Just imagine: 90% of all new apps will use microservices by 2022. Well, maybe that number is slightly exaggerated, but even so, you can’t ignore it.
The fuss around microservices raises a series of questions I’ve faced as a software engineer when assisting business owners with finding the best solutions for their projects and when developing microservices-based applications. If you also need some clarification, here’s my list of top five frequently asked questions (FAQs) - with the answers drawn from my personal experience and deep research.
What makes microservices so popular?
To some degree, the technology owes its popularity to Netflix that started migrating from a traditional monolithic datacenter to cloud-based microservices as far back as 2009. At that time the term ‘microservices’ didn’t even exist - the word was coined in 2012 and became widely used in 2014, after Adrian Cockcroft publicly shared his experience as a cloud architect at Netflix. ‘A service-oriented architecture composed of loosely coupled elements that have bounded contexts’ is how Mr. Cockroft defined the new model.
Today, Netflix wins Oscars and entertains roughly 137 million subscribers worldwide. Obviously, such an impressive expansion would not have been possible without microservices working to stream digital content to millions of viewers 24/7. Tech giants like Amazon, eBay, Twitter, Uber, and PayPal have followed the path taken by Netflix, with their stories of success inspiring others.
How can microservices help businesses succeed?
Loosely coupled elements, mentioned by Adrian Cockroft, give organizations a strong foundation for consistent growth. Contrary to the classic monolith approach, loose coupling allows you to develop, test, release, deploy, integrate, maintain, and update each of the services separately, without making changes to the rest of your code.
In other words, every single part of your system acts as an independent business unit that runs specific processes. For example, if you want to build a restaurant app with microservices, it means that every functional part (restaurant management, menu listing, order management, payment system, etc) will have its own lifecycle and ecosystem.
What are the actual benefits of such an approach?
1) More productive development. In the microservices ecosystem, each product team focuses on a particular isolated module, following the well-known Amazon principle ‘You build it, you run it’. Smaller services can be developed faster, while one team doesn’t wait for another to release their part of the code.
2) Faster scaling and shorter time to market. You can add new services or update and scale the existing ones on demand, without impacting the entire system. Releases of new features are faster and less risky as you don’t need to redeploy the whole application and there will be no downtime.
3) Better quality of separate parts. It’s easier to find and eliminate bugs in the isolated pieces of code than to search for a source of failures in a huge monolithic application. What is even more important, if something breaks in one module and the particular service fail, in most cases the entire system will continue to function.
4) More flexibility regarding technologies. You may build one service with Java, another with JavaScript, and then switch to Python - depending on the expertise of available engineers and the requirements of the particular module. Development teams have the freedom to select a new stack for each new microservice.
5) Reusability. Small services like login systems or file uploaders can be shared within the company.
Are microservices really ‘micro’?
Actually, they vary greatly in size. As Martin Fowler, a guru of enterprise software design, explains it, “microservices is a label, not a description”.
Sometimes, a small microservice is designed, deployed, and supported by one person. However, a great number of tiny components can result in undesirable (and unnecessary) project complexity. Typically, the team size working on one service should be six to eight specialists, which fits Amazon’s definition of a Two Pizza Team (a group that can be fed by two pizzas).
Why can microservices turn into a nightmare?
You already know how small services help large companies become huge and powerful, but it’s also widely known that ‘With great power comes great responsibility’. The idea voiced at different times by Winston Churchill, Franklin Roosevelt, and Spider-Man, is still relevant to modern technologies.
The set of great responsibilities imposed by microservices include the following:
1) Company re-organization. Migrating to microservices entails the global change of the whole business culture and structure. Instead of tightly shackled departments, you need to create autonomous ‘build-and-run’ teams that have full ownership over the lifecycle of the microservice from development to deployment. Such decentralization takes time and doesn’t pay off in all cases. Also, it’s not always easy to teach a team to be agile, independent, and responsible.
2) Managing multiple independent units. You can consider good microservices-based software as an ant colony with every member working independently, but towards a common purpose. Yet unlike insects, pieces of code don’t have inborn instincts dictating the right behavior. Hundreds of individual parts may become a total nightmare if not properly organized, deployed and managed. You need a high level of expertise to think out the architecture from the start and construct a robust system out of loosely coupled elements.
There are modern open-source solutions (e.g., Kubernetes) that help to orchestrate microservices and monitor and scale them. However, companies using the Kubernetes environment still face a wide range of challenges relating to:
- security (46%);
- networking (42%);
- storage (41%);
- monitoring (38%);
- complexity (37%).
3) Handling communication among microservices. To act as a single well-established mechanism, microservices need to interact with each other over HTTP REST APIs (synchronous communication models) or message queue services (asynchronous communication models). This constant ‘talking’ leads to poorer performance because of network latency and the time required to process messages. You should carefully select the type of flow to mitigate disadvantages. While the asynchronous approach is more complex, it benefits from lower latency.
4) High risk of failure. The growing number of components interacting through networks creates more points where things can go wrong.
5) Support issues. With the microservices architecture, you have dozens or even hundreds of fragments, living in different environments and using different languages, APIs, databases, config files, etc. Such diversity makes it tricky to support the application. And yes, in an ideal world, changes to a microservice shouldn’t impact other independent components. Yet in practice, an update in one place sometimes requires a re-build of several services at once to preserve their compatibility.
Do you really need microservices right now?
The answer depends on your business ambitions and the actual size of your company. In spite of all challenges, microservices architecture is proved to be a great solution for enterprises, large departments, or business units that provide a huge number of services. The ability to scale fast and make quick customer-driven changes brings a significant competitive advantage.
However, if you manage a small company and want to build a simple business solution or plan a quick launch to validate your business idea, the classic monolithic approach will fit your goals better.
The biggest mistake is to buy into the hype and go with a popular technology blindly, just because everybody talks about its great future. Even famous advocates of microservices advise caution and acknowledge that microservices pay back only when your system is so large that it starts falling apart under its own weight. Otherwise, stick to the monolithic architecture with good modularity - not the separate services - within it.
Top comments (1)
Great post! I already have an SOA-ish architecture with a few dozen services, some fairly large, some small... All try to encapsulate a specific business function. They use HTTP and RMQ to communicate.
I've been trying to determine how to move to microservices, thinking I need to figure out how to make the services smaller. But maybe that's not the point, I should break them up when I reach the point that I see an obvious seam to break on?
So don't take a business requirement and try to determine how many services I can turn it into, but determine how few services I can turn it into and then add more when necessary?
That seems to make sense to me.
Instead maybe I'll focus my efforts on migrating our existing services to Docker and Kubernetes or Service Fabric to get our system into an easier place to deploy, manage, and debug. Which would also make it easier to break up existing services when I need to.
Any thoughts?
Thanks!