In the last couple of years, microservices have become a huge buzzword in the IT department. I actually believe that a lot of the hype is actually deserved. Microservices are a technique for managing the backend programming.

Microservices offer an incredible rethink of a lot of software development that allow systems be much easier to change.

So, what are Microservices?

Microservices are a vastly different approach to developing software than the normal conventional method of putting everything for a system together. Everything is designed to be independently deployable, very small and incredibly modular. Changing one service should have little to no effect on other services. This means that a very large system is broken into very well defined subsystems that should have very firm boundaries on what they can and what they will do.

Most companies are splitting microservices into business capabilities. For example, for an ecommerce business you would probably have microservices for Orders, Shipping, Catalog, etc.

Typically each has their own database, and can be written in any programming language, and have very small teams working on them. In a well defined microservice architecture, data will be stored separately and only accessible to other systems via API calls.

I like to think of microservices as a variation of service oriented architecture (SOA). SOA projects in the past, may not have been as small and modular, but the concepts are otherwise very similar. One of the large differences is that all of the microservices do the business logoic and have the smarts. Microservices do a lot of communication to other services through API calls or through an enterprise service bus or some other sort of queuing system.

Common Characteristics

When looking at a system it should be relatively easy to tell if the system is using a microservices architecture based on these characteristics.

Single Responsibility

Like the SOLID design pattern – a microservice should only have one responsibility. The responsibility should be focused on a certain business function. For example, one microservice should be focused on billing. A separate microservice should be focused on users and so on.

Autonomous

Microservices should be autonomous. Autonomous means they shouldn’t really depend on one another. A service should be independently deployable and have all of its own dependencies, and execution environment. Developing microservices with something like the serverless framework allows us to easily create independent microservices.

Easily Deployable

Since each microservice should be fairly small, simple, and have it’s own database it should be fairly easy to deploy an updated microservice without impacting any other part of the backend. Using continuous deployment and continuous integration, I’ve had deployments take place in an automated fashion and take minutes to do with no downtime.

Replaceability

Microservices need to be completely independently replaceable. This means that you could completely change how the microservice works and no other system should have any knowledge about the change unless the inputs or outputs change.

Benefits of Microservices

Microservices can help solve a multitude of problems related to fault tolerance, programmer productivity, and operational savings.

Fault Tolerance

Microservices should be designed for failure. Systems go down, sometimes it’s a hardware issue or sometimes (usually) it’s a problem with our software or one of our dependencies. Since our microservices are small, and shouldn’t normally depend on direct API calls it should be fine if one microservice goes down for a moment or two.

Downsides of Microservices

Planning to build a microservice can be incredibly difficult as there will be a lot of communication between systems that may or may not be on the same computer and may not even be in the same data centre.

Although the average team size for a particular microservice, is pretty small, there ends up needing to be quite a bit of coordination between different teams to make sure things that are dependent are deployed at the same time.

Examples of Companies Building Microservices

I believe that at this point, there’s most likely thousands of companies that are using microservices or looking at using microservices. Netflix, Amazon, and Twitter are all companies with large websites that have transitioned from using large monolithic systems to using a microservice approach. Any company that is vocal about using devops is most likely using microservices as microservices and devops are typically working hand in hand with one another.

Should a small team or small startup use Microservices?

Microservices can add a lot of complexity and a lot of overhead compared to using a monolith. I think for a small experienced team there are benefits, but for a small mostly inexperienced team it’s likely a lot faster and easier to develop a monolith and try to keep seams that would allow removing things later.

For a startup building it’s minimum viable product (MVP) it’s likely a lot faster and easier to build the API as one big monolith and break things out to microservices as you’re sure things won’t change.

Wrapping It Up

Microservices are similar to service-oriented architecture. Microservices are most often see when working with an API and are usually hidden behind an API Gateway. They should be small independently deployable services that have their own database, their own potential technology.