The term Service Oriented Architecture has been twisted by so many people now that it has lost some of it’s meaning. Microservices is a software architecture for web apps that aims to define a more specific way of doing SOA that isn’t so fuzzy and hand wavy.

Web applications have long been developed in a SOA way.  Especially with the advent of PaaSes like Heroku which make it easy to bolt on services.  But even when building an app to run on Heroku it’s easy to create a monolithic application which may better be segmented into separate services.

By dividing your application into micro services you can focus on clear contracts and well defined APIs. If you have an application that can be divided between people to work on then micro services allow you to reduce the cognitive burden of understanding the entire application.  It makes regression errors less likely, and gives you the focus to produce a high quality service.

You can go pretty far with micro services.

Exactly how micro you go can depend on your goals and the size/requirements of your project.

A project I’m working on now will be creating a separate analytics service.  By pulling this API into a distinct application we were able to choose a different technology stack that  was better suited to the requirements.  For uptime and performance it made sense to write the analytics API in Go, this provides nearly 10x the performance of our usual Rails stack.  Given that we expect the reporting app (in Rails) to be updated far more often than the analytics gathering API it’s valuable to isolate it.

This separation is just the start. In a micro service architected system you can go so far as to pull out user accounts, generating reports, sending reports, processing various things etc. all into their own stand alone service.  Then tie everything together with asynchronous message bus so that if a service goes down messages are queued and nothing gets lost.

There are some performance issues to be aware of.  A request going through a message bus adds significantly more overhead compared to a function call.  As a result some thought should be made on how to design the API with some performance considerations. Perhaps adding a bulk update operation as an example.

The benefits to pulling off a successful micro service architecture can be huge for managing the scalability of a big system.  If you have a project that is going to be big enough to require 4-5+ full time developers then consider micro services so that you can divide the work into multiple stand alone micro services.