There are lot of definitions of micro services based architecture floating around in the industry but the most commonly accepted definition is that Micro services architecture is a way of breaking down a large and complex software system into smaller modular parts which interact with each other by means of APIs.
There are tonnes of benefits of building a decoupled system with micro services architecture and it has become a sort of industry norm to start building the entire system with such a distributed and decoupled architecture from the very inception.And it is very well established fact that this type of architecture works really well for cloud based applications.
While it comes with solid tangible benefits, it is also important to note that there are some downsides to this type of architecture as well which needs to be weighted out at the initial stages of system architecture and design. So a more nuanced approach is required to understand if you really need to start off with building a decoupled system from the start itself.
Also sometimes it is better to start with a monolith application and then subsequently over a period of time strip out different functionalities into services as it grows. So lets take a look at some common downsides to micro services architecture which will help you get a more balanced view on it:
1. Hard To Maintain — Micro services based systems are really hard to maintain and refactor. In a monolithic system, you just have one code base to make changes to while in micro services based system there will be many different code bases which require development and maintenance.
2. Complex To Write — Lets admit it, building a decoupled distributed system is not really a piece of cake. It requires meticulous system planning and design where you have to craft and stich together lot of interface code layers. Then there might be case where one service fails to respond to a call, so you need to write code and checks to handle those type of situations.
3. Deployment and System Admin can be Painful — Even deploying a single application tends to become very painful sometimes and keeps causing fires frequently which needs to be put out by the ops teams. Now scale this problem into number of services you have. Without the right ops team, it is almost impossible to build and manage a micro services based system.
4. Database Management — Although it is possible that you have one single database with which all the services talk to, but even in those cases maintaining transactional data requires overtly complicated logic and very tight code. There will also be cases where individual services might need to have their own dbs associated with them and to manage so many small databases can be quite cumbersome.
5. More Manpower is required — Micro services architecture leads to too many moving parts which grow along with the system and to manage all of these interfacing moving parts, you need to have a bigger team as compared to a team required to maintain a monolithic system.
6. Different tech stacks — Although it might be beneficial initially to not having to commit to a particular stack for long term, but as the number of tech stacks increase so does the effort and engineering expertise to manage them.
7. Tracking bugs is hard — Tracing application performance and managing logs or finding bugs gets very hard. In monolithic system it is quite straightforward to track, identify and fix bugs.
8. Performance is affected due to network — Since most of the services communicate with each other over a network, so the performance of the system gets dependent on the strength of underlying network.
9. Changing interfaces can complicate things — For a loosely coupled services system to work well , initial spec of each API needs to be in place. Although the failure in such a system is isolated, but still changing APIs on the fly can have disastrous cascading effects to rest of the functionality.
10. Testing Becomes A Challenge — It is far more easier to test a monolith system, but to test a decoupled services based system means doing entire spectrum of performance, exploratory, functional and regression testing for each of those individual APIs. It is equally difficult for manual QA engineers and also to build and maintain an automated test suite for such a system is quite challenging in nature.
So effectively you need a strategy and an expert team in place to execute that strategy in order to resolve these issues which come with building a micro services system. With using the right automations, tools and teams in place many of these drawbacks can be mitigated quite trivially. We at Enpointer are big proponents of micro-services architecture at all the products that we work on. So pros of micro services based architecture definitely outweighs the cons we just described above, but it is helpful to have a balanced view of things so that next time you are designing architecture of a new product you have a more holistic and textured understanding.