Microservices have won major following from technology enthusiasts all over the world. A couple weeks ago I was giving an introduction to Spring Cloud at one of Scott Logic breakfast technical talks (techie brekkies). All the developers in the room were interested and could see number of benefits and challenges with this, still rather new, approach. At the end of the session, during the question time I was asked by one of the business people in the room- “So, what is the business case for this, what business problem does it solve?”. It is easy to provide a few answers about scalability and maintainability of microservices, but I don’t think that speaks clearly to our business people. In this article I will look deeper into the business benefits provided by investing into microservices architecture.
Before going right into benefits and the business case, a word of caution. Microservices can be done wrong, IT projects often fail. If anything, microservices can be more complicated than the more traditional approaches. In this article I will not be examining this problem too much, and assume that after due diligence, microservices approach was suggested as a viable option by the engineers. So, given that you can chose microservices and they are recommended as a reasonable approach, what benefits for business do you get by choosing this new approach?
Microservices architecture is build around the open source proposition
The first and quite a big benefit is that this is all free! Most microservices frameworks (like Spring Cloud for example) are build around Open Source platforms and ideology. I don’t think I need to go on explaining here why Open Source is great for everyone, including businesses. Moreover, this is not the kind of Open Source that nobody maintains and there is no Enterprise Support available if there is a need for it. Companies like Pivotal (creators of Spring Cloud) or Lightbend (responsible for Lagom) provide Enterprise grade support for their product. There are many others if you chose different frameworks/platforms.
I am sure that no one enjoys paying huge amount of money for complicated application servers and databases that are supposed to make all our problems disappear. The great news is that you really don’t need that anymore. Microservices are not only build on Open Source, but they are also proven at an enterprise and Internet scale.
If you actually have budget to spend some money regardless, it is better to utilize it into hiring more people instead or investing in training your own workforce. Microservices are still quite new and not everyone has knowledge or experience in this area. If you already have microservices ready people, you could invest in development tools or more modern workstations instead- now you have the options!
Microservices enable business to better utilize infrastructure and save money
This business benefit is also all about money… But there is more to it than most people realize at first. There is of course a lot of money to be saved from not spending money on servers that sit idle all the time, only being utilized to their maximum for 10% of running time or less. With microservices being much more light-weight and scaling usually being much easier, there is no need to provision so much power up-front. As the service is seeing more use- more instances can be created. Simple as that.
When dealing with traditional monoliths, there is another problem- often this rapid scalability is not available. Here, the loss of money can be even greater! Imagine your software has a sudden spike in demand and you not only can’t deal with all this extra business (and extra profit), but potentially your whole solution stops performing. Here, a product/marketing success may turn into business disaster with even the basic levels of service not available. Instead of doubling the profit, you stand at a risk of losing everything and ending up with a tarnished reputation.
This automatic scalability often depends on having cloud-deployment capabilities. If you are not deployed on the cloud and can’t rapidly provision new hardware, you may still benefit from it. Because of the way microservices fraction the whole system, you could identify the underutilized parts of the system and scale them down, freeing the capacity for the service under stress.
Microservices help to achieve the agility that is a goal for so many organizations
When talking here about agility I mean more than simply running the agile development process (although this is a part of it). For many organizations, being able to dynamically respond to changes in the marketplace and implement ideas faster than competition is absolutely crucial for their long term survival. Lets have a look how microservices help foster these two types of agility:
- Development Agility: Running development teams in an agile fashion is good for business, no questions about that. It is also incredibly hard to have any sort of development agility when 80 people work on the same software component. This is how it often looks when dealing with monoliths. Sure, it can work, but how wasteful can it be! We have all seen smaller teams achieve feats that were impossible to achieve by teams multiple time the size. It is enough to look at multiple startups that regularly disrupt different businesses with their new products. How can you have the best of both worlds? Assuming that you can actually afford amazing 80 people to work on your project- split them into smaller teams (lets say 10 teams of 8 people) and give them full responsibility of implementing their own service (or services). If you can manage this well (and it is not that easy!) you may have the power of multiple startups working in harmony with a strong business behind them. It seems that nothing should be impossible with this setup!
- Product Agility: Innovating and introducing new products and offerings is key to a long term success in business. I have seen multiple companies built around a large product that is getting older, larger and more difficult to change every year. It can be extremely dangerous for a company to find themselves in such position. With microservices you leave yourself a way out. Changing a 1,000,000+ lines of code sized monolith can become near impossible. Changing a microservice that has well defined contracts- now, this is something that can be done! With microservices it is easier to continue changing and innovating, as the coupling between your services is genuinely low. From the strategic perspective for a company, this should be an important point.
Microservices help to recruit and retain talent
Companies are built by people. Usually, the more motivated, talented and experienced your people are- the better the business outcomes. Of course there are other factors at play, but a great company that loses all good people often ends up in troubles and a troubled company that has amazing staff, usually lives to fight another day. Why would you not want the best people you can get? Here are the reasons why microservices attract good engineers:
- Independent services mean that developers often have a real impact and responsibility with the work they produce
- They are usually making use of a modern technology that is pleasant to work with
- The code produced is often cleaner and easier to work with
- Devops culture is a great and rewarding way of working- it usually comes with microservices
- Other industry leaders are already doing this and good people attract more good people
- There is always more to learn- this is a very active space that is already good and mature and is only getting better
Beyond these points, if you are going to introduce microservices, make sure that your working-culture is devops oriented. Without the devops culture, which I understand by teams being responsible for the service all the way from source-code to production deployment, you may find it difficult to succeed. The independence and responsibility are not really optional here, they are a requirement for high performing microservices teams. To really understand what I am talking about here, have a look at The Devops Handbook.
In short, if you are recruiting people and you mention that your company is doing microservices, prepare for a lot of interest. Also, be ready to answer some technical questions as the curiosity of your candidates spike!
Some of the largest companies out there use them, they are likely the future
The last important point here is that this is not a proof of concept. By going with microservices, you are going in the direction the industry leaders are taking- Netflix, Ebay, Amazon- to name just a few. Some of the world most successful companies are going this way. Super successful startups, and established brands alike. By choosing microservices you are not embarking on a lonely journey, but rather join the group of industry leaders pushing further how fast and how well products and services can be build and maintained.
This is a sensible choice, but more than that- it is a future proof choice. If different technologies emerge and new trends in Software Architecture become the norm, you are in a position to take advantage of them. As mentioned earlier, with microservices you leave yourself an option to always change. This is a rare opportunity for a company to both chose something that is modern, but also proved all over the world on different scales.
Summary
Be under no illusion- implementing microservices may not be easy. This article does not claim that. Software development is never easy in the real world. What this article is trying to do is to showcase why businesses should take a good look at microservices when considering where they want to go strategically. We are still in relatively early days, but microservices are already mainstream. Not everyone is reaping the benefits of this new paradigm. If you are given a chance to steer your company in this direction, if you have people ready to embark on the challenge- the rewards are great.
I can see microservices being a just another kind of architecture (with especially not new concepts) embracing distributed communication. But it should be recommended to at most circa 5% of projects otherwise its overengineering, most of the projects don’t need it.
To comment some point from your article:
“If anything, microservices can be more complicated than the more traditional approaches”.
They will be much more complicated because it is about distributed programming and distributed programming is difficult. In addition to business logic you have to handle remote communication (REST and messaging), handle remote exception handling, retries and circuit breakers, handle eventual consitency, split your data store into many small pieces. You will have to merge distributed logs and trace your invocations with correlation ids, deal with messages ordering and so on. It’s very unfamiliar to average programmer and very error prone.
“Microservices architecture is build around the open source proposition”
Open source shouldn’t be accounted to microservices. These days you can write almost any architecture with great open source tools with enterprise grade support. There is nothing special here in microservices.
“There is of course a lot of money to be saved from not spending money on servers that sit idle all the time, only being utilized to their maximum for 10% of running time or less”
It sounds like a sales person argument. If you have server utilized in 10%, it’s badly managed and
IT architecture is not planned well and you should fire your administrator. I don’t find situations like these in real world companies. It would more reasonable to argue that you could get rid of most of your admin team, but then you should have really good skilled devops people, including your programmers (still quite rare).
“When dealing with traditional monoliths, there is another problem- often this rapid scalability is not available.”
The question is who (what kind of project?) really needs rapid scalability, what could be the reason to rapidly scale?
I guess when you say “traditional monolith” you mean “big ball of mud monolith”. You can have
well written monolith with DDD apprach, and then extracting specific Bounded Context to some kind of “microservice” to scale better shouldn’t be a problem, without the need to have the whole system being architected as microservices.
On the other hand you can also have distributed big ball of mud monolith, with spaghetti of microservices, what I find very often when teams get attracted with microservices buzz and use it without much reflection. It’s even worse than in monolith case.
“By going with microservices, you are going in the direction the industry leaders are taking- Netflix, Ebay, Amazon- to name just a few”
Sorry, but this is very poor arguments.
It should be treated as a warning: Netflix, Ebay and Amazon, Allegro need such kind of architecture because they process hundred kilos request per second from outside world. Is your system somewhere around? At least 95% of current commercially developed systems are not. So stay away from microservices as a architecture for whole system, it will be just another CV-toy that will ruin many next years of developers lives working with the system.
Microservices should be last step of your architecture evolution, only if you deal with extremely high levels of requests hitting your system. (I find teams doing microservices for systems having 200 users, ugh). Start from monolith, invest in good desing (eg. with DDD approach), then going do microservices can be done with reasonable effort, not having to change everything, and only there, where needed.
Of course it doesn’t mean that microservices are bad. They are very vital, when distribution and availability is essential and can’t be achieved with traditional approaches. It’s just an architectural style, like many others and be careful before you choose one.
And please don’t do microservices because they are mainstream. They aren’t. They are marketted very loudly so they seem to be mainstream. It’s selling voice supporting a new market for tools and consultancy services.
Thank you for your very well reasoned comment!
I guess we are also biased by the kind of systems that we end up working with. With most of my clients being national scale or larger, microservices do not feel like an over-engineering. Maybe I should have been more specific about what kind of client this business case is targeting? They certainly do seem like a mainstream option when discussing large projects with enterprise clients (but it could be statistical error, I agree).
About scalability- yeah, when talking about traditional monoliths I might have been equating them either to “big ball of mud”, or just general, heavily coupled deployment that can take very long time to start and does not scale well (not well implemented SOA). If you are not facing these problems and your system runs well- absolutely no need to rewrite. In general in many cases it is safer to start with a monolith (especially if your problem is medium-small).
One point that I do not agree that microservices only make sense for really large companies. Last week I have been speaking on a meetup where representatives of two other companies (RightMove and Tidal) spoke about their experience with microservices. They were very positive and had tangible benefits from that re-factoring. https://www.meetup.com/JVM-Roundabout/events/247187636/ – I will add a blog post once videos from the meetup are available. I have seen quite a few other cases where microservices were successful on systems with only a few hundred thousands users.
One of the drawbacks that you mentioned I agree 100% with:
“On the other hand you can also have distributed big ball of mud monolith, with spaghetti of microservices, what I find very often when teams get attracted with microservices buzz and use it without much reflection. It’s even worse than in monolith case.” I even wrote the “Common technical debt in microservices” based on some of the bad implementations I had a “pleasure” to see or hear about when talking with my colleagues.
Again, with this architecture still being quite new, there are multiple opinions on how to do it well and if we should be doing microservices at all. Thanks again for your very well reasoned post, as it adds the side of the story that was not included- risks and challenges.