Advocates for microservices tend to pitch the pattern as a remedy for bloated, messy, monolithic ailments. However, is the cost of transforming a monolith into a series of microservices worth it? There are arguments for the merits and sins of each, but what about microservices attracts so many companies and developers?<\/p>\n
The most common use case for switching to a microservice-based infrastructure is converting an existing monolith into microservices. I like to refer to this process as \u201cdecomposing\u201d an application, because we\u2019re taking a tightly coupled piece of code and breaking it down into smaller services. This could be anything from just adding one or two microservices to support your main application, to completely reorganizing every aspect of your software architecture into microservices.<\/p>\n
In short, I believe that decomposing a monolith intro microservices is a worthwhile effort. However, it\u2019s a long-term investment that may take a while to yield dividends. Every project or company has different experiences and lessons learned that come along with this process. Here are a few common themes I\u2019ve noted in my most recent work with decomposing a monolith into microservices.<\/p>\n
When developing software, we often split up large tasks into smaller sections in order to better carve out a step-by-step plan. With microservices, this plan of attack should look quite similar. We want to break down the decomposition of the application into smaller pieces. In many ways, we\u2019re treating it like a compost pile: We want to gradually add the right ingredients over time so it decomposes into rich and useful resources.<\/p>\n
When you first introduce the idea of microservices to your development team, odds are they\u2019ll be quite receptive to it. Microservices are trendy in the development community as of late, so people are pretty eager to give them a shot. The more romanticized versions of the pitch tend to go like this: \u201cChanging one thing won\u2019t break 200 other things in your app anymore. Isn\u2019t that awesome?\u201d<\/p>\n
However, the journey to a less-coupled and dependent app is far from a two-week process. Odds are, you\u2019re going to spend months (possibly even years) breaking down each aspect of your application into a separate, functional service.<\/p>\n
Its also very important to look at decomposition as a long-term technical debt task. Clients and investors don\u2019t really care whether you\u2019re extracting an old feature into a microservice. They\u2019re concerned if you\u2019re delivering a product they expect. You and your team will need to push forward the developmental priorities of the company while having a taste of what microservice architecture looks like and getting a feeling for where to push forward with decomposition next. Again, this is very much like technical debt that you\u2019re always aware of.<\/p>\n
That\u2019s why taking your time with decomposition matters. It works best when you look at decomposing your application as a long-term effort that might takes years to yield tangible dividends. Each piece of code extraction should be looked at as a surgical decision. It\u2019s possible to make a really dangerous mistake if you decompose too fast!<\/p>\n
Microservices architecture opens many more doors for using different development languages and frameworks. Microservices limit the restrictions of a limited set of languages shared by an app and allow developers to create using any means they please!<\/p>\n
This obviously can lead to some very exciting decisions for developers to make. However, you might want to pump the brakes a bit before choosing the new language or framework with which to develop that microservice.<\/p>\n
Learning new programming languages, frameworks, and tools can be a really fulfilling personal experience. They\u2019re a lot of fun to poke around with and learn from. However, even though I might be comfortable building personal projects in some of these languages and frameworks, something that scales in a production-ready manner for large corporations is an entirely different ballgame.<\/p>\n
You and two of your coworkers might think writing a service in Rust is a great idea. On paper, this idea can seem pretty sweet. You get to implement a pretty exciting language, all while making your business a better place.<\/p>\n
But it\u2019s important to note that nothing stays the same when it comes to your team and coworkers. Team churn is a real thing whether you choose to think about it or not. Currently, your company might have the resources and skills among developers to create a really great microservice in Rust. However, will your team continue to invest in developers with the skillsets to maintain that Rust microservice? Depending on how big your investment is on that microservice, you might find yourself accidentally married to it.<\/p>\n
When you\u2019re choosing a language, you\u2019re choosing to invest in dealing with it for the foreseeable future. Think beyond the current state and size of your team. In the worst case, you\u2019ll be heading down a frustrating path that could waste a good deal of development resources to fully correct.<\/p>\n
If you\u2019ve decided to move forward with decomposing an application, I strongly encourage you to increase your investments in DevOps. A trademark characteristic of microservices is that they work really well with continuous deployment. There\u2019s a lot to be said about the process. Microservices enable you to quickly deploy your smaller services whenever they\u2019re ready. This makes for a better deployment process in theory, since you aren\u2019t constantly redeploying a huge chunk of code.<\/p>\n
That\u2019s in theory.<\/p>\n
The more services you create and maintain, the more lengthy your deployment process will become. You\u2019ll need to be able to effectively deploy multiple services within quick succession. If you only have a limited set of developers trained in deployment, things can get out of hand quickly.<\/p>\n
This is why it\u2019s important to teach developers how to own their code from development to deployment. Ideally, they should be comfortable simply sending off their code to be deployed and monitored. They should also be ready for the worst case scenario of deploying and monitoring a service themselves. In addition, your developers should be well versed and aware of common production errors for a microservice. I\u2019ve experienced numerous deploy errors that could have been solved more easily if more developers were familiar with common production errors. It could be the difference of a few seconds of downtime to a few minutes.<\/p>\n
Furthermore, this complexity can be aggravated by the stability and diversity of the languages that you use. To reiterate my previous point, not all new languages and frameworks deploy as well as they function in development. It\u2019s wise to take smaller risks when using cutting-edge languages and frameworks; some of them might not be as production-ready as you would like to believe.<\/p>\n
There are a lot of moving parts when it comes to decomposing a monolithic application. The key to making this work is to let teams efficiently plan out their time and efforts. They\u2019ll need time to work on new features and fixes, while also taking effective steps to decompose the application.<\/p>\n
With microservices, you have an immense freedom to choose any language, tool, or framework you want. This freedom can be exciting, but you can get caught up in building something that\u2019s just cutting edge instead of something that\u2019s more practical for your stability and production needs.<\/p>\n
You\u2019ll also find that the DevOps process is given a different kind of complexity when you decompose a monolith. You gain the advantage of not having to totally redeploy every time you make a relevant change. However, this creates a need to have more support and ownership of the multitude of new services that you\u2019re adding to your deployment process.<\/p>\n
I ultimately believe that decomposing a monolith intro microservices is a worthwhile effort. However, it\u2019s a long-term investment that may take a while to yield dividends.<\/p>\n