Lately, I have been reading extensively about microservices architecture, especially regarding the team and organisational culture required for this approach to be a success. I found it just as interesting to read about when NOT to use this approach.

In this Blog I’ll take you through some of my findings and thoughts. Let me know if you agree or disagree.

Essential rules of thumb

• Know when it is appropriate to apply it: microservices architecture is not a one-size-fits-all solution and can hurt you if you do not apply it with open eyes. Sometimes monoliths are entirely appropriate;
• Know your team culture: your team needs to be willing to do what it takes, and be patient. Microservices architecture rides heavily on team maturity, tooling and techniques to be able to deliver it efficiently;
• Know your organisational culture: Conway's Law states "organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations". Essentially, your company’s structure and culture should be willing to give autonomy to teams with less governance. The more red tape, the less likely microservices are to succeed;
• Be prepared for trial-and-error, and grow into it rather than go with the big-bang approach. Companies like Google and Amazon did not start off with microservices as an architectural approach; they all started with a monolithic approach and evolved to solve real architectural and business challenges.

Tips on your road to success

Make sure it is the right fit for your project/ projects

Before you apply this architectural style to a project, ensure that:

• You are not applying it because it is the latest ‘cool kid’ on the block. Sometimes a monolithic approach is the right solution.
• It will meet your client's needs regarding performance, functionality and effort required;
• Rather apply microservices architecture when you have a real customer problem or business case that is difficult to solve in a monolith.

Team and culture

Your team must be willing to own a product (one or more microservices) from top-to-bottom and be mature enough to:

• Decide on the technology which has little or no governance. Be autonomous as far as possible;
• Have cross-cutting skills in the team to address everything from the database right through to the user interface (UI) if required;
• Your team should consider Continuous Deployment to be efficient with how they develop, test and deploy;
• The team must be prepared to be held accountable for the product and own it right up to production support (DevOps).

Deploy, Refactor, Reuse Recycle

Microservices needs to be boxed (see Domain Driven Design's bounded context):

• You must be willing to retire, add and modify them separately and often. This means you need to be on top of your versioning game;
• Reuse other teams' microservices before you build your own. Collaboration between groups is essential;
• Use Domain Driven Design, paying particular attention to the Bounded Context principle, where appropriate, to make sure your microservices do not end up being semi-monoliths.

So, when does it make sense to use microservices as an architectural approach?

Adrian Trenman (Gilt) advises that one should use microservices as an architectural approach when:

• You can isolate a piece of domain functionality that a single service can “own”;
• The service can fully own ‘read and write’ access to its data store;
• Multiple teams are contributing to a monolithic system but keep on stepping on each other’s toes;
• You want to implement continuous deployment;
• You favour an emergent architecture rather than a top-down design.

Conclusion

The take-home from this article, should you remember nothing else, is that you need to be mature as a team before embarking on the microservices journey. It requires trust from your team and organisation for it to be successful.

Also, you need to understand that it is a tool in the toolbox of architectures and not a magic bullet.

Lastly, don't rush it. Be okay with trial-and-error and make sure your organisation understands that.

References

Thank you to the following resources and contributors to those resources. I highly recommend you read up on these articles if you want to know more.

 InfoQ microservices architecture e-book where most of my info comes from. People like Eric Evans, Martin Fowler and Randy Shoup (plus some others from Gilt) were contributors.

From monolyth to microservices by Randy Shoup (slideshare).

InfoWorld's article on how to succeed with microservices.

SmartBear's article on what is microservices architecture.