With so many organisations claiming to do microservices, it’s time to re-examine. Let's explore the principles of microservices and how the mindset transcends specific technology choices of the moment. It's more about people and change than it is about technology.
Microservices is no longer new and shiny. Maybe it never was - it being a term coined in the early 2010s to describe an emerging set of common architectural characteristics, a kind of “lightweight” Service Oriented Architecture. Many organisations, following the lead of pioneers such as Netflix or independently, were doing it long before it had a name.
A few years down the line, with the explosive growth of cloud computing and the convergence on enabling technologies such as Kubernetes - and in particular the availability of such platforms as managed services in the cloud - the barrier to entry to this architectural style has lowered dramatically, contributing to its increasing popularity.
Now that microservices is a thing, with so many organisations claiming to do it or aspiring to, it’s time to re-examine: What is it really? What advantages do we hope to gain and at what cost? Under what conditions is it right? Is it still the future?
This post is about my own opinions, formed from my own experience. I am fortunate to have witnessed the evolution of a system and engineering team on a more than 10 year journey, before, through and after taking the microservices approach.
In my view microservices is not an architectural blueprint for the perfectly optimised system. It’s not about REST APIs or containers. Rather it is a loose set of principles, aimed at supporting and arguably depending upon a certain software engineering culture. Its benefits pay off in the long term, for systems that must be continuously adapted while they run, to exploit emerging opportunities and respond to the unexpected challenges of business.
Microservices is therefore more about people and change than about any specific technology.
From the technical architecture point of view, I would summarise the microservices approach with the following set of principles:
Small is of course a relative thing. In terms of code, in my experience some might be simple enough to have only 10s of lines of meaningful logic, but generally 100s or 1000s and probably not 100s of thousands. That said, lines of code is an imperfect measure of complexity. Every case is different, and it depends on the language and style of implementation as well as what the code is actually doing. The important point of course is separation of concerns: break a large multi-faceted system into smaller parts.
The separation of concerns into microservices is unlike traditional n-tier architecture where decomposition is based on layers of technical abstraction - validation tier, business tier, data access tier for example - although internally, each service may indeed be structured along those lines. What functional area really means is highly dependent on context. It could be business domains, or groups of closely related features.
Independently deployable means that each service runs in separate processes, often on separate host machines although not necessarily so. This means they can be stopped, updated and started independently, but of course does not necessarily mean they have no dependencies on other services to get their actual work done.
Microservices are so often associated with REST APIs that one would be forgiven for believing these things are synonymous. Simple HTTP request and response mechanisms with JSON bodies, such as in the RESTful approach, are a popular choice, owing in part to their accessibility to browser technology. The main point though is to prefer mechanisms that are ubiquitous or simple enough to implement that they don’t tie to a specific platform or runtime. This is in contrast with platform-specific remote procedure mechanisms such as Java RMI or .NET Remoting. Even “Web Services” standardisation attempts such as SOAP suffered ultimately from diverging implementations causing compatibility issues.
REST is a fine choice for many scenarios, but there are many cases where other communication mechanisms are a better fit for requirements. In my experience REST is commonly mixed with one or more asynchronous messaging mechanisms - for example queues, publish/subscribe. Event-driven and streaming approaches are increasingly popular and worthy of discussion beyond the scope of this post. The main principle remains: keep the means of communication as simple as possible for the sake of broad compatibility.
Let’s make the assumption that in our system the storage of some kind of data is inevitable. Given that we decompose the system by business domain area, this means broadly speaking each service is responsible for dealing with distinct parts of the overall data. Sharing data stores between services should be avoided to reduce coupling, so that each service’s data schema may evolve independently.
It has become very common to use a variety of storage mechanisms across an overall system to best meet the functional and nonfunctional requirements of its features - for example a mix of relational databases, key/value stores such as DynamoDb, and search indexes such as ElasticSearch. This idea is sometimes referred to as polyglot persistence. The use of more than one type of storage is not of course a prerequisite of microservices, but the decomposition supports making that choice independently in each part of the system, as well as retaining loose coupling.
By definition one system cannot be decomposed into separate parts that have literally no dependencies on each other. The parts must work together to perform a useful function. In microservices this means features generally involve multiple services. We’ve discussed the mechanisms of communication above, but what of the coordination, or flow, of work across the system?
The microservices approach advocates that it is the services themselves that perform such coordination, as opposed to the alternative that this is centralised into some kind of service orchestration platform. The idea, dubbed “smart endpoints, dumb pipes”, is that all business logic, even high-level workflow, belongs in the implementation of services, not in the mechanisms that provide the infrastructure for communication. This is one way in which the microservices approach distinguishes itself from Service Oriented Architecture, where often some kind of configurable middleware system such as an Enterprise Service Bus provides capabilities like data transformation and routing of client requests to appropriate services. In practice this means finding new ways to solve the issues that such platforms attempt to abstract out, such as for example the handling of exceptions, or the monitoring of communication between services. The core idea, just like services managing their own data, is decentralisation.
For a more thorough description of the microservices style and its origins as perceived back in 2014, I recommend Martin Fowler’s microservices paper.
As the HR tech market is booming, experts in the industry share their insight at the biggest HR tech conferences in 2020.
HR tech is nowadays common in most enterprises, growing faster than ever. Find out what drives this market and why it is worth exploring.
Remote Check-Ins, AI, Apps: Tech-Enabled Recovery Strategies for Hotels. Technology is ever-evolving and so are user expectations. Technology is also a key element hotels can use to stand out from the crowd, to better assist their guests, and increase revenue. Sales are a key area in which hotels are always on the lookout for innovative methods to increase their profits.
Berlin is a budding HR tech hub with a growing pool of startups. We’re exploring 10 inspiring Berlin startups and their tech stacks.
Today was a not so good day at work.I’ve had better days. The issue itself isn’t even regarding my day-to-day work with clients or my immediate team. The issue is regarding how one of the largest technology companies in the world fails to understand and account for my personal living situation, during COVID-19. But that’s a whole different story, for another time.