Are you sure your team can use microservices?

Most companies aim to reach the pinnacle of architectural nirvana by using cutting-edge technologies. Unfortunately, what I observe are desperate attempts to implement what is read in sources that are, at best, dubious. This is when the intention is not simply an irresponsible desire of a group of developers to show (on LinkedIn? to friends? for a talk at the corner conference?) that they can.

Let’s imagine you have the autonomy to adopt a microservices architecture in your company. Before breaking your monolith into several parts, hoping that this will magically transform your current system into a microservices architecture, there are a set of questions that must be asked.

Do you have organizational support?

After various research, you’ve seen the benefits that companies like Netflix and Spotify experienced by adopting this architectural model, and now you’re sure that if it works for them, then obviously it will work for you, right?

WRONG!

Each case is unique.

How does your company handle a failure or a bug? Does it look for culprits when something goes wrong in production, or does it try to learn from the failures?

Remember that the cultural barrier is the biggest hurdle to overcome.

One of the main goals of adopting microservices is deployment independence. So, if the culture is to have deployment windows for production, you already have a significant cultural challenge ahead.

Creating a distributed system is not like making a blog with Rails. There is a large amount of new techniques and technologies beyond the notorious three-layer architecture that must be mastered for adopting microservices architecture.

Does my team have the necessary skills?

Essential: collaboration, communication, and business knowledge.

Refactoring databases. Distributed messages. Queue theory. API Gateway. Communication protocols beyond HTTP. Domain Driven Design. CAP theorem. Application profiling. Service discovery. SQL vs NoSQL. The importance of logs in a distributed model. Correlation ID. DevOps. Contract-based testing. IaC. Linux containers. Swagger. Continuous Delivery. Stateful vs. Stateless. Graceful shutdowns.

If your team doesn’t understand at least 80% of the terms described, it seems that there’s a LOT of studying to be done before getting into trouble.

Does your team already know how to build a monolith?

If your team still doesn’t know how to build an excellent monolith, what makes you think you will be able to do the same, this time in a distributed manner?

Can you already look at your monolithic system and identify the various business areas?

Is the core business covered by enough descriptive tests that serve as documentation? Are known exception cases also covered?

How easy is it to remove a functionality without breaking the system?

What problems will be solved with this architecture, and what new problems will be taken on?

What can be done with this architecture that wouldn’t be possible with a monolithic one?

Does the team already know the throughput of the current system to justify the potential high availability in the distributed model?

In exchange for high availability, does your team already know how to handle distributed transactions?

When there is a change, is it easy to observe which systems or clients are affected?

How do I ensure that the service depending on the current system (which the team has no domain over how it was implemented) will continue functioning after a change?

Is it still necessary to access via SSH to see application logs?

Conclusion

Whatever the answers, keep in mind that your team needs to be able to be more efficient in delivery speed and costs while maintaining the system highly available.

In the next texts, I intend to tackle these questions and dissect the topics for a clear view of how to handle the challenges.