Service Meshes and App Modernization

Container-mania continues unabated. But that might not mean what you think in terms of applications and architectures.

There remains a tendency to equate containers with microservices. And by equate I mean "use interchangeably." 

This is a bad assumption.

You see, a significant percentage of containers today are actually being used to deploy … existing applications. As noted in Container Journal, an IDC survey found that less than half (46%) of containers were used for new applications. The rest were running existing applications. (Source: IDC Survey Finds Containers Driving Mission Critical Apps) The oft-cited explanation for this strange combination? Modernization.

There are any number of studies and research that will point out the number of "new" applications being built as cloud-native are still relatively small - less than 1 in 5 by Cap Gemini's research. Recent research from Diamanti found that 31% of IT leaders were looking to containers specifically for the purpose of modernizing legacy applications. This is no surprise. We are in an era of multi-generational IT, supporting five different generations of application architectures. 

So there's all these traditional apps out there - and more still coming - that may wind up deployed in containers.

I'm going to posit that's a good thing, because containers and related technology like service meshes can actually aid in modernization efforts.

Modernizing Monitoring with a Service Mesh

Observability, if you aren't familiar, comprises three generally accepted pillars as detailed by Cindy Sridharan in "Distributed Systems Observability":

1. Event logs
2. Metrics
3. Traces

There is no shortage of content on this topic - including the challenges inherent in the big operational data generated by logs and the emission of telemetry - so I won't cover it here. Suffice to say that you need all three in order to realize the full potential of observability.

Suffice it also to say that on this latest point - traces - existing and legacy applications are at a disadvantage. You see, most were not instrumented to emit the telemetry necessary to trace a transaction on its journey from origination to fulfillment. Event logs and metrics are much easier to generate and obtain regardless of application architecture and environment. These are standard options in just about every web and application platform. But instrumentation? That usually implies embedded code or agents with visibility into real time traffic.

Which is one of the things a service mesh can provide.

If you recall, a service mesh is primarily composed of sidecar proxies inside a container orchestration environment. These proxies basically proxy all communication - in and out - for a container. By doing so, these proxies scale services but also provide a perfect place to instrument traffic for purposes of enabling full observability. They can enrich messages traversing the container environment to include detailed tags and other meta-data that enable systems to track and correlate traffic across multiple systems and services.

Best of all, they can achieve this with very little modification of the application. In some cases, like that of Java apps, there are configuration-based options to inject the appropriate capabilities without modifying code.

The ability to emit traces from existing applications is a key capability in the quest for true observability. If existing applications will be deployed in containers, consider how a service mesh can help modernize them.