Getting started with microservices

Microservices are becoming the cornerstone of modern architecture. Almost all microservices stories start with a monolith that got too big – the application is slow, the backlog has grown, the delivery to production time takes longer than ever, and the infrastructure has been pushed beyond its limits. Sound familiar? I have been there.

You know breaking apart the application makes sense, the next challenge is determining where to start. I wrote the piece “Tackling the Monolith – Where to Begin” to help answer this question and provide steps to align your team before jumping in.

Here’s a preview, and check out my original blog post for the full article.

Take Clues From Refactoring Practices

  • Take an incremental approach instead of a big bang one. Refactor code just a little bit at a time, just around the area that your new feature code is going to touch. Since it is incremental and scoped to the small area, this can become the team’s habit in a short amount of time.

Business Alignment

  • Understand the business domain from the perspectives of bounded contexts. We can start by isolating the business processes in a way that they don’t leave their boundaries.
  • Understand the misalignment that has happened throughout the organization in terms of teams and functions by horizontal layering.
  • The cross-cutting services for everything increases the tight coupling and leads to too much of cross-communication between services.
  • Get organizational buy-in into this type of project. It is important for the business to understand why vertical slicing is necessary.
  • Establish the communication patterns between different pieces and start establishing service layer agreements.

Choosing the Area

  • It is very important to have monitoring in place to identify which parts of the app are heavily used over the others. Highly used areas and the slowest performing could be a good starting place.
  • Consider how many new features are coming down the pipe and if the system is no longer in active development. If there is too much happening at once, changing architecture may delay the delivery.

Remote Procedure Calls

  • Start analysis on the network and identify RPC calls to services. Our app is not going to scale very well if we are hardcoding the calls to other services. Service discovery with Consul can be helpful.

Shared Relational Databases

  • One of the problematic and yet very common forms of integration patterns is the shared relational database. It creates coupling that becomes very hard to remove. Start identifying some of the most heavily used tables, their relationships, and how applications are using them.


  • Increase the organizational awareness and education around containers. Try them out in your build and test systems as mentioned in this .Net rocks episode. The risk is lower. The faster build and test pipeline can help in delivering the software quicker.

As you get started with your microservices journey, it’s crucial to examine these considerations and define what you want to achieve with microservices and identify areas that could come in the way of breaking up a monolith.

Head over to my blog to read the full post for a deeper dive into getting started with microservices.


Let's Talk