It's the number 1 question that Simplicity Itself gets asked at the moment:
"How do I set (myself/my team/my department/my company) up to win with Microservices?"
The truth is that there are many pitfalls to fall into, and some nice bridges across those pitfalls that we advise people to consider.
Here are the top ones things that can make you lose at microservices adoption that we've encountered so far through our years of work in the field, in no particular order:
1. You are not Netflix, stop trying to be them!
That's great but that isn't necessarily you!
Netflix doesn't have your people, it doesn't have your history, it doesn't have your technology real-estate, it doesn't necessarily do the same business as you. Netflix might not have the same regulatory forces acting upon it either.
It's a good idea to listen and observe what Netflix have achieved, and their contribution to upping the game in software design, architecture and deploying is broad and should be recognised! But you are not them, so you have to be very careful about trying to copy them.
Many are cargo-cult copying Netflix and then, the early adopters, are starting to wonder what benefits they thought they were going to get...
2. Stop worrying about Small! The 'Micro'services label sucks
It really doesn't. Lines of code, exactly how many responsibilities... these are things that are easy to measure and so they're tempting to adopt when a different answer is harder.
The fact is that the right microservices for a given domain differ widely from other contexts!
The types of people, teams, departments and groups, and types of change that affect the system... all of these factors that are unique to a given context (yours) will help inform what set of microservices you plan for and evolve your systems towards.
3. You must go public cloud or 'Cloud Native'
Cloud native is a term originally used by Netflix for their own runtime strategy.
If it's your goal to make your software run happily on a public cloud then cloud native is a good label for that, but how you achieve cloud native (embracing failure, thriving on change) is a wide and varied topic.
Unfortunately a few are assuming that if they use Netflix tools then their system is automatically going to get these benefits. It won't.
4. Thinking that you must use Docker, or containers
But it's not absolutely necessary. It provides useful options for deployment on top of virtualisation, or not, but that's it.
I've worked on many very successfully microservice adoptions now where docker, even containers, do not feature. They can be helpful, but if you can get your options with virtualised or even bare-metal hardware then those options do not preclude the benefits of microservices.
5. Thinking that you must worry about exactly how many lines of code are in your microservices
We tend to focus on my services being a single concern, and evolving at a single rate.
6. Thinking that this needs to be a big-bang organisational to even work
The effect of the architectural style was broad and permeated all areas of the culture in the company. As they scaled in people, microservices and a culture of 'you write it, you run it' became the key mechanisms to supporting that growth. A form of reverse-Conways Law.
That's not to say that you have to take such a big-bang approach! It does not necessarily require a company-wide strategic change to adopt microservices. Or even require a whole project dedicated to it.
You can get benefits just from re-thinking a part of your existing project's functionality, or even a piece of legacy real-estate. The benefits might not be as large, but it doesn't preclude you starting.
7. You MUST use REST, and entity/resource-focussed, communication throughout
The thing is that that is simply not what we have seen as we build these systems.
In Tareq Abed-Rabbos post, and Daniel Bryant's excellent recent talks, on the 7 Deadly Sins of Microserives he calls out, in number 3, that "Assuming the wrong communication protocols" is a problem. In our own experience we couldn't agree more: Different integration styles and protocols work well in different contexts for different purposes, and focussing on entity-centric exchanges through something like REST does have it's place.
It's far from the only way though, achieving the right level of de-coupling is of greater importance!
REST and entity/resource-centric exchanges are a choice, not a given. Choose them wisely.
Hint: We've found REST most useful at the boundaries of our microservice-based systems, between us and the outside world through public or internal gateways. More on that in tomorrow's post on "Ways to win with microservices".
8. You MUST reuse microservices across your organisation
Microservices are there to support change within an area of business. Inappropriate reuse, similar to the Innapropriate Intimacy refactoring pattern (still makes me laugh that title; pure genius!), carried to the level of the system can lead to prevention of change!
This is also called out nicely in Tareq's post where he talks about shared domain models, number 5 in the 7 Deadly Sins.
In Antifragile Software, I recommend using specific gateways, that may not be micro at all, are used for reuse between business areas; or in fact between conflicting areas of change.
Don't reuse functionality through microservices, expose specific gateway services if there is a need for reuse at all.
In the my next blog post tomorrow I'll flip things around and share some of the ways we advise our clients to win at Microservices adoption.
Catch you on Friday!