How to Go from a Monolith to a Microservices Architecture

This week I attended the eXtreme Tuesday Club at Pivotal Labs in San Francisco. There were attendees from Square, Twitter, Twilio, Pivotal Labs, Nisum, and others.

I liked the format of the meetup. The participants can suggest topics, and the members exchange their experiences on each of them for a specific amount of time.

I suggested the topic of microservices, since it is a topic we have been working on and we would like to specialise in. It was good to hear the experiences of the attendees who are currently working on this type of architecture.

To start learning about microservices, a good introduction by Martin Fowler is this video or this article.

Initially, we considered how to introduce a microservices architecture in a Ruby on Rails application which is currently a monolith. Two scenarios were discussed here: Task Extraction and Entity Extraction. Later on, I identified a third scenario, Application Rewrite, after reading related blogs and an experience with this approach.

Task Extraction

Initially we can focus on extracting a microservice from particular functions which may need improvement. For example, there is a process that is taking too much time and could live on its own process. Examples in this category would be generation of PDFs and delivery of email messages.

Once the microservice is on its own process and own codebase repository, we can improve it and make it more robust. The additional complexity will be outside from the main Ruby on Rails application, improving modularity and maintainability of the system.

Entity Extraction

A second scenario is to extract the microservices following the boundaries of the domain entities. It is recommend to follow the Domain Driven Design practices by Erick Evans.

For our Ruby on Rails example, this would translate into extracting some controllers and associated models to form a new microservice. This mechanism requires careful consideration as there might be models which may have too many dependencies and will be harder to extract.

Application Rewrite

There is a third scenario, which is probably less common, and it is to rewrite the application in a microservices architecture. This may be a valid alternative if the team has a deep understanding of the domain and there are resources and time available for the task.

There is a related article from Stefan Tilkov that considers the scenario of building an application from scratch using a microservices architecture.

A second topic of interest in the meetup was a short discussion about Cloud Foundry.

I wanted to hear about how the Pivotal Cloud Foundry Platform was being used. The people from Pivotal Labs mentioned that they are using it for client work.

The purpose of this platform is to ease the setup and management of the different microservices that together form an operational system.

A microservices architecture brings additional complexity in the wiring of the different components to each other, the management of the run-time interdependencies and the mitigation of failures in distributed systems.

Martin Fowler has written a good article titled Microservice Premium that compares the productivity levels of developing a system as a monolith versus one with a microservices architecture.

I enjoyed the meetup discussions, and they were helpful to deepen my knowledge about microservices. I am looking forward to attend some other related meetups where these topics are discussed. Please feel free to share in the comments the related meetups that you attend in San Francisco or London.