How to make “just right” easier with microservices
Discover balance in polyglotism, persistence, and immutability.
Pendulum (source: Pixabay)
With microservices taking the software industry by storm, traditional enterprises are forced to re-think what they’ve been doing for almost a decade. We’ve seen software design paradigms change over time along with the evolution of project management methodologies. Old hands might see this as another wave that will gently find it’s way to the shore of daily business, but this time it looks like the influence is bigger than anything we’ve seen before. The interesting part is that microservices aren’t new.
Compartmentalization and introducing modules are core skills for architects. The software industry has learned how to couple services and build them around organizational capabilities. What’s new in microservices-based architectures is the way truly independent services are distributed and connected back together. Building an individual service is easy with all technologies. Building a system out of many services is the real challenge, because it introduces us to the problem space of distributed systems.
Learn faster. Dig deeper. See farther.
Single responsibility—fully contained
Enterprise developers have thought in terms of specifications and built their implementations inside containers without caring too much about their individual life cycle. Hooking into startup and shutdown events was easy, and accessing other components was just an injected instance away. The base platform or framework of choice made it comparably easy to map our objects into relational databases or connect to other systems via messaging. The best part of all of this was the transactionality, which can be easily achieved. What was built as a means to support developer convenience very easily led to applications that violate the core principles of microservices as outlined in Jonas Bonér’s Reactive Microservices Architecture.
While traditional application servers offer a lot of features, they don’t offer what a distributed microservices-based system really needs. Using standard platform APIs and application servers can only be viable if you scale both the application server and database for each deployed service, and invest heavily to use asynchronous communication as much as possible. This still puts you back into the 1990s with CORBA, J2EE, and distributed objects. You’re still going to miss many parts of the so-called outer architecture like service discovery, orchestration, configuration, and monitoring. What made life easier for developers in a monolithic application design environment has incredible drawbacks for more modern architectures.
Just right for microservices
The hunt for the perfect microservices framework has started. Instead of operating too much of what nobody needs, the ideal combination of relevant features with as little overhead as possible would be the “just right” fit. This is where the recently released Lagom Framework puts its emphasis. Lagom is an open source framework for creating microservices-based systems. It offers four main features:
- A Service API that provides a way to declare and implement service interfaces, to be consumed by clients.
- A Persistence API that offers event-sourced persistent entities for services that store data, with Command Query Responsibility Segregation (CQRS) read-side support for queries.
- A development environment that runs all your services, and the supporting Lagom infrastructure, with one command.
- Services that can be deployed, as they are, directly to production using ConductR, a reactive application manager.
Polyglot systems with microservices
The main anchor point to today’s discussion around microservices-based systems is their ability to free enterprises from vendor lock-in by offering a polyglot approach. Instead of being forced to use the single, available technology, which has been put down as a blueprint, those architectures foster the adoption of “using the right tool for the right job.” Without limiting it to middleware, even. Being able to use various communication protocols is key. And Lagom doesn’t make an exception. The framework offers a seamless experience when multiple Lagom services are talking to each other.
Getting data transportation and storage right
While it sounds comparably easy to separate services according to their bounded contexts, the most challenging part in enterprise applications is persistence. Especially coming from brown field developments, the separation of an existing database into service domains requires thoroughness, know-how, and knowledge of the application domain. Even if you put all these efforts into it, you will quickly notice that the traditional way of service interaction and data access (e.g. JDBC) doesn’t scale well enough in highly distributed applications.
With microservices, the key concept of immutability plays a very important role. Lagom makes heavy use of immutable values to represent commands, events, and states because it encourages users to implement microservices-based systems with an event-sourced architecture. Event sourcing (ES) and Command Query Responsibility Segregation (CQRS) are frequently mentioned together. Although neither one necessarily implies the other, they do complement each other. The main conceptual difference for event-sourced architectures is that changes are captured as immutable facts of things that have happened. For example: “the flight was booked by Markus.” All events are stored and the current state can be derived from the events.
Even if CQRS feels unfamiliar to you at first, it is the best fit for microservices architectures. With Lagom you can implement your services with whatever data store solution you like. However, asynchronous APIs achieve best scalability. If you are using blocking APIs, such as JDBC or JPA, carefully manage the blocking by using dedicated thread pools of fixed or limited size for components that call those blocking APIs. Never cascade the blocking through multiple asynchronous calls, like Service API calls.
For more information about Lightbend’s (formerly Typesafe’s) open source microservices framework Lagom, visit the Lightbend website.
This post is a collaboration between O’Reilly and Lightbend. See our statement of editorial independence.