You have probably heard the following sentences numerous times: Microservices are the future of software. Monoliths are nasty. You should migrate. Netflix is doing it, Amazon is doing it, Spotify is doing it. Lists of benefits littered with words like agility, performance, high availability, lower costs, agility, faster time-to-market… Oh wait, have I mentioned agility?
It sounds good on paper or when Business Managers and Cloud Evangelists say it, but what are the actual reasons behind all that chatter? Let’s revisit the common bullet points on the microservices benefits lists and dive a little bit deeper into each one. But first, we need to get a good grasp of the subject at hand.
What Are Microservices All About?
What is a microservices architecture to begin with? Often discussed in opposition to monolithic architectures, (where a single gargantuan application does everything), microservices is a software architecture style based on a large number of loosely coupled, small, independent applications, which are assigned their own specific jobs. Connected together, they constitute a system that is sophisticated yet scalable, efficient, reliable, and easy to work with. In order to create or move to such an architecture, we need to have a decent level of automated infrastructure that allows us to rapidly provision computing resources, to deploy applications, and to closely monitor their behaviour in the production environment. The Cloud and container orchestration are tools that are very helpful in that regard. Sounds interesting? Moving on to the benefits of such a solution with more details then.
1 & 2 – Fast Releases and Innovation
Non-trivial monolithic software systems, with many development teams, often pose challenges when it comes to quickly releasing new features. Most of us have been there at some point. It’s that place where the release is a complicated process that takes lots of time, sometimes renders the whole system unavailable for hours, carries many risks, requires some deeply hidden lore unavailable for mere mortals, and is performed once a month or even less frequently. With microservices, we have a lot of tiny applications, owned by small and independent teams. We don’t need to synchronise releases across the organisation and thanks to an automated infrastructure, we are able to push changes to the production environment within minutes, not weeks. It is also much easier to rollback faulty updates, which allows us to go even faster without compromising user experience. Business assumptions and priorities may be very dynamic nowadays, but technology is now able to keep up and enables us to grab opportunities as they arise.
3 & 4 – Ease of Development and Quality
The larger the monolithic system grows, the more rapid development slows down and it requires more programmers. The more programmers we have, the more likely it is that we will run into conflicts regarding the code, the version of required libraries, frameworks, and common parts. Technical debt starts to crawl into the codebase, dependencies multiply, it becomes harder and harder to keep the structure and comprehend the logic while the risk of unpredictable side effects popping up here and there increases. Microservices are all about a bounded business context and the single responsibility principle, where we keep everything we need to perform a single, well-defined task in one place – this way, in case we have to change something, we know exactly where to look. We physically isolate portions of code and communicate with other modules via well-defined network interfaces, which helps to keep things simple. We can reuse components in many places saving effort and eliminating duplications. Thanks to powerful and accessible monitoring tools, we can keep an eye on how the code behaves in the production environment so we are able to adjust it accordingly. Work is easier and much more fruitful.
5 & 6 – High Availability and Fault Tolerance
Hardware fails because the network is unreliable, hard drives become corrupted, processors short-circuit and power gets lost. Software fails because of a myriad of reasons too. When it comes to monoliths, a single failure may bring the entire system down. Microservices architecture is built according to the philosophy of failure tolerance – it’s easy to deploy redundant components that will take over in case problems arise. We have plenty of tools at our disposal that allow us to handle failure gracefully and enable us to recover from it automatically – and even if some small part of the system becomes corrupted, we can just ignore it for a moment and continue with the main business flow. With automated infrastructure, we don’t care much about random hardware failures; we just lazily observe orchestration tools that spin a new unit of deployment or a virtual machine for us and carry on. In terms of software problems, services are equipped with health checks that automatically bring down the ones that misbehave and replace them with fresh instances, (we can analyse the causes post factum). It is also much faster to restart a small service, (as opposed to an entire monolith), which greatly increases the availability of the system. And finally, we make small changes very often, on isolated pieces of code that a small team controls and knows well, thus the risk of critical failures diminishes greatly.
7 & 8 – Scalability and Cost Optimisation
Some parts of the system are used more often than other parts. When traffic increases, we don’t have to roll out additional instances of the entire monolith – we only have to handle a small portion of the functionality. We can differentiate the number of particular services so that they will be able to match exact demand, adjusting to changes in daily or seasonal traffic automatically. As parts of the system are highly decoupled, we avoid the single point of failures that often become performance bottlenecks and prevent us from scaling beyond the limits of what a single powerful server can offer. We are encouraged to use Cloud Managed Services, which releases us from much of the burdens associated with maintaining and hosting databases, messaging queues, storage, and other resources. Our applications may require various types of hardware to run efficiently – some need more raw processing power, others lots of fast memory, a strong graphics card, or even tensor processing units for AI-related activities. With monoliths, we sacrifice a lot of what modern hardware diversity has to offer, but it doesn’t have to be that way.
9 & 10 – Freedom of Technology and Shiny Things
There are no universal languages, frameworks, technologies, or techniques. Solving business challenges often requires tailored pieces of software, and we face many various challenges in our systems. An easy-to-use and ubiquitous web framework might not be well suited in high-frequency trading where each nanosecond counts. An huge and expensive relational database is not the only way to store data records and certain, less popular languages might fit particular domains better than the most commonly used languages on the market. With microservices, we are not tied to one particular technology. We can choose what suits us best each time and experiment a lot without much risk in order to discover new and better things; additionally, helping to move the entire engineering organisation forward with us. If something goes wrong, rewriting a service from scratch is not a big deal anymore; but the experience is invaluable. Taming bleeding edge technologies has an additional merit – that of attracting the best talents to the organisation, which nowadays, with the explosion of the insatiable software industry, is harder and harder.
Are Microservices Right for Me?
There are no silver bullets. But some bullets are, indeed, really good. If you want to build and evolve a non-trivial IT system with real potential, microservices architecture is probably something you should seriously look into. To execute it right, it requires some initial commitment but it will quickly pay off and enable you to introduce new features and to scale in a way that is basically impossible with classic software development paradigms. Microservices are not only an architecture – they are a mindset and an organisational philosophy that fits well with agile cross-functional teams and end-to-end responsibility.
Interested? Want to know more? Our Microservices Workshop can help you move forward on your journey to creating cloud-native applications with all their glory.