Recently, the engineering team behind Prime Video has announced moving away from their microservices and serverless architecture to a more monolithic approach. This news has sparked a lot of outcry on social media. Many are rejoicing and announcing the "death of the microservices era". Some are using this news to voice their growing frustration towards microservices and the ever increasing complexity in software development. So, could it really be the end of an era?
Microservices, and more largely, Service Oriented Architecture is not something recent. The idea of Service Oriented Architecture was to architect applications per business function rather than technical function. Instead of having a 3 factor application where your software would be divided into a User Interface layer, a business logic layer and a database layer, you would combine those layers together. The new boundary of your application would then be the business function of the application. This new architecture came with the freedom to build cross-functional teams that reduce knowledge silos and to reduce cross-team dependencies while building new features.
Posterior to that, a revolution rocked the IT industry. Cloud Computing started to become a mainstream thing. It offered cheap and accessible computing at the click of a finger with promises of infinite scalability and high availability. Anyone with little to no IT skills could now deploy their application to a Cloud platform in mere seconds for the world to see.
Microservices and Cloud were matches made in heaven. We could stretch the concept of Service Oriented Architecture to functionality bound, independently deployable artefacts thanks to the massive scalability capacities of the cloud platforms. Engineering teams could be scaled massively and work independently on their own services. Those services could then be deployed as independent units of compute without a need to align with other teams. Such promises brought a lot of hope in the industry, especially for companies that were stuck in an unmanageable amount of technical debt. But with the hope came the hype.
If there is one thing that social media excels at, it's creating the fear of missing out. Software development is no exception to the rule. Continuously, new hypes are emerging. Whether it is a new framework or tool, those media will let you think that you'll be left behind if you don't hop onto the train. Strong of some success stories, microservices became one of those hypes. For developers, it was the opportunity to work on bleeding edge technologies and be part of the change. For companies, it was the opportunity to solve their development bottlenecks, reduce their technical debt, and attract new talents. But many people forgot something fundamental along the way. Microservices and Service Oriented Architecture are just one archetype amongst many others. More importantly, in software architecture, there isn't a one fit-all solution, and this leads to two problems.
Firstly, some companies that didn't need microservices (or could have satisfied themselves with pseudo microservices) are spending countless engineering time and money in building a complex microservices architecture instead of focusing on their core businesses. I have personally worked in such companies were it was very unlikely to see a sudden burst in scalability or maintainability need. Yet, we spent months (and increasing AWS bills) building complex solutions that may or may not be needed one day, and that could have been a simple method call coupled with a rudimentary alerting mechanism at first.
This problematic can lead to some frustration on the business side because business needs can be delayed for the sake of planning for (potential) scalability needs, amongst other things. Some developers might also grow frustrated because they might rather spend their time on tangible work, like building new features, rather than more abstract work like designing fault tolerant and scalable microservices systems.
The second issue is that some companies that might need microservices pour all of their resources into a complete architecture and software refactoring, hoping to solve all of their problems at once. Unfortunately, such projects often end up failing. I've worked on such projects where a new GitHub organisation was created with hundreds of repositories at once. Those projects usually take years to achieve and involve countless of projects managers, POs, and hundreds of engineers. Managers who usually have the bigger picture in mind often come and go. Dependencies are often created during development, and tensions between teams are common. Engineers often work on very small and abstract pieces of software that can lead to a loss of work meaningfulness. Projects are very often and continuously delayed. Many times, the top management grows tired of the lack of results and pulls the plug. In the end, nobody is happy.
So, does it still make sense to use microservices? Shouldn't we find a simpler way of solving our SDLC and architecture bottlenecks? In my opinion, thinking that microservices are a mistake is as wrong as thinking that they should be used everywhere. The reality lies in between. I think that many companies don't need microservices, especially at the beginning. There is a critical mass under which microservices are overkill. Be it based on the amount of services, features, their complexities, number of lines of code, or amount of engineers working on the codebase should be left at the appreciation of experience and guts feeling. Most likely, it will be a conjunction of those factors anyway.
But they are cases where using microservices is an evidence. Many softwares are completely bloated and unmaintainable, and a modular architecture might not solve some specific problems. I've worked on old JEE monoliths made of millions of lines of code. Any code changes could break dozens of unit tests and have disastrous effects. Spinning up a dev environment can take up to half a day. Testing is even worse. In those cases, the advantages of using microservices are evident and immediate. Not only does it allow to improve maintainability and scalability, but it can also be coupled with a rewriting of the code that can help remove unnecessary complexities and, in many cases, dead code.
In those cases, and to avoid the pitfalls mentioned earlier, the best is to identify a piece of the code that could easily be decoupled. Thinking either in terms of domain or service is usually useful to make a map of your software and identify the parts that could be decoupled from your existing monolith. Do you have a video sharing software? A microservice that would be responsible for uploading videos to a storage exposed by a REST endpoint would be a good starting point. A dating app? A microservice that handles user profiles would be useful. What matters the most is that you start small and that you keep it stupid simple. You won't need distributed tracing and complex queuing mechanisms for the near future. Start small, reap the benefits, and iterate. With microservices, the benefits lie as much in the journey as in the destination.
Top comments (0)