Microservices are a modular architecture approach that is driven by domain driven design principles and organization’s communication structure.
The size of service matters. Microservices meant to be “micro” in nature.
Microservices are developed in a modular fashion. Teams develop software in modules. Developers focus on modules and inter-communication between modules rather than understanding the whole system.
Microservices run within independent processes. Therefore, communication between microservices is via the network.
A team has to be able to implement features independently of the other teams.
Domain Driven Design
In Domain-driven design, a domain is defined as a sphere of knowledge, influence, or activity. DDD is a methodology that is applied when designing individual systems. Here, we propose to use domain-driven concepts at the enterprise architecture level, organizing the IT portfolio in large bounded contexts.
Capability domains bring together:
- The products that support the capabilities of the domain
- The information that is produced by the products in the domain
- The application experts who ‘own’ or support the products in the domain
- The projects that realize domain capabilities and thus deliver value to the business
Domain-driven design is important for understanding microservices for it supports structuring of larger systems according to domains. Each microservice is meant to constitute a domain, which is designed in such a way that only one microservice has to be changed in order to implement changes or to introduce new features.
Microservices architecture benefits
- Strong modularization
- Easily replaceable
- Velocity, strong modularization and replicability leads to sustained speed of developmen;
- Legacy systems can be supplemented by microservices without the need to carry around all the code accumulated by legacy systems;
- Continuous Delivery is much easier to setup because of smaller nature of services;
- If microservices are implemented by applying best practice then it results in a more robust system;
It takes a long time to upgrade from one version of language to a newer version. If making a framework upgrade means impacting every single aspect of your production deployment, it is highly unlikely that the business would agree to it.
Microservices offer technological freedom. Microservices communicate over the network via language-agnostic protocols, they can be implemented in any language and platform as long as it can communicate with other microservices. 3
Microservices offer Free Technology Choices to an Organization
Choice of data sources
And languages that an organization can support
Standardized protocol with polyglot service implementation
HTTP protocol with JSON payloads is recommended. This yields better performance at runtime, compared to XML/SOAP. A REST style (noun-verb) service API is recommended. It also maps more naturally to the data hub data models. Teams implementing services may choose a technical stack appropriate for the specific services. e.g. a stateless orchestration service that retrieves status of an order may use light-weight components such as node.js or java Tomcat, whereas a service that expose capabilities of the SAP module may be written more naturally in ABAP. In both the scenarios, the services should expose endpoints supporting HTTP protocol with JSON payloads.
Service implementations with XML over SOAP, or ESB style integration isn’t recommended.
Command Query Responsibility Separation (CQRS) pattern
Typical calls to business services represent a large number of information query and read operations and a fewer calls for information updates. Accordingly, it is recommended to use Command Query Responsibility Separation (CQRS) pattern. It allows for effective performance improvements as compared to services based on canonical models. CQRS also implies an event driven asynchronous processing model. An event bus (publish / subscribe messaging platform such as MQ or Kafka) will enable coordination for event processing and implementation of eventual consistency paradigm.
Stateless, REST-style services with containerized deployments
We recommend that all services in the API layer shall be stateless. These services should transfer state to either a persistence layer (backend systems, data hubs, transient data stores) or to client components (session state is stored with BFFs and browser apps).
We recommend an architecture with REST style services along with a microservices based, containerized deployment approach. Containerized deployments, in addition to supporting seamless scalability of services, will simplify operational aspects and enable faster adoption of cloud.
As stateless processing components, the services should either persist the state permanently to backend systems or data hubs, or temporarily to transient data stores, or they should transfer the session state to client applications following the REST principles.
Services should use a light-weight mechanism such as the HTTP protocol with JSON payloads for better performance. Distributed transactions in an event driven architecture should be supported through a variant of two-phase commit protocol.
Query services live on top of data hubs and hence they provide access to data hub content, only. The recommended service protocol is GraphQL. Query services may have internal caching strategies, but this is not observable through the interface.
Query services may unify access to data hubs and corporate memory.
Istio framework is highly recommended for visibility within microservices.
Istio is an open platform to connect, manage, and secure microservices. It provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. It provides a number of key capabilities uniformly across a network of services, including:
- Traffic Management
- Policy Enforcement
- Service Identity and Security
During the lifecycle of a services, service utilization may grow (or shrink) in terms of volume of requests it processes. Accordingly, it is recommended to use a container-based deployments architecture
Microservices with Java EE
For microservices Java EE i.e., WebSphere / JBoss can also be an option: Theoratically it would be possible to run each microservice in its own application server. In this case an application server has to be installed and configured in addition to the application. The version of the application server and its configuration have to fit the version of microservice. For Fat JAR deployment there is no need for specific configuration because it is part of the Fat JAR i.e., Spring boot for instance. This additional complexity of the application server is not counterbalanced by any advantage.
- Microservices [Eberhard Wolff]
- Domain-driven Design — Eric Evans
Cloud Solutions Architect
Mazhar Choudhry is a Cloud Solutions Architect at Objex, Inc. He has tremendous experience of successfully implementing digital transformation stacks i.e., Microservices, APIs, Containers and Eventing platforms for various customers.
Solution Architecture, Event Driven Architecture, API Management using Apigee Edge, Microservices, Docker, Kubernetes, Azure DevOps, AKS, Azure Dev Spaces, GKE, HELM, Istio, Kafka, Redis, Java, Google ML Engine, Typescript, Spring, AWS, Azure, Google Cloud Platform (GCP), Technical Architecture, OpenShift, ELK, EFK, Logstash, Fluentbit, Datadog