Architecting the Stateless, Software-Defined Digital Enterprise

Taking a page from the DevOps playbook, we don’t want to monkey with systems in any production environment. Instead, if there’s a problem in production or if we’d like to roll out an update, we should make a change to a recipe, script, or other abstract representation of the running software and then rely upon automation tooling to reprovision the code in question.

This immutability principle is fast becoming a reality for more advanced DevOps efforts, but as I discussed in my last two Cortex newsletters (read Part 1 and Part 2), we have not yet fully realized the broader vision of shift left/Software-Defined in the context of immutable infrastructure with the state of our technology today.

However, we’re well on our way – and given the continually accelerating pace of technology innovation, it won’t be long until all the pieces are in place.

Any digital transformation roadmap, therefore, should take into account the power of the immutable infrastructure principle as it applies to the entire enterprise digital deployment – which in reality, becomes the digital enterprise itself.

Statelessness and Immutable Infrastructure

One essential aspect of such immutability: statelessness.

The question of how and where to manage state information is an important, if rather technical consideration for any distributed architecture. As we apply Software-Defined principles to our digital organizations, however, statelessness becomes an invaluable capability for addressing several of the knottier issues with modern digital architectures.

At its most basic, state information is how software keeps track of things – for example, what you’re doing at a particular moment on a web site.

In traditional distributed architectures, we typically maintain short-term state information in various types of caches or other temporary storage mechanisms, and write such information we want to keep long-term to our persistence tier – in other words, a database of some sort.

Knowing what data to put in a cache and how long to keep them there is a famously difficult problem in distributed computing – and this problem becomes even knottier as we move to immutable infrastructure.

Let’s say, for example, we have an ecommerce web site that gets a lot of traffic, so that at any moment in time, there will be a good number of people at every step of the ecommerce process – putting an item in a cart, checking out, entering payment information, etc.

Now let’s say we want to roll out an update to our site. Following the immutable infrastructure principle, we deprovision the site (or some part of it) and redeploy it by running an automated script. What, then, happens to the numerous purchases in progress? Clearly, we don’t want to drop them.

In a traditional architecture, solving this problem essentially requires one awkward workaround or another. We might briefly pause the workflow, stalling people at the beginning to allow in-progress sessions to complete before we roll out our update – even though some customers will bail because of the delay.

Or we might take the cached state information and write it to a database, and then reconstitute it after the update in the hopes that customers won’t notice – even though this alternative impacts performance.

In any case, we don’t want to make a habit of writing cached state information to our database too often, because that would slow everything down – one of the main reasons we use caches in the first place.

Regardless of which workaround we choose, we still have a problem. If we have to go into our ecommerce infrastructure and manually configure one of these workarounds, then we’re breaking the immutability principle.

However, even if we script our workaround of choice, thus making it part of the broader automated deployment, we still haven’t fully implemented a Software-Driven approach. We’re still missing the big picture.

The Software-Defined Digital Architecture Mindset

The problem with scripting our workarounds is, well, they’re still workarounds. Instead, we want to leverage a coherent, Software-Defined abstraction across the entire architecture.

In other words, we want to build an abstraction that hides state management issues altogether, an approach we might call Software-Defined State.

We start with our persistence tier – which in modern, cloud-centric architectures is no longer simply a database, but an abstracted collection of distributed data stores with built-in resilience, availability, and tunable consistency. Such an abstraction is inherently Software-Defined.

Next, we take this notion of separating the logical persistence layer from the physical infrastructure underneath and extend it to the distributed caches as well. After all, why bother with caching-based workarounds if we can rely upon a Software-Defined state management solution?

Once such a solution is in place, we can essentially treat our Software-Defined digital infrastructure as inherently stateless. We’ve moved up the level of abstraction necessary to consider our digital architecture as consisting of two basic elements: a Software-Defined persistence tier and a Software-Defined edge.

Understanding the Edge of our Software-Defined Digital Architecture

In traditional distributed architectures, we refer to the edge as infrastructure that is close to the user, as opposed to belonging to a centralized data center or other centralized infrastructure.

The edge thus includes all client devices, but also includes infrastructure that is close to users, like the distributed servers that make up content delivery networks (CDNs), or technology in distributed physical locations like branch offices or stores where customers might be located.

When we move to modern, Software-Defined Digital Architecture, however, we free our Software-Defined edge from any particular physical constraints that we might traditionally associate with edge-based technology – including location itself.

In this context, offices, stores, and other branch locations become “virtual branches,” where we might provision the software-based capabilities at one location or another with the push of a button, handling knotty issues like state management and latency in the underlying infrastructure, hidden from view.

Furthermore, even the devices we hold in our hands can be part of the Software-Defined edge.

Today we might go to the Apple App Store or Google Play to manually install or update our apps. In a Software-Defined world, those choices are part of a deployment and configuration script, freeing the specific configuration of each device from the device itself.

The power of this stateless, Software-Defined Edge is profound:

• Companies can ensure no corporate data remain on devices, in case they be lost or stolen.

• Enterprises with branch offices in different locations around the world can manage the physical location of their data separate from the locations of those branches.

• Access policies or other permissions can follow individuals, even as they move from one device to another or one location to another, independent of the physical network they connect to.

• Mobile employees can log into any system anywhere, and find their entire personal digital environment ready at their fingertips.

Individual technologies, like mobile data management and virtual desktop technology, have provided point solutions to each of these problems for a while now. In the fully Software-Defined, stateless digital world, however, we finally achieve a single, coherent approach to configuring, managing, and changing all such capabilities across the enterprise.

Software-Defining Our Data

One of the important benefits of Software-Defined Digital Architecture is that our data are where we need them, when we need them. If we need to access corporate data from our phone, we have that capability – but if we don’t want to store such information on a device, so be it.

Furthermore, a distributed, resilient persistence tier that provides low latency around the globe is now a practical reality. But if we must also conform to a mishmash of data sovereignty regulations limiting where data can go, we can meet that requirement as well.

Finally, in the fully realized Software-Defined Digital Architecture, even the problem of data gravity becomes less of a concern.

In today’s Big Data world, massive data sets can be too expensive and slow to move, and thus moving our compute capability closer to the data is often necessary. With our modern approach, we may still have the underlying physical limitations that characterize data gravity, but our Software-Defined digital architecture allows us to think of our data as well as our compute capability as location independent.

As a result, the abstraction technology that supports our Digital Architecture either handles the proximity of data to compute automatically, or we simply configure our choice as a matter of policy.

The Intellyx Take

We may not have all the pieces to making this Software-Defined vision a reality, but even today, most of this vision is now possible – and the few missing parts are right around the corner.

Remember, digital transformation requires an end-to-end rethink of how enterprises leverage technology to meet customer needs. Your rethink should already be well under way, even though the full vision is still incomplete.

Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Steve Johnson.