All successful applications grow more complex over time, and that complexity creates challenges in development. There are two essential strategies to manage this problem: a team can keep everything together (create a monolith) or a team can divide a project into smaller pieces (create microservices).
The monolith at its most extreme is a single code base that contains all of an application’s logic and to which all programmers involved contribute. This approach is perhaps the most natural, and organic growth often tends towards this model. It’s also, in many ways, the easiest to reason about and operate. A single codebase can reduce many of the costs involved in distributed systems.
Unfortunately, the practical costs of deploying a very large project can reduce velocity over time and can make it difficult for larger teams to collaborate.
Microservices, on the other hand, describe a strategy for decomposing a large project into smaller, more manageable pieces. Although decomposing big projects into smaller pieces is a practice we’ve seen in the field for as long as software has been written, the recent microservices movement captures a number of best practices and hypotheses about how to scale software development.
Microservices encapsulate many of the best practices of some of the industry’s biggest software development organizations, and are at the core of the development practice of many organizations today, not least among them Heroku, Netflix, or Amazon.
It’s worth noting that there is no such thing as a free lunch, and the advantages of microservice based development bring new challenges as well.
The Heroku blog has an interesting read with their microservices post. Definitely worth a share.
We’ve helped a few clients implement microservices using Data McFly as their backend, and it’s worked nicely.