Microservices Done Wrong

Microservices are not inherently evil. My two cents is that people often use them on small projects because of fashion and not necessity. Monolith First at the very least, and find out how far you can get with Cookie Cutter Deploys before you reach for them.

That said, you probably have decided (or a manager did for you) that you are going to use microservices to build the next great thing. Now, how can you make sure your microservices are microservices done wrong (MDW from here on out). Here is a quick guide!

The easiest way to make a solid MDW is to pretend that change doesn’t exist. Don’t version your interfaces, don’t have a way to change them over time. Assume that URL you have will last forever! Avoid using a registration server, as who needs such complications! When you change the way a part of your service works, drink the tears of any teams that depend on it and let them fix their code. You look even better by comparison.

Another critical feature of MDW is inscrutability, roll them out without any tracing infrastructure. Who needs to trace requests when you got it right the first time! Tracing is a nightmare to add later, so by avoiding it at the start of the project; you have put a significant dent in the chances it will ever get added.

Even with the above, someone could successfully manage to set up and run your microservices. That isn’t our goal with MDW, ensure that some of the required services can not run locally. Adding external dependencies means that every dev cycle can be broken from the outside, so a developer is never truly safe, and can never work offline.

The magical trio of hardcoded unversioned endpoints, zero tracing infrastructure, and network service requirements will help you build your MDW.


308 Words

2019-08-12 01:42 -0400