· Read in about 3 min · (445 words) ·

Pitfalls to avoid

However, an equal number of implementations that run into rough weather are also because they lack strong engineering leadership. Especially in a corporate/enterprise environment, you need strong engineering leadership who can push for good engineering hygiene. Now, none of these are very special to microservices so it’s

  • Lack focus on the domain - The easiest way to mess up a microservices implementation is to not structure your domain well. Domains are complicated, messy beasts and if you try to keep it at an arm’s length, you’re going to find out that services aren’t aligned well and have too much coupling. Working on the domain and splitting it correctly requires both domain experts and architects and engineers to come together for a significant portion of time both initially and later as well as the domain evolves.

  • Lose focus from having a deployed, working system at all times - Can’t say this enough - but having a system that’s always deployed and available (even if it’s just internally) is non-negotiable. Otherwise, you risk putting up something that can’t stand up and it’s hard to find out where the problem is since so much has been added to an instable system. In a corporate/ enterprise environment, it’s easy to end up focusing on the wrong things (management metrics/dashboards?) because that’s what floats up the hierarchy. Metrics are important but if your system doesn’t start up, is it worth anything?

  • On-board too many developers too quickly - Having too many developers in the early stages is counter productive. It’s much better to start small and then expand organically than an assembly line approach with a large number of developers. As the famed Jeff Bezos said, aim for 2-pizza-teams - ie. If you can’t feed a team with two pizzas, it’s too large. That limits a task force to five to seven people, depending on their appetites.

  • Lack service ownership - If your system’s down, then it has to be all hands on deck till you have it back up again. If you don’t build the discipline during development, then sure as hell you’ll pay for it when you’re in QA or worse, in production.

  • Too many shared components/libraries - hiving off shared code into libraries are something that we’re trained to do. However, in a microservices world, this is often counter productive as you introduce dependencies and coupling. Things that are truly orthogonal and more infrastructure like logging, A&A are fine but if you find yourself trying to create a shared library for something that’s part of your domain, keep in mind that it’s a tradeoff (see Shared Kernel)