Why Microservices

Traditionally, development teams built applications in one large codebase. This technique suited the way teams worked and what their users needed, but the modern user demands reliable, fast responses and near-constant updates to applications. The developers behind these applications want to try new techniques, tools, and languages to see if they improve a user’s experience. Meeting these needs is difficult when an entire application is inside one large, tightly coupled codebase, often referred to as a “monolithic” application. As a result, microservices — breaking individual application components into smaller, self-contained “micro” services — has emerged as an alternative to this monolithic architecture. These microservices generally communicate with each other via standard APIs and run in containers that package applications and their dependencies into recreatable and scalable self-contained units.

One major benefit to microservices is that if your service experiences increased demand, you can add more instances to cope. You can then reduce them again when no longer needed, keeping your infrastructure needs and costs as efficient as necessary. This ability to add instances of a service with ease also means that you can upgrade or update services in a microservices architecture without any downtime for your entire application. Of course, microservices bring their own challenges as well.

In this article, I’m going to walk you through how to use Heroku as a way to deploy and become comfortable with microservices and then close with best practices.

#microservices #bots #board-games