Are microservices worth the complexity? It depends...

I’ve spent the last 2 years wrestling with and eventually taming (most of the time) microservices, both as a startup and at enterprise scale spanning multiple teams. Overall I’m a pretty big fan. But, microservices require a certain level of complexity to really get the advertised benefits. The “you must be this tall to use microservices” image by Martin Fowler and the corresponding post provide some fantastic prerequisites and hints at the benefits of a DevOps cultural shift as a friendly companion. Here are a few additional (not comprehensive at all) thoughts to consider for your microservices implementation...

Complexity: Microservices Death Star, Hailo

Understand why and communicate it. I’m sure the initial answer is “well, just have a look at all the benefits that come with microservices”…great, but what specifically are you hoping to get by adopting microservices? Personally, I dig the independently deployable benefit, get your own. Going through this exercise helps ensure that microservices are being used to solve YOUR problems. Got your goals? Does the team as a whole understand the benefits that the team is hoping to get from this architectural style? The simple reason is a team should understand why they are doing something and the benefits they should expect. Deeper than the surface…teams will make better design decisions when they have an understanding of the reasons an architectural style was chosen. For example, if independently deployable is one of the main goals, the team is more likely catch and callout coupling that could shatter your atomic deployment vision. Publish the reasons why, somewhat of a microservices mission statement and help each other understand.

Microservices are complex, make sure your system warrants the added complexity. This one is searchable on Google and pretty straight forward…if you have a simple system and minimal functionality, monolith it up and call it day. If you didn’t get code, test, build, deploy and monitor right with one code base, chances are it is going to be a shit show with 10. Often, not always, it is easier to see your system as a monolith and then “strangle” out complexity and components as they become pain points.

Microservices require DevOps and SRE skills on the dev team to make things run smoothly. More often than not your Node developer is not a DevOps girl. Not only do you need people that can do ops and SRE task, you want your developers thinking this way all the time. Having access to the SRE team is great but…I’m talking about the people writing the code should have a solid understanding of the environment that the code is running in, the process that the code went through to get there and a desire to make both of those things better. You are going to need to find engineers that are passionate about these things and make them part of your team, otherwise it can feel like you are chasing your tail or consistently relying on that one “devops” girl.

Size matters…team size. If “your team” means you are sitting home in sweat pants living off of beer, coffee and pizza for a weekend (ok, so this is me…) then you may not get some of the benefits from microservices. A large team working out of the same code base can lead to some shitty code merges (doesn’t have to but…yeah, it happens). Microservices are fantastic for dividing up the work in large teams, but the associated overhead may not be worth it. If I have 10 microservices, in theory I have 10 code repos, the associated build process for each, a few environments to run the code, log aggregation, etc…sure, automation is great, but it is overhead anyway you look at it. If your team is small, the cost of doing microservices may outweigh the benefits, this makes the “Understand why” the most important part of your decision.

Didn't scare you away? Here are a few high level (shoot me a message, we can chat details) notes for developers and architects working on or planning their next microservices wrestling match.

• Best practices still apply to your code! Stay DRY when it’s raining microservices

• Common and Client libraries can save time and headaches

• Automate everything

• Test everything and test the ’stuff’ that is not your code

• Understand domain driven design and bounded context

• API Gateways are helpful

• Have some standards and best practices

• Monitor everything

• Plan for additional cost (10 micros vs 1 monolith)

• Cloud native / 12 factor design will save your ass

• Plan for failure

• Async processing is sexy

• Be mindful of how many microservices you are building between clients and the ACTUAL domain

This certainly isn’t comprehensive…more like a few things that are top of the mind after doing some reflection recently. Shoot me a message if you have something burning that you would like to chat about. Remember, understanding why will help you make sure the cost of microservices is worth it. Keep an eye out for a “Return Of The Monolith” post as it relates to ReferOwl and why we rebuilt a monolith...complexity and cost.

#tech #microservices #architecture