Microservices: Culture -> Strategy -> Skills -> Tools

(This post is related to a presentation I gave about two months ago on microservices tools. If you don't know what that means and/or aren't interested in it then just ignore. We will return to our regularly scheduled programming shortly.)

I was asked give a talk at a microservices seminar. My job was to cover/demo  the tools used for 'typical' microservices deployments. ('Typical' is a generic term and does not lend itself well to this kind of talk, but whatever.) The tool-specific section of that talk is less important than the overarching themes I explored when I introduced the tools. Specifically, I outlined a hierarchy of dependencies that will enable (or derail) any microservices initiative.* They are, in descending order of criticality:
  1. Culture
  2. Strategy
  3. Skills
  4. Tools
Any organization that attempts to adopt a microservices initiative without alignment in all of these key areas will never reach their full potential. At best they will fumble along with intermediate or haphazard success; at worst they will fail spectacularly.

No strategic microservices initiative will succeed without a culture shift. No amount of brilliant developers and their concomitant skills can overcome a weak or antagonistic strategy. And the best tools cannot help you if you don't have the requisite skills.

If you are considering a microservices strategy and aren't sure what tools to use then it is very likely that you have other, more serious challenges. Is your culture in alignment with microservices principles and best practices? Is your strategy in alignment with your culture? Does your team have the skills to execute your strategy? If so, what tools are they most comfortable with?

Of course there are a great many other issues to consider - that's why Amundsen, et. al. wrote a book. Go there for more information, or use the google. It will not take very long to find more information than you ever wanted to know. If that's not enough then I will unpack each of the component dependencies in a later post (get excited!), but if all you take from this is the four key elements then you are off to a good start.

Thanks for reading.



* None of this happens in a vacuum. I adapted the work of the authors of this book along with some interesting and useful strategic thinking from some other hobby interests of mine.