Bad Reasons For Microservices

11:50 Because they are the cool thing to do for your resume.

You can sometimes get away with Resume-driven development, but not at the architecture level. Architectural mistakes are not easily corrected, and you could be paying the price for years. You also need a lot more buy-in from your team, which can lead to conflict.

Yes, writing microservices looks cool, however a good interviewer will question whether they were needed. It’s worse to have experience from forcing a microservice where it didn’t fit than lacking the experience. If the interviewer sees that you worked for a million dollar company that went all-in with microservices, they are right to question your judgement and experience.

If you don’t really need a microservice, something simpler will probably get you results more quickly. If you plan to stay with your current employer for a while, you’re better off if they can get results (and the money that comes from results) more quickly. Simple solutions that work and get to market quickly are likely candidates for moving to a microservice later, once you’ve decided what the software actually does, instead of what you designed it to do.

16:15 Because it will be easier to scale “later”.

“Later” seldom looks like you think it will. If you don’t know you have to scale and how, you probably don’t have to scale yet. Small tweaks to your design might have huge impacts in terms of the way it’s used and the way it needs to be partitioned and scaled. You might also find that you can off-load some of the work to a third party service in a way that drastically impacts the way you’d break up microservices. You won’t know this until you’ve had code out there for a while.

Premature optimization is a primary source of unnecessary complexity in software. If you designed a microservice architecture and never need it, you’ll still pay the cost of the architecture. You just won’t have the benefits. Allow the complex to evolve from the simple, rather than trying to create it out of whole cloth.

The money to pay for scaling things is often not there until those things need to be scaled. Presumably, there is a business reason for the code you are writing. If that code comes under enough load to need to be broken up and scaled out, then the load is evidence that the money is there for it. If the need doesn’t justify a microservice, then you are often better off finding some other place where it is justified and where you can show the benefits, rather than building something eloquent that isn’t needed.

19:45 Because you don’t want to commit to a single software stack.

You’re probably more efficient in one stack than another. Don’t change lightly. Multi-stack environments can work really well, provided that the organization is equipped for it. However, if you are just dipping your toes in a new stack, you’re going to need a lot of buy-in, high up in your organization for it to work.

“I really hate it when people make huge committed decisions based on lack of commitment.”

It is more complex to manage a mixed environment with multiple software stacks than it is to manage a single one. When you have multiple software stacks in a work environment, people tend to separate into tribes very easily, especially when it comes time to assign blame for things. If you switched languages and stood up a microservice, you risk both the language and the idea of the microservice being blamed for years if you screw up.

That doesn’t mean that you can’t do so, just that this lack of committment shouldn’t drive you to taking on microservices and making things even more complex. Search for solutions to problems you have. Don’t search for problems that beg for your solution. If you are wasting time on the wrong things and your competitors are not, you’re going to have a bad time.

25:00 Because you want to be able to quickly add new functionality.

While the promise of microservices it that you can quickly add functionality if it is done properly, there is a time investment to be able to do it properly. You’re going to need automated deployment to a testing environment. You are going to need practices in places so that your changes don’t break the world for the rest of your team when you roll out a new version. You’re going to probably have to have the capability of running multiple versions side by side for a while so that your updates don’t create a lot of sudden work for the rest of the team.

Your competition may be spending time on their product while you build infrastructure. A lot of managers don’t trust developers, because developers have focused on stuff that didn’t look important, while the competition was moving forward. If you can’t show the value of what you’re doing in terms of actual money or the organizations road map, you’re going to encounter resistance to your ideas.

You may not know how things need to be broken up before you need them. Users don’t always use your system the way you would think. This becomes more true at scale. Until you have some experience with what people want your software to do, you are unlikely to have the right answers as far as how microservices best need to be designed to make that happen.

32:00 Because your development teams are siloed and it fits your organizational model.

You probably don’t need to be doing things that make siloing worse. Siloed teams may also indicate that your organization isn’t mature/big enough to need microservices. Unless your organization is truly huge, knowledge silos are not something you want to be encouraging.

35:20 Because you can’t maintain your legacy monolith / distributed monolith.

Maintaining a bunch of loose microservices is not easier than maintaining a monolith. There might be an argument for moving from a distributed monolith to microservices, provided that the organizational problems that led to a distributed monolith have been addressed. A shift to microservices is likely to make things worse before it makes them better. If things are already bad, that’s going to make life difficult.

36:50 Because you’re designing a minimum viable product.

At this early stage, you don’t know what your scaling issues really are. Premature optimization is the mortal enemy of minimum viable products. You can easily design microservices that scale poorly early in the game.

There is an opportunity cost to microservices. You should be working on adding features for your users. Your using don’t care whether you have a monolith. They care what the software does. At an early stage, building infrastructure for microservices distracts from dealing with user needs.

An early microservice implementation may result in a costly rework. You may decide to run on a different platform, with a different framework, or even to drastically change what the app does. The more code and infrastructure you have, the harder this move is.

39:20 Because you think they’ll be easier to manage in production.

Again, a microservice architecture might be easier to manage in production, provided you have met the prerequisites. The prerequisites usually mean that you have dedicated people to handle things like deployment. It also means that your other software development practices are up to snuff.

You’ll want to make sure your team is well-trained to be able to handle the system in production. You need enough trained people for coverage. Your “deployment team” can’t just be one dude. That dude will get sick, go on vacation, etc. The number of people required will go up as you get more microservices.

In addition to staffing, you may be required to migrate software to infrastructure that will support your microservice ambitions. This is hard when you can’t prove the need. For instance, you’re probably looking at one of the cloud providers if you have the kind of situation where microservices really shine. It’s a real head-fake for old-school coders to have to abandon ACID for BASE.

42:55 Because it’s a default in your organization.

If your organization has the infrastructure and practices in place to deal well with numerous microservices, then it would be sensible to use them. If they don’t, it’s a dumb default. Even if you do have the infrastructure, that doesn’t mean that you have appropriately abstracted the microservice you’re designing. A lot of organizations think they have microservices, but actually have a distributed monolith.

Realistically, your organization may only need microservices for certain functions. Pick the right tool for the job. It’s completely fine to have a few microservices in your infrastructure without the whole thing being microserviced up. There are legitimate technological and business reasons for spinning out microservices. Let those pull your design towards microservices, rather than you pushing things that way.

A lot of organizational defaults are implicit and don’t reflect an actual decision arrived at by thinking. You might find that a previous developer set the default, and got fired years ago. If you follow that person’s defaults blindly, you’re going to remind management of them.

46:40 Because you want to farm work out to an outsourced team to save resources on your end.

You might think that you can avoid different teams stepping on each other if they use microservices with well-defined interfaces. This can actually happen, but you have to have some degree of design in place before you start. Fragile-agile is worse with a distributed team, not better. Particularly loose agile with API interfaces in the mix can really be unpleasant for everyone.

Architectural choices are not a good substitute for actually managing people who work together. You can certainly reduce conflicts between people with design choices you make, but you’re probably making a mistake if your solution for existing personnel problems is to code around them. Disparate teams having to integrate microservices with each other will require more interaction, not less, than what you’d see in a lot of distributed monoliths.

Version conflicts between microservices and their clients are especially fun to work out with geographically dispersed teams. Any time you migrate versions on a microservice, you’re probably going to have both versions running in production for at least a little while while all the clients catch up. If communications between your teams are already limited, microservice version migrations (and the differing assumptions between teams) will probably drive some conflict.