“Many of our clients are in the process of investigating or implementing ‘microservices’, and a popular question we often get asked is “what’s the most common mistake you see when moving towards a microservice architecture?” We’ve seen plenty of good things with this architectural pattern, but we have also seen a few recurring issues and anti-patterns…”

After learning the seven deadly sins of microservices from Daniel Bryant, he is back with more of the nastiest anti-patterns in microservices at Devoxx US. We asked him what else could go wrong.

 

What’s the worst thing that can happen in a microservices project?

I believe the worst thing that can happen with any technical project is not delivering any value for the associated business or organisation. It’s all too easy to think that the latest architectural style or technology will be the answer to all of our problems, but in reality there truly is ‘no silver bullet’ with software development.

This is why I always ask “what are our goals?” when starting any new project with the developers wanting to use microservices. Once we are clear on the value we are trying to deliver (and have documented this), then we look at whether microservices are an appropriate architecture. There is nothing fundamentally wrong with building a monolithic application. Even when developing microservices many of our old ‘monolithic’ habits can sneak into the design and delivery of code.

On a related topic, I really like the recent work of Matthew Skelton, who talks about the different types of monolith: application monoliths, joined at the database monoliths, monolithic releases, and monolithic thinking. This is something to watch out for when working on a microservices project!

Are there any tools / best practices that can help to prevent this?

I’ve seen several good practices for building an application based upon microservices:

  • Understand your domain: Domain-Driven Design (DDD) is a popular methodology for doing this, but the primary goal is making sure that the business teams and software delivery teams are aligned and on the same page in regards to goals.
  • Clearly define application service boundaries and interfaces (this is the ‘static’ view of the system).
  • Understand the flow of data around the application (this is the ‘dynamic’ view), and evaluate appropriate communication mechanisms e.g. REST, messaging etc.
  • Create business/behaviour tests, perhaps using Behaviour-Driven Development (BDD), and codify these tests using something like Cucumber, REST-assured etc.
  • Identify the platform on which you will be deploying your services, and understand what it provides, both in respects to the operational characteristics (‘mechanical sympathy’) and also the platform primitives e.g. service discovery, orchestration and fault tolerance.
  • Invest heavily in the creation of a continuous delivery pipeline that rigorously tests the fitness of your individual services and overall application. Don’t forget to test the nonfunctional requirements too!

Is there enough knowledge or expertise about security in microservices projects?

Most likely not, and I think this relates to software delivery in general. I strongly recommend that developers read the book “Threat Modelling: Designing for Security” and check out Sam Newman’s recent talks on the topic.

What’s the most important thing to keep in mind when migrating from a monolith to a microservice?

I’ll loop back to my earlier answer, and say that we should also be looking to deliver value continuously and in a sustainable manner – we shouldn’t be re-writing applications just because we think microservices are ‘cool’.

In close relation to this delivery of value is the management/migration of data: after all, the primary non-people asset in many businesses is their data. I’ve seen a few microservice projects were it would have been relatively trivial to rebuild an existing monolithic application with microservices, but the existing data model and the actual data itself meant that a ‘big bang’ delivery of new functionality was not viable for the business.

As a shameless plug, if you want to know more about many of the things I’ve discussed here then please do come along to my Devoxx US talk, and you can also download my latest O’Reilly mini-book for free (thanks to nginx!) on the topic of “Containerising Continuous Delivery in Java”.

 

For more, see Daniel’s talk The Seven (More) Deadly Sins of Microservices at Devoxx US:

Devoxx US banner

More deadly sins of Microservices

About The Author
- Katharine is a Java developer by trade, turned Community & Content Manager for Voxxed. Helping developers learn and share knowledge. Contact me at kbe@voxxed.com with any news, articles or tutorials.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>