It was a Monday. I was reading the Internet. Okay, I was skimming feeds. Anyway, I happened across a title that intrigued me, "Stateful Apps and Containers: Squaring the Circle." It had all the right buzzwords (containers) and mentioned state, a topic near and dear to this application networking-oriented gal, so I happily clicked on through.

Turns out that Stateful Apps are not Stateful Apps. Seriously.

To be fair, I should really say that when a devops guy talks about ‘stateful apps' it is not the same thing as when a netops gal uses the term ‘stateful apps.'  That's because the devops guy is referring to persistent data storage for applications. File systems, databases, etc... When a netops gal talks about stateful apps, they're talking about the unique characteristics that identify existing TCP connections between two systems, like a client and an app. Devops thinks in terms of app data, netops about network data.

Devops and netops speak different languages that use the same word to mean different things. It's like English. No big deal.

The thing is that this may seem like a minor issue to be worried about. But then I got thinking about emerging application architectures like microservices and the dominance of APIs and the urgency with which everyone is moving to secure HTTP traffic. And I realized that actually, it is a pretty big deal, because it's a clash of ops. While devops is over there, building stateless architectures based on the newest theories and principles of scalability, we're requiring security that basically negates many of the benefits we might have seen.

That's because the nature of public key cryptography requires state in the network.

Here Comes the (Computer) Science
Public key infrastructure (PKI) is based on a fairly simple premise that information is exchanged between two endpoints (client and app) that is unique to that connection. That means any subsequent exchanges have to be made between the two endpoints that established that connection.

That's stateful networking.

Even if your entire architecture is based on stateless microservices, once you add security (SSL/TLS), it's stateful. Whamo! Just like that. And that impacts scale. Because now you've got to figure out how best to distribute traffic based on how loaded any given instance of that app might be.

And you probably don't want to be renegotiating secure sessions for every, single, interaction. You don't. I don't care how much faster HTTP/2 is, or how much better ECC is over previous generations of cryptography (spoiler: quite a bit better), there is still significant latency by the process of negotiating that connection. There's the overhead of establishing the underlying TCP session and then the security negotiations. That adds latency thanks to all those round trips back and forth, which means slower application response times. Especially on mobile devices.

So what? You might say. It's measured in milliseconds, that can't possibly impact the application experience.

But it does. Milliseconds matter, especially today, when digital natives who've never experienced what 2800bps feels like want their apps to respond instantaneously, with LAN-like performance.

What that means is that adding that layer of security (which is - or should be - a requirement) effectively turns your elegant, stateless architecture into a stateful one.

This is why architecture matters. Because it's no longer a matter of throwing a load balancer in front of those services and picking an algorithm, it's about extending the app architecture into the network, upstream, and understanding the advantages of terminating that security before it gets all that "state" in your "stateless" architecture. If the load balancer (or ADC if you prefer) is terminating SSL/TLS, then it has to manage the negotiation, and the back and forth with clients. That means it's free (if it's a modern proxy-based solution) to interact in with services in the back-end the way dev intended: statelessly.

The thing to be aware of is that when app architectures and network architectures meet, they can often clash and effectively negate all the goodness intended by the new app architecture in the first place. DevOps is as much about communication between groups as it is automating the processes between them. That means understanding the impact of the network on apps, and vice versa and agreeing on an architecture that preserves the best characteristics of the app architecture without sacrificing network speed or security.