3 Things We Learnt from ‘Reactive Microservices Architecture’ | Voxxed

3 Things We Learnt from ‘Reactive Microservices Architecture’ | Voxxed:



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.”