A Simple Introduction to Microservices

In software engineering, a microservice is a service that meets a very specific business need, like for example: handling payment methods, sending emails or managing authentication.

By extension, microservices is an architectural style where an application is structured as a collection of services that are loosely coupled, isolated, highly maintainable, independently deployable and organized around business capabilities—as opposed to monoliths, which are single-tiered applications where all the functionalities are bundled together.

The main idea behind the microservices architecture is that components (services) should depend on each other to the least practicable extent by sharing the minimum degree of direct knowledge (i.e. loose-coupling). In other words, the only thing a service should know about another service is how to call it though its API—using protocols such as HTTP or AMQP—without having to be aware of its implementation or the technology it uses. Consequently, it becomes fairly easy to occasionally replace components with alternative implementations that provide the same service through the same interface, introducing little no to breaking changes.

Beyond that, it allows services to be deployed independently and executed within a separate process (i.e. isolation of space)—like on Docker for example, where each service runs in its own container. A service can therefore be individually managed—which implies being started, stopped, re-deployed or scaled—without having to take the whole infrastructure down, resulting in features and fixes being released much faster to production.

Moreover, if a service crashes for some reason, it will just become unavailable to other consumers without spreading the error across the system, meanwhile the rest of the application will still be running (i.e. isolation of failure)—as opposed to a monolithic architecture where it is quite common for a single failing component to bring down an entire application if an error is not properly handled.

It is also good to mention that in this type of architecture, each service is fully responsible for the data it stores. Any access to this data from the outside is exclusively performed through the service’s API, creating a firewall that prevents the data from being modified without the service being aware of the change. A service is therefore free to choose which technology to use in order to persist state without having to adapt to its consumers.