Application Services for Kubernetes Applications: Same Old New

It’s a long way from VMS VAX troubleshooting to writing serverless microservices (although with the announcement of COBOL support in AWS Lambda at re:Invent, the first lap of the IT lemniscate might be complete).

Many things have changed along the way. I seem to remember being able to hack up scripts in Perl and getting annoyed at an operating system that would let you change directory to somewhere that didn’t exist (bonus: it would let you create it once you were there). Now it seems you can spend as much time deciding on the very approach to solving a problem as actually solving it. And this is fantastic. The array of architectures, the pace of development, the digital opportunity, and the unlashing of developer creativity that all the new toys are giving us is great. It doesn’t matter what side of the proscenium arch you are on, both builders and consumers are enjoying new and better apps at a rate and functionality that was the property of science-fiction not that long ago.

Containers and their watchful Kubernetes minder is a pertinent example. Container technology has unarguably been a key accelerant of the application development explosion.

This week in sunny Seattle (as of 10:46 AM on the day of writing [Update – still sunny at 1:36 PM]), over 8,000 people are gathering to talk, listen, and learn about Kubernetes and other open-source related technologies. The mix of conversations, hands-on learning, and stimulants is the primordial soup of innovation. While you are reading this, 12 great new ideas (and 37 terrible ones) will have been dreamed up.

Some of these apps will change lives, some will innovate architecture, some will evolve user interfaces, and some will probably just be another way to illustrate how disconnected I am from youth culture.

But a few needs will unite these diverse applications and the frameworks they use. The solutions might look different, but there are critical components that everyone needs to solve for:

Scale – If you’re going to make it big, you need to be able to get big along the way (and probably occasionally back again).

Stability – All apps need an appropriate level of stability – from ‘making it through the onstage demo’ to life-threatening uptime requirements.

Security – Bad people exist, and sometimes they will attack your applications. The complexity of modern systems seems to ceaselessly stretch the attack surface area you need to worry about.

Observability – Seeing is believing, which is doubly important when there’s a problem. Getting the right information from the OSI layer to the right people fast can help you fail less, recover faster, and make the ‘you build it, you run it’ world a bit more comfortable.

These needs aren’t terribly unique, but they remain the fundamental concerns that need to be addressed by every well-architected app, ideally before they become a problem and before a line of code is written.

My esteemed employer F5 Networks has built a multi-billion-dollar business meeting these needs, and honestly, we’re pretty good at it (but I would say that). We call the things we make to meet these needs application services. Application services that secure application traffic, inspect it, direct it. Application services that route clients to the right place, application services that extract, forward, and display key application telemetry. These are the core services that have kept our customers’ applications up and running – and they are the kind of services that applications continue to need, no matter where or how they are created.

Bringing it Back to a Vendor Pitch?

So far, so ‘old crusty guy trying to convince me his old-skool tech is still relevant.’ OK, so here’s what has flipped, twisted in the air, and landed upside down. Let’s start with the most important: The way the services are deployed.

One of the enabling technologies behind the adoption of platforms and working practices has been the systems that link intent to action in an automated, integrated way. Application services have to be part of this chain, and this represents a more fundamental shift than simply a change in runtimes.

Sometimes, services need to be injected into existing components – like the exceptional visibility and control that Aspen Mesh adds to Istio. Alternatively, connection tools like the F5 Container Connector can link environments to services, so that as Kubernetes pods are added or removed, they can be secured, scaled, and observed.

Ideally, the code to create the application services needs to exist in the same repository as the code for that application and be deployed in the same way. Application service definitions – for example a web application firewall service – need to exist as code and be treated as code, whereby a service definition change and commit in source code management produces a production web application firewall deployment without further human input. In late-breaking news the fast-talking Melaine Cebula from Airbnb described exactly that model in her Wednesday keynote session at Kubecon when she described keeping all the components for a service – including infrastructure definitions in a single project (as well as about fifty other cool things they do to make app developers lives easier).

This change in service instantiation (coupled with the welcome death of long IT ticket queues) is dramatic and obvious.

The second change is maybe a little more mundane, but still critical. One of the joys of Kubernetes and containers is portability between environments. Your Kubernetes-managed microservice will run anywhere a supported container engine does (hint: everywhere), and the same app services should be there too, not ‘sort of the same’ or ‘does the same thing in a different way with a slightly different interface.’ The same. This means the number of places we need to deploy is growing all the time.

The need to work in the same way and the same places as all your current and potential Kubernetes deployments has become guiding principle for F5.

It’s absolutely critical, as our customers not only rely on us to keep not just their existing apps scaled and secure, but also need to know we’ll be protecting and observing the apps that are – as of this very writing – being thought of as a rogue caffeine molecule binds to a lucky adenosine receptor in need of a post-lunch boost.