Microservices architecture is both a trendy phrase and a genuine sea change in the way software is build. However, like everything in life and business, there are still drawbacks. In a recent article, we spoke about the key advantages of microservices but also touched on some situations when monoliths still make sense. Now we are going to look in more detail at a couple of hidden costs of microservices architecture and how to overcome those issues.
Before we get into the details, if you are a CTO or tech team leader looking at microservices for your next build, I’d like you to ask yourself a serious question: Why are you considering microservices architecture at all?
Why build with microservices?
What is that is drawing you to microservices? Perhaps your developers are talking about working with something new and shiny? Or maybe there was an article or some marketing material that presented it as the ultimate way of building the software of the future? Just to be clear, I’m a huge fan of this architecture and co-author of the book ‘Microservices Architecture for eCommerce‘. However, I’d still recommend doing a little diligence and questioning what you believe microservices can bring to your specific business before making the leap. And once you know the reasons, it’s worth looking at the real costs, some of which are perhaps not so obvious.
Monolithic architecture v microservices
One of the most popular arguments for getting into microservices architecture is that it can make the software easier to maintain by decomposing and decoupling it into smaller units.
Most monoliths are not well modularized and their features are not easy to test (unit testing, behavioral testing). It becomes difficult to deploy the changes because of the tight-coupling between the modules it’s quite easy to break some other features.
Amazon, Netflix, Coca Cola, Shopify and eBay are just some of the worlds biggest companies to start building in microservices or switch from monoliths. Read: 10 companies that implemented microservices architecture and paved the way for others
It’s worth noting that the problems with monoliths can be fixed without major re-architecting of your application. For example, Shopify started as a startup with a Ruby on Rails base and now they’re perhaps the only force in the world to compete with Amazon.
Ruby on Rails is well known for its flexibility with a “convention over configuration” approach that has just a few strict rules on designing the application. You can get results fast and it is a fun and productive way for developers to work. In fact, startups often choose Rails because they need to be fast, validate, and pivot. In essence, if Shopify had started with microservices architecture, complex deployment schemas, and complicated CI/devops processes, they may have failed.
Monolithic architecture is the easiest to implement. If no architecture is enforced, the result will likely be a monolith. This is especially true in Ruby on Rails, which lends itself nicely to building monoliths due to the global availability of all code at an application level. Monolithic architecture can take an application very far since it’s easy to build and allows teams to move very quickly in the beginning to get their product in front of customers earlier.
Source: Deconstructing the Monolith, Shopify blog
Maintaining the entire codebase in one place and deploying your application to a single place has many advantages. You’ll only need to maintain one repository, and be able to easily search and find all functionality in one folder. It also means only having to maintain one test and deployment pipeline, which, depending on the complexity of your application, may avoid a lot of overhead. These pipelines can be expensive to create, customize, and maintain because it takes concerted effort to ensure consistency across them all. Since all of the code is deployed in one application, the data can all live in a single shared database. Whenever a piece of data is needed, it’s a simple database query to retrieve it.
Shopify fixed the issues that monolithic architecture brought by investing a lot into better code organization, componentization, and hermetization. Components provide the closed interfaces the other modules can rely on and the whole deployment process is somehow automated and based on version control, semantic versioning, and these interface contracts.
Think about JavaScript npm packages. They’re developed by different teams, still – by having the proper version control and package managed they become the base of building and maintaining most sophisticated web applications of our times.
“No architecture is often the best architecture in the early days of a system […] It’s practical to trade off design quality for time to market. Once the speed at which you can add features and functionality begins to slow down, that’s when it’s time to invest in good design. The best time to refactor and re-architect is as late as possible, as you are constantly learning more about your system and business domain as you build. Designing a complex system of microservices before you have domain expertise is a risky move that too many software projects fall into.”
Source: Deconstructing the Monolith, Shopify blog
Read more about the differences between monolithic and microservices architecture in our in-depth analysis article: Monolithic architecture v microservices
Reasons to use microservices architecture
If you’ve considered a proper modularization and still want to go with microservices, it means you’ve probably identified a number of reasons why microservices are the best or only way for you to go.
Deployability is one major factor which gives freedom to your separate teams to release and test out new features without waiting for others to complete and integrate them. This is one of the reasons Kelly Goetsch gave during my interview with him in regards to why Oracle started microservices investments in early the 2000s.
Another advantage of microservices architecture is that components can be written in totally different languages, even using different tech stacks, but still be integrated by just HTTP/REST/GraphQL contracts.
You can find a lot of enterprise-grade services you can use for your application and save significant time by using top-notch enterprise products. You can also find a whole set of services starting with the wide portfolio of Amazon, Google, and Azure hyper-clouds and then leading to specialized platforms like commercetools and engines like Algolia (for search) and Nosto (for recommendation). This is what MACH architecture is all about and we’re strong supporters of the MACH Alliance which aims to show how businesses can benefit from open tech ecosystems that are Microservices based, API-first, Cloud-native SaaS and Headless..
The complexity of microservices implementation
The problem with the services you own is that you need to keep them up and running. If you’ve got a small team (say less than 20 developers), it can be challenging to maintain, deploy, monitor, and keep the 24/7 SLA for a few dozen services. You need to have a DevOps inside your team.
The developers working on the software you deploy usually won’t be ready and won’t like to be on the pager 24/7 having the SSH terminal always on ready to react for any kind of issue their service will face. You must ensure the proper error and failure handling, network traffic balancing and redundancy. Then the team need to be in charge of the whole thing 24/7
When building Storefront Cloud, it took us a good few weeks to organize the Level 1 and Level 2 application support and the SWAT team that provides the SLA for the infrastructure and the application, log monitoring, KPIs, and so on
Microservices development: what you use vs. what you own
If your next application is gonna be a modular, monolithic or microservices-based, it will use some services. The most important issue to resolve is which services you’d like to own and which you like to buy in order to keep out of the trouble and the hidden costs.
Having your application based on enterprise grade services—maintained and serviced by the provider—is a totally different situation to having your core business system fully decoupled and maintained by your team. I think that the power of the cloud computing is that you don’t have to take care of the details and can actually fully outsource the DevOps to the service provider.
The ownership problem is the key question to answer. The services businesses would like to have are the ones that make a difference for customers or are key to the business model. These change a lot; it may be the frontend application or the product configurator. They are usually the processes that are quite common and are not customized ones like invoicing, general ERP features, or WMS. These services increase your overall costs of ownership without giving back the proper business values. I’d recommend you to avoid owning these services and just integrate them altogether.
The hidden cost of microservices architecture
In the simplest definition, the hidden cost of microservices is the money spent to maintain a more dispersed system, and can be broken down into a few key areas:
- 1. DevOps team: You need a large group of people to set up a complex ecosystem, meaning the cost of getting started can be higher than with a monolith
- 2. SWAT team: You must have a few people to monitor and react on any issues at all times
- 3. Duplicated cost of changes: Because it is so broken into very granular micro services, even minor change requests can require you to change a number of services
- 4. Common resourcing mistakes: Taking ownership of the wrong types of services, which don’t bring back sufficient business value
Regardless of these facts, we’re still all in on microservices. It’s naive to believe that any single solution is free from drawbacks and that it will always be the best choice. The important thing is to understand what might be an issue for your business and to weight it up against the benefits. We truly believe that after that calculation, microservices will still be the best option in most cases, especially in the future as the entry point becomes easier.
In essence, the hidden costs of microservices architecture cannot be overcome but they can be planned for and minimized through careful resource management. They can also be offset to some extent by choosing the right time to turn to from a monolith to microservices.
If you want to assess if microservices are the best option for your new or existing eCommerce project, or if you are ready to build and need the right team, check out our microservices offers and contact our experts.
Published July 24, 2020
