Microservices: “Service landscapes are of great benefit to business agility but require very fast remediation cycles”
It’s DevOpsCon Munich right now, and speaker Tobias Kunze took some time to answer a few questions for us about controlling the chaos that can start to set in as applications federate and microservices accelerate the speed your dev team works at.
JAXenter: Microservices have changed the way businesses and development teams work and we’re starting to see more and more references to complex, layered and deep systems. What do you see as the biggest challenge that companies relying more and more on microservices have to face?
Distributed systems are difficult to engineer on all levels, from the computer science behind it all the way to specific details of implementation.
Tobias: When we hear “layered” or “deep,” we still think in terms of an “application.” After all, that’s what we grew up to do, right? We build applications. But the new reality that enterprises live in today is one of federated applications: applications that interact with each other but are not part of the same blueprint or even the same roadmap. They are developed independently, by small, self-managing teams and all deployed in parallel. In other words, enterprises deal with systems of applications, not just individual applications. This is considerably more challenging and has fundamental implications for operations, SRE and security teams. Microservices accelerate and exacerbate this new reality.
SEE ALSO: DevOps: “A T-shaped human has the benefits of being a specialist in a particular area but also a generalist in many areas”
JAXenter: You’re the CEO of Glasnostic, which describes itself as “mission control for federated applications” – in your experience what is the likelihood that microservices could unexpectedly interact with or affect each other?
Tobias: It’s less a matter of microservices interacting accidentally across application boundaries. It runs deeper than that. As applications federate, the very notion of an application starts to disappear! Applications depend on other applications, and other applications in turn depend on them. Because the business craves agility and rapid time-to-market, applications turn into services so new applications can be rapidly built on top of them—that’s how value is created. And because those new applications build on existing capabilities, they become smaller, more “micro,” if you will.
JAXenter: And what sort of impact can that have on the overall system?
Tobias: The result of these two trends, federation and organic growth, is what we call a “Service Landscape.” It is a continually evolving landscape of sprawling, connected services. And the reason why this is a fundamentally new reality is that failures in a service landscape predominantly don’t occur because of a defect in an individual thread of execution—they occur because of environmental factors. Factors such as grey failures in dependencies, random ripple effects, noisy neighbors and the like. This has profound implications for “old-school” operational practices like monitoring, tracing, and in general, observability.
JAXenter: In your DevOpsCon session “Controlled Chaos: Managing your Microservice Ecosystem for Business Agility” you will talk about how to impose order on the emergent behaviors of these hyperconnected microservices – how big of a challenge is that?
Tobias: Service landscapes are of great benefit to business agility. But, because they represent a new reality in which environmental factors determine the stability and security of the landscape and because these factors are large-scale in nature and inherently unpredictable, they require very fast remediation cycles. This is a big challenge and a big shift away from our traditional approach to operations, which is obsessed by the notion of a “root cause.” The new reality that service landscapes represent requires operators to see very quickly what is going on, at the systemic level, not the level of microscopic details, and to respond to it in real-time. This ability to view and do, in real-time, is essential to operating a service landscape successfully.
JAXenter: You also mention in your session’s description that the ability to remediate at the ecosystem level is more important than observability. Could you tell me more about what you mean by that, as it seems like monitoring and observability are very prominent concerns when dealing with microservices?
Our software systems have reached a scale at which traditional, systems-oriented engineering is simply too expensive to make any economic sense.
Tobias: Yes, absolutely. Because distributed systems are difficult to engineer on all levels, from the computer science behind it all the way to specific details of implementation, they tend to require very small tolerances and these tiny tolerances make observability eminently important when you are running such a system. But, like massive SQL systems, such architectures are increasingly an anti-pattern in the enterprise. They are simply too slow to build, too expensive to maintain and too heavy to evolve! That’s why agile enterprises opt for an organically evolving landscape of services in the first place: because it gives them speed.
Now, as a developer, your area of responsibility is much smaller in a service landscape—likely only a handful of services! And because you ultimately only care about that, observability becomes a very local concern. You don’t want to trace into services you merely depend on! What matters is the ability to rapidly “view and do,” at the systemic level and in real-time.
JAXenter: Looking to the future now, where do you think we’re heading in terms of microservices and platforms such as Glasnostic that help tame the beast?
Tobias: Services. Whether you call them “microservices” or “applications” doesn’t matter. Our software systems have reached a scale at which traditional, systems-oriented engineering is simply too expensive to make any economic sense. Yes, you may still punt a whole country’s wealth on building a Burj Khalifa, but for the vast majority of businesses, it’s going to be urban sprawl. Development after development, after development. That’s how we, as humans, deal with complexity. Divide and conquer, step by step. That’s why microservices have become successful!
Service landscapes are the natural evolution of microservices. The new reality is that we have an organically evolving federation of services. There are no more applications: everything has an API and is part of that landscape. And the new reality is that, like organizations, service landscapes need real-time management, not debugging. That’s what we, at Glasnostic, have set out to do: provide enterprises with runtime control over their services. Not just passive observability. Active management.