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, Lightbend recommends 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. Lightbend’s Reactive 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:
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. For a more comprehensive discussion, watch this webinar on The 6 Traits 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.”
From Why Reactive by Konrad Malawski.Next up → Reactive Microservices
In less than 15 minutes:
In less than an hour:
Really dig in: