Microservice Architecture
Making Microservices Work in the Cloud
“The term Microservice Architecture has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization, around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.” — James Lewis and Martin Fowler
Microservices
For years, services have been a favored technique when building Web applications. Web apps are frequently built with HTML, CSS, and JavaScript GUI front-ends running on Web browsers that interact with Web servers to query, insert, update, and delete business data. This architectural pattern has been enshrined as Service-Oriented Architecture (SOA). The Spring Framework and Jakarta RESTful Web Services (JAX-RS) are the go-to frameworks for implementing SOA in Java.
It is important to understand that though microservices are a type of SOA, not all SOA implementations are microservices. In fact, using the popular SOA frameworks makes it difficult — if not impossible — to realize the full promise of microservices.
One of the major problems with the term microservice is the lack of a precise definition for it. Through inexperience, ignorance, or sheer marketing chutzpah, the term is often misused for technologies that cannot possibly meet the declared objectives of the microservice architectural pattern. So, what makes a SOA service into a microservice?
A microservice:
- Implements a single task (or set of closely related tasks) within a bounded context. This is a fundamental characteristic of a microservice. The more different things an individual microservice tries to do, or the more ownership boundaries it crosses, the less likely it is to meet the other objectives of microservices.
- Is loosely-coupled and makes use of little or no knowledge of the definitions of other microservices. Ideally, it makes use of messages in a standard format, such as JSON, when communicating with other services.
- Is autonomous and can be modified without coordinating with other development teams. This is a key attribute for promoting agility in microservices development.
- Is independently deployable and can be individually tested, rolled out, and rolled back without impacting other microservices. This is a key attribute for promoting agility in microservices deployment and scalability.
If an application component does not meet these four objectives, it may be a service, but it is certainly not a microservice — and it cannot deliver all the benefits of the microservice architectural style.
Single Bounded Task
This is why we call them microservices and not simply services. To be autonomous and independently deployable each microservice should focus on implementing a single task that is tightly bounded by a clearly defined context within the problem domain. This promotes the high level of granularity and separation of concerns that preserves microservice autonomy and independent deployability.
Loosely Coupled
A loosely coupled microservice is less likely to be affected by changes to other microservices or to have an effect on another microservice when it is changed.
Microservices should communicate through message passing, rather than by function calls, method calls, or remote procedure calls (RPCs) — which are tightly coupled, frequently computer language specific and, except for RPCs, require services to be physically deployed in the same executable. A true cloud-capable microservice architecture is message-driven using both synchronous request messages and asynchronous queued event messages. The message passing Actor Model is an an excellent model for microservices.
Unlike the messaging between the Web client and the initial Web service, when using Spring Boot or JAX-RS, communication between separate services typically uses Java method calls and requires the cooperating services to be deployed together — hardly a loosely coupled or cloud-friendly solution.
Autonomous
An autonomous microservice can be modified and tested without the need to coordinate with other development teams. This attribute dramatically reduces software development overhead and makes agile development strategies more efficient and more easily managed.
To be truly autonomous, a microservice must also be testable in isolation from other microservices. When using Spring Boot or JAX-RS, a service resource cannot easily be accessed or executed except though the framework.
Independently Deployable
The granularity of a service and its ability to be tested, rolled out, and rolled back individually, without impacting other services, is the deployment side of development autonomy. It is a crucial component of service agility and continuous delivery.
Being independently deployable is also critical for exploiting the automated deployment, scaling, reliability, and failover capabilities available through cloud containers and container orchestration.
When using Spring Boot or JAX-RS, a “microservice” is actually deployed within a set of Java .jar files as a part of a larger deployed executable. It is not independently deployable and is usually dependent upon the supporting framework code to be executed. These frameworks are powerful, reliable, and manageable implementations of the SOA pattern, but they cannot exploit the full promise of the cloud or microservices.
If you are interested in reading more about how to take advantage of the real capabilities of microservices and the cloud, we recommend that you read Software Architecture for the Cloud.
Thank you.
