Microservices 101

Recently, I spoke at DeFragCon with some other incredible speakers. I decided to speak on the topic “Migrating From a Traditional MVC to Microservices Architecture”. Here you can find the slides. My lecture consisted of an introduction to the topic, answering some questions about software architecture and the right steps to take before beginning to develop a piece of software using a simple MVC as an example.

The example I used as proof of concept is a simple Ruby On Rails app that has a search engine for geographical data. A user can search how to move from point A to point B and the app will give the user which bus stops a bus route should take. Also, the user can receive an email with its search. This description is important because I used this app and the process of its migration to illustrate the concepts in my talk.

To thoroughly understand this blog post, please follow along with the slides provided in the paragraph above. In future posts, I’ll dive deeper in to implementing each piece of a microservice architecture and migrating from the existing MVC.

So what’s all the buzz around microservices?

Maybe you’ve heard some big tech companies talk about microservices or maybe you just want to know more about it. “What’s the buzz around microservices” is a good question that can be answered with even more questions:

• Have you worked with big codebases?
• Were you trying to go for the easiest (but not optimal) solution, because trying to refactor will break other X pieces of the software? (Technical Debt)
• Do you have hundreds of classes and you’re running out of decent names to call your classes?
• Are you having scalability issues? First your bottleneck is your code, then your database server.  You can scale them and you are still facing downtime and calls from angry users despite hundreds, or thousands, of dollars being spent on amazing brand new cloud servers.
• Trying to run tests? You have to wait more than X minutes for all your tests to run, making TDD impossible to apply?
• Are we in 2016 and still working with Ruby 1.8.7 (released in 2008) because your codebase is too big and painful to migrate?

If you have experienced any of these pain points (or putting it bluntly, you are fighting with a monolith hell), microservices is your solution.

Microservices has arisen as a new way of structuring your software ecosystem. A formal definition from Sam Newman, is:

“Microservices are small, autonomous services that work together.”

A good strategy has always been to divide and conquer and, in computer science, we’ve been using it for algorithms all along. This philosophy can now be applied to software architecture.

What’s wrong with MVC in the first place?

MVC was an evolutionary step in software development. We have multiple flavors and tools that make development speed increase and we can add new features quite easily. But, I’ve seen in my professional career, many MVC’s that grow towards monolith hell. The apps become huge, untestable and a great technical debt. If the app breaks at a single point, the whole app is down. I target MVC here because many apps are coded in this pattern, but in general, the real danger is the app evolving into monolith hell described above.

What are some tools and experience I need before adopting microservices?

• An open mind: Be ready to work from a single language and database technology to a new diverse tech stack with different programming languages and even different paradigms talking between each other. This is a golden opportunity for many developers to learn something new or to use its/ their experience to speed up development.
• A governance document: Since the organization is now open to multiple and diverse technologies, some standards are needed to ensure good quality and good practices are kept high. Also, the technologies to be adopted should be specified and aligned to business goals (for instance, the organization must decide which technologies they want to support to hire the necessary human resource).
• Drawings and diagrams: A picture is worth a thousand words. Having diagrams and drawings keeps the pieces clear of the new “software universe” and helps new developers have a broad perspective of what they are working for.
• Good knowledge and culture of CI/CD are essential on the team: More coordination is required and automation must be embraced since it will help team members deal with increased complexity of managing multiple microservices.
• Communicating different software technologies and, also, move from synchronous paradigm to an asynchronous.
• Understand concepts not commonly used in MVCs: This includes API gateway, service registry, event-driven architecture, circuit breaker pattern. These concepts will be explained and implemented later on.
• Collaborative environment: Be prepared to talk a lot with fellow developers owning other services.
• Good OO principles: This includes Don’t Repeat Yourself (DRY), Keep it Simple, You Aren’t Gonna Need It, Single Responsibility Principle, etc, should still apply when designing and coding the microservice.
• Think about the edge cases: Imagine we have microservice X talking to microservices Y and Z. What happens if microservice X just dies? How should microservices Y and Z react to that? These situations don’t happen in the monolith app since we are dealing with one piece of software.

How big should a microservice be?

This is a hot topic for debate and there is no exact answer for this. A particular heuristic has worked for me:

The microservice should do one, and only one, thing and do it well.

I found this particularly useful for creating autonomous, loosely coupled services. However, this also depends on the relationships with the other services. For example, if you take a look at my slides, you can see I moved my MVC to 4 microservices, one of them being Elasticsearch. Elasticsearch is not micro or even small, but I’m using it for setting up a cluster that’s only purpose is to store geographical data and search. The other microservice is a rack cas authentication server (SSO) and its only purpose is to manage authentication. Other criteria, perhaps a more scientific one, is using Domain Driven Design. Sam Newman in his book “Building Microservices” makes a really clear reference to Eric Evan’s book Domain-Driven-Design and applies some of these concepts into microservices. We will revisit this in future blog posts.

Also, we have to remember that the microservice is usually owned by one developer or a small team, so if the codebase is too big to be managed like this, maybe the service itself is too big and should be split further. This is a good instance of the Single Responsibility Principle.

Conclusion

As you can see, this is just the tip of the iceberg. Some basics are covered here, but numerous new components of the microservice architecture will be thoroughly examined in upcoming blog posts.

Resources and Bibliography

Here are some good resources for understanding microservices. They include some excellent talks, articles and a book that can be used for understanding the problem and applying it in real life.

• Kevin Goldsmith: GO TO Conference Berlin, 2015, Microservices @ Spotify
• Martin Fowler, GO TO Conference, 2014, Microservices
• R. Meshenberg, GO TO Conference, 2016, Microservices at Netflix Scale
• Netflix Engineering Blog
• NGINX Microservices Articles 
• Soundcloud dealing with the Monolith
• Martin Fowler Microservices Article
• Newman, Sam. Building Microservices: Designing Fine-Grained Systems (Kindle Location 153). O’Reilly Media. Kindle Edition.