kran77 - Fotolia
A quick rundown of multi-runtime microservices architecture
Learn the basics about a multi-runtime architecture, and the two-component approach it takes to provide a standard for abstracted microservice-messaging processes.
A microservices architecture helps decouple business domains across bounded contexts in which each microservice is developed and built separately. With that said, microservices alone are incapable of breaking down the coupling between business logic and middleware concerns. Adhering to microservices standards won't protect you from coupling with the middleware if the domain requires complex integrations.
Let's take a closer look at this component-coupling issue, particularly when it comes to the libraries and middleware that tend to inhabit a microservices environment. Then, we'll discuss how an approach known as multi-runtime microservices might provide an answer to this problem.
Component coupling problems in microservices
If your software architecture is peppered with complex integrations and dependencies, applying microservices development and coding principles won't be enough to avoid troublesome component coupling. If middleware components rely on the same libraries as your microservices to define variables, coupling will become particularly apparent as soon as you migrate and modify those libraries.
Multi-runtime microservices architecture is an approach that addresses these challenges. The main advantage of this architecture is the loose coupling of business logic and distributed system concerns. Although business logic code is unique and relies on the organization's preferences, distributed primitives are developed based on factors such as vendor priorities, security updates and release cycles.
What does a distributed application need?
A truly distributed application architecture requires development teams to think carefully about four specific aspects of their software systems and applications. They are as follows:
- the ability to deploy continuously, scale services automatically and provide reliable error-recovery mechanisms;
- networking capabilities, particularly service discovery and error discovery;
- the ability to coordinate reliable workflows, job scheduling and service orchestration with state-based methods; and
- the degree to which components can integrate and communicate between legacy and updated systems.
The micrologic and mecha components
A multi-runtime microservices architecture represents a two-component model that very much resembles the classic client-server relationship. However, the components that define multi-runtime microservices -- the micrologic and the mecha -- reside on the same host. Despite this, the micrologic and mecha components still operate on their own, independent runtime (hence the term "multi-runtime" microservices).
The micrologic is not, strictly speaking, a component that lives among the various microservices that exist in your environment. Instead, it contains the underlying business logic needed to facilitate communication using predefined APIs and protocols. It is only liable for this core business logic, not for any logic contained within the individual microservices. The only thing it needs to interact with is the second multi-runtime microservices component -- the mecha.
The mecha is a distributed, reusable and configurable component that provides off-the-shelf primitive types geared toward distributed services. The mecha uses declarative configuration to determine the desired application states and manage them, often relying on plain text formats such as JSON and YAML.
Ultimately, these particular application states dictate which features the services activate and the communication path it travels. However, the mecha component makes no assumptions about the micrologic runtime and uses transparent protocols and formats for messaging -- like HTTP/gRPC, JSON, Protobuf and CloudEvents -- to remain a flexible, polyglot component.
Use of multi-runtime microservices
The adoption of cloud and Kubernetes opens different avenues for implementing a multi-runtime microservices architecture. One approach involves using a sidecar pod that offers out-of-the-box primitives designed for distributed architectures. While the business logic pod forms the core of the application, the sidecar pod acts as the mecha component that will standardize integration through the supplied primitives.
This multi-runtime approach takes advantage of out-of-process features for its distributed system needs. The future likely holds more of these multi-runtime projects, such as Microsoft's open source Dapr (Distributed application runtime) project.
