Yep, I said it — DON’T USE MICROSERVICES. And I mean it. Don’t use that pattern. To make it clear from the beginning, I am not against it, but like with any other decision do proper analysis before. Every damn pattern has pro and cons and those must match to your particular context. And in most cases, you are not in the right context for microservices. Microservices are an extreme form of classic distributed systems. In distributed systems, a couple of applications work together to fulfill a business outcome. Traditionally the number of systems aka applications involved was pretty small. Every network connection aka app2app communication is a breaking point. It can break or cause otherwise trouble anytime. Network down, network slow, packet loss, apps slow down because of workload, scheduled downtime, etc.. Oldschool devs knew that and usually tried to reduce the number of systems to an essential minimum. The fewer part could easily break, the better for everyone. But that had it’s downsides too. Those apps tend to get to complex and start doing things which should never be in their responsibility — business wise. Often this ends in the frightening monolith everyone complains about and can share a war story off… Yep, a lot went wrong in those situations, and the main culprits are the developers, but that’s for another story. For now, they solve the problem like always and run for the next shiny new object, in this case, microservices. The domain boundaries of those old school distributed systems were not always given. Microservices tries to solve that in combination with DDD. The latter aside, microservice splits a former single app of a distributed system into tiny pieces and thus 10x (or more) the complexity of such a system. With complexity, the risk of outages, slow performance, and other operational problems increase too. The general reaction of devs is to throw even more complexity at this problem in the form of automation. Now, we need complex deploy pipelines, containers, and monitoring tools. Without automating much of that, a dev team can’t handle the services anymore. In the end, operations and dev cost will increase and the complexity will more and more become a problem to your business. Except, and this is the crucial point, the business goal of your company aligns with the goal of the microservice pattern. And I bet it does not. The only reason to use microservice is to gain speed of change. And changes are not necessarily technical but more often business changes. Companies embracing microservices usually are VC-backed startups or behave like one. The ultimate goal of a VC-backed startup is to grow as big as possible as fast as possible to get a good chunk of a market. The reason for that is only a few companies in a VC’s portfolio will survive and give an ROI, see the first on HN. comment And one problem with a startup is, that you must be able to pivot quickly and adapt your business model, customer segments or whatever. If you can’t, the company might die. Microservices can help with that in the form that one can reuse more components. For example, storing customers and billing them is always required. All the other consequences like operational costs, rising complexity, etc. are of secondary nature if your sole business goal is to grow as fast as possible. If they reach the goal, they sell their shares and with it the technical depts. If it fails, who cares about those services!?! Just one item in the portfolio died. So, is ultimate growth the goal of your company? If yes, consider microservices. But if not, be careful and try to stay away from it. The cons might kill you. Want content like this in your inbox each workday? No BS, spam or tricks… just useful content, join my Learnletter . Originally published at codeboje.de .
