At Your Microservice
While researching my past two blog posts about Docker, I came across a number of tutorials for a particular Docker use case. Namely, Docker is a very popular way to package and deploy microservices.
Microservice Architecture is a new-ish software architecture pattern. The premise is that you decompose your application into smaller, less tightly interlocked components. Each of these parts is exposed to the others as an API endpoint. While creating microservices, it is recommended that each component is created around business capabilities rather than technology stack. The alternative, all-one-app architecture is referred to as a monolith.
Netflix is the most commonly cited example of a familiar web application using microservices. (It is also said to account for 30% of web traffic.) They’ve actually open-sourced a number of their services as stand-alone components.
One major advantage of microservices is that you can deploy changes to one service without affecting any of the others. Because of this, microservices are closely associated with the concept of continuous integration / deployment / delivery.
Another huge advantage is scalability. If there’s a heavy load on one service (say you’re running a promotion and getting lots of new sign ups), you can deploy more instances of the user service. (You will need a tool to direct traffic amongst the iterations, such as an API gateway, a load-balancer, and orchestrator, or all of the above .)
I actually encountered a real-life example of why decoupled services are great just a few weeks ago, with my Debt Free app. I ran out of free Heroku hosting hours, so our Rails backend was down. However, the React frontend was hosted on my collaborator’s account, so it was still accessible even while the backend was blocked. Plus, we were able to deploy a new instance of the backend service on his account, and now the whole app works good as new!
There is a ton more to say about this topic. Here’s a free O’Reilly ebook, and a couple other good links:
