Bilgin Ibryam talked at QCon London [slides] about the evolution of distributed systems on Kubernetes and the future architecture trends. Ibryam said that the next trend would be to decouple infrastructure concerns from microservices. Ibryam calls this multi-runtime microservices, a service with business logic along with a sidecar in charge of state management, networking, binding, and lifecycle.
Modern distributed applications are conformed by hundreds of polyglot, independent, and automatable components. Some applications run on hybrid environments, use open source software, and are based on a Kubernetes ecosystem, said Ibryam. Additionally, Ibryam mentioned that distributed applications require lifecycle management, advanced networking, resource bindings, and stateful abstractions. According to Ibryam, cloud-native architectures, along with Kubernetes, fulfill many of these needs with health probes, self-healing mechanisms, declarative deployments, workloads scheduling, and configuration management.
Ibryam talked about the evolution of the Kubernetes ecosystem with projects like Istio, Knative, or Dapr. New patterns have emerged in the ecosystem thanks to these projects, which is the reason why he said that serverless is not what comes after microservices. Although, serverless has more specific use cases for implementing an application as a single operation. According to Ibryam, what comes after microservices is to decouple infrastructure concerns like networking or resource binding, and he calls it "multi-runtime" microservices architectures. In a recent post, he said:
In this software architecture, you have your business logic (referred to as "micrologic") forming the core of the application and the sidecar mecha component that offers powerful out-of-the-box distributed primitives. The micrologic combined with the "mecha" capabilities form a multi-runtime microservice, which is using out-of-process features for its distributed system needs.
InfoQ interviewed Bilgin Ibryam, product manager at RedHat and co-author of the "Kubernetes Patterns" book, to find out what multi-runtime microservices are and the concerns in regards to performance degradation and complexity of microservices.
InfoQ: What do you mean by multi-runtime microservices? Any example of a tool, company, or pattern that is already implementing this architecture?
Bilgin Ibryam: When you use a service mesh like Istio, it comes with multi runtimes like Envoy next to your application. But what’s happening is you do more things in other runtimes like Envoy or the Docker runtime. For instance, Envoy was only doing traffic management, but now the tendency is you do more with it, like caching or encryption. So, I see a shift from "smart endpoints, dumb pipes" to "smart sidecars, dumb pipes;" all the intelligence is not in the endpoint but in the sidecar. You have your business logic pod forming the core of the application and the sidecar pod that offers out-of-the-box distributed primitives. This forms a multi-runtime microservice which is using out-of-process features for its distributed system needs.
InfoQ: What about performance? Any concerns that systems might become slower by having too many sidecars around?
Ibryam: There are already efforts in service mesh from other projects that help us to write sidecars more efficiently when interacting with the OS or hardware like Cilium or Calico. But, apart from that, I’m not suggesting you have many sidecars. Probably, the best approach will be to have consolidation. So, you have one pod for your business logic and one sidecar doing more things to cover the distributed system needs I talked about today. The overhead will be negligible. Similar to the overhead in performance we have from moving a monolith to a microservices architecture where you have too many interactions. Having one sidecar could be increasing the overhead, but not in a tenfold increase.
InfoQ: What’s your position on other companies moving back to monolith architectures after experiencing the complexity of using microservices?
Ibryam: I maintain a website called microservices.fail where I have a collection of articles from companies failing at microservices. So, I’d say that multi-runtime architectures are kind of helping you with those failures. You can still combine microservices with a monolithic system, but I don't think you will be combining all of these needs from distributed systems, like networking connectors or working with different APIs. You don't want to put that into a monolith. You can still have business logic in the monolith, but next to it you can have a sidecar. So, even if the trend goes back to the monolith, it won’t be in the shape of the old monolith, but more in the shape of the distributed system needs. So, I'm quite excited about this idea, so whatever it turns, I stay for selection.