The recent rebrand of Lightbend has made some considerable waves in the JVM-sphere – not the least because the traditionally Scala-centric company chose to debut Reactive Microservices framework Lagom as Java first. But language politics aside, the core story behind the creation of Lagom links to the Microservice evolution sweeping the industry, and how Lightbend as a company envisions what the core principles of Microservices should be. Following the launch of Lagom, O’Reilly has just published a report titled ‘Reactive Microservices Architecture: Design Principles for Distributed Systems,’ penned by company CTO and co-founder Jonas Bonér, which drills further into these principal ideas (register here to read it in full for free).
We had the chance to take a look ahead of the official release, and here are three interesting things we came away with:
The march towards Microservices isn’t just about technology
Bonér observes that the ideas encapsulated by the buzzy term Microservices actually predate the trend by quite some distance, and even outpace microservice fore-runner Service Oriented Architecture (SOA). In the past, however, Bonér writes, “Certain technical constraints held us back from taking the concepts embedded within the Microervices term to the next level: single machines running single core processors, slow networks, expensive disks, expensive RAM, and organizations structured as monoliths. Ideas such as organizing systems into well-defined components with a single responsibility are not new.” In 2016, with the advent of cheap RAM and multi-core processors, zippier networks and the dawn of the Cloud, systems can now be structured “with the customer in mind. As a result, “Microservices are more than a series of principles and technologies. They’re a way to approach the complex problem of systems design in a more empathetic way.”
Isolation is king in Microservices
For Bonér, isolation represents “the foundation for many of the high-level benefits in Microservices.” But, as Conway’s Law predicted in 1967, it’s also the trait that will most heavily influence your design and architecture, and will even influence how you divvy up your teams and responsibilities, given that any system you design will most like produce a design which structure mimics that of an organisation’s communication structure. With this in mind, you need to ensure that any failure can be contained and isolated “without having it cascade throughout the services participating in the workflow.” Isolation also prompts the natural rollout of Continuous Delivery for incremental changes on a service by service basis, and allows for easier scalability and monitoring.
REST in Microservices is definitely not Lightbend’s jam
Although for some REST has come to be considered as the de facto communication protocol by many for Microservices, this is not something Bonér would advocate. In fact, because REST tends to be synchronous, he sees it a “very unfitting default protocol for inter-service communication.” If you must use REST, try to limit it to a handful of services, or “situations between specific tightly coupled services.” And, Bonér adds starkly, “use it sparingly, outside the regular request/response cycle, knowing that it is always at the expense of decoupling, system evolution, scale and availability.”