Getting the most from microservices
Adopting microservices has impact on more than just the code. Organizations must understand and accept the consequences of reorganizing into smaller and more nimble teams. This might, for example, include decentralizing decision making and expanding access to staging and production environments.
In addition, existing development skills often do not directly transfer to this new architectural pattern. Changes can be difficult, and become particularly challenging when they impact both technology and the organization. Whether you are at the beginning of your journey or already have experience and are ready to move to the next level, understanding the difference between traditional n-tier architectures and microservices will contribute to your success.
A variety of competing technologies claim to offer a fast path to microservices. However, decomposing a traditional application into individual services does not guarantee that you will realize all of the desired benefits. Microservices run in a distributed environment where network, hardware, and software failures are everyday occurrences. It is possible for a microservice system to succeed initially, only to fail under increased load or unexpected spikes.
For systems with demanding requirements, we recommend Reactive Principles as the best way to design a system that copes well with uncertainty. Reactive Principles, as defined in the Reactive Manifesto, include the properties of being responsive, resilient, elastic, and message-driven. The Akka platform has delivered the technical and organizational benefits of microservices for demanding applications across a variety of industries.
When designed with Reactive Principles, microservices have the following characteristics:
- Isolation, where each microservice is completely decoupled so that its lifecycle, including failure, has no impact on other microservices in the system.
- Autonomy, where each microservice acts and makes decisions independently and publishes its behavior through an API.
- Single responsibility, where each microservice does one thing and does it well.
- Event-driven, where a microservice produces, consumes and reacts to events.>
- Mobility (and addressability), where a microservice can be moved at runtime but can be reached in the same way regardless of its location.
- Own their state exclusively by managing and persisting their own state in the way that best suits its own needs.
Mobility and addressability give reactive microservices resilience at both an individual and a system level. A cluster of microservice instances can be deployed in different JVMs, if a single instance fails, the others are still available. If a cluster of a particular microservice fails, the rest of the system can continue, although possibly with diminished capability. With supervision and coordination, a system can even become self-healing by restarting failed microservices and clusters without human intervention.
The remaining topics discuss each of these briefly in the context of reactive microservices.
On complexity: “… even something really complicated becomes easy if you practice it for a long time, such as knowing deep internals … of a very complex system you’ve been working on for the last 10 years. The fact that something is easy for you now does not make it any simpler than it really is—it still is complex.”