As Azure and DevOps consultants, we have the privilege of helping organizations deliver greater value by streamlining their processes. So how do we do that? By helping organizations become more Agile by moving them to the cloud, helping them build cloud-native apps, and introducing DevOps practices to refine the process and acquire meaningful feedback.

Often times, we help companies that has already created a shared IT vision. Lately, some of our clients have visions of creating microservice-style architectures.
This post is to share some light in the mistakes we’ve seen:

1. An architecture that doesn’t align to strategic goals

Occasionally we ask: “Why microservices? What business value are you wanting to get out of it?”
Sometimes we hear:

  • Scale – “We want to scale each service independently”
  • Autonomy – “We want to deploy independently”
  • Fear – “We don’t want to build a monolith”

While these are totally valid answers, I challenge the notion that those reasons of why an organization should adopt microservices.

One of my favorite answers was:

“We want to expand to new markets and for that we need to add new features. Right now, it takes 3 months to release a new feature and at this rate, we won’t be able to sustain our growth.”

As it turns out, our client was struggling to keep adding features to a monolith. They have about 5 teams of developers all working on the same codebase and these teams were often times in a holding pattern – changing a true monolith is costly and risky. In this scenario, microservices could buy a whole lot of autonomy for each team and thus could allow the business to grow into new markets quicker.

Be clear on what your IT organization wants to gain when adopting microservices. There’s a lot of new struggles that come when adopting this architectural style.

2. Not validating assumptions

As mentioned earlier, sometimes our clients choose microservices because they want to scale – in this context, be able to sustain large amounts of traffic.
One of the promises of microservices is the ability to scale out the services that are used most frequently. Now that your teams are embarked on this journey, have they validated that they are able to do this?

It is extremely risky to embark on a microservices journey without validating that you’re headed in the right direction.
For example, are you validating that your application can handle more traffic by running load tests against it?

As a consultant, I find this particularly difficult conversation to have:
“Hey, I know you want to be able to handle a lot of traffic. We ran a load test, it was not very good at all. It couldn’t scale past 10 users.”

3. Wanting to be like Netflix

Netflix clearly does many things well when it comes to building their platform. They’re one of the strongest advocates and biggest success stories for building microservices.
One example that comes up a lot is their network map:

(Image: Bruce Wong, Netflix)

The story behind this picture is that they have hundreds and hundreds of microservices. The sheer complexity is astounding, yet each service individually does one thing well and they’re relatively simple.
Sometimes, as engineers we fall in love with grandiose stories like this one. We assume that is ok to build hundreds of services to support an application.

The missing context is that Netflix also employs hundreds of developers. Netflix does not have 10s of developers creating hundreds and hundreds of services. It could be very dangerous to think that a small/medium sized team can create and support hundreds of microservices. Theories like Conway’s Law support this concept. Conway’s Law influences us to think about forming a small team that will create a single microservice.

Closing Thoughts

As consultants, we have the privilege of helping organizations with their pain points and learning from engagement to engagement. In addition, many of us are software developers at heart and we understand what teams in the industry are struggling with. If your organization is considering moving towards microservices, give us a call – we can help.
We could give architectural guidance and recommendations on what could be most effective for your organization. Want to get started on the right foot? We have a team of talented software developers who live and breathe Cloud and DevOps – two key ingredients for successful microservices.