Skip to content

Latest commit

 

History

History
51 lines (37 loc) · 3.07 KB

1. Microservices.md

File metadata and controls

51 lines (37 loc) · 3.07 KB

Microservices

In this chapter, we discuss the microservices concept.

Monoliths

In the past, web services have most often been written as "monoliths". I.e. where there is a single application, which will probably grow as features are added to it.

Monoliths have both pros and cons. Among the pros are:

  • They are easy to deploy (just a single application to worry about)
  • They are easy to start
  • Scaling is not a big deal as long as the monolith isn't too big: just start a new instance (may require a load balancer)
  • The application is usually written in a single programming language

As a monolith grows, certain problems arise:

  • It may become harder to implement new features, new programmers may find it hard to navigate a large project
  • The project will be tied to the programming language which was initially chosen
  • Scaling may get harder, i.e. certain features may need scaling but other features not

What are microservices?

Microservices are a method to solve these problems. They have been described by Martin Fowler: http://martinfowler.com/articles/microservices.html. In this architecture, the application is built upon many small services, where each service is a single deployable unit, with its own isolated datastore. Each service has its own (REST) API, and if service A requires data from service B, it will only use the public API to access that data.

This architecture has a number of advantages:

  • Smaller services are easier to manage
  • Separation of concerns - each service manages a single problem
  • They can be scaled up, i.e. if a given service is used more than others, it can be deployed on more machines. This could result in some microservices being deployed on a single machine, while other would be deployed on a number of machines.
  • Changing a single service should be easier in theory because there is less code to read and get acquainted with when diving into a service
  • Each service may be written in whatever language you choose, they may run on any number of computers and don't even have to be located in the same room - or even the same country!

There are of course downsides as well, some of which are outlined in this article: http://www.stackbuilders.com/news/the-hidden-costs-of-microservices

  • When a microservice returns a list of some items, and each item requires access to data defined in another microservice, then the client may end up doing (N+1) requests, i.e. 1 to fetch the list of items, and N requests for the additional data.
  • If some operations need to be atomic, but cross more than one microservice, we can no longer use traditional transaction support provided by databases (since the operations span multiple individual databases).
  • All microservice require a certain amount of "boilerplate" code to support various common tasks such as documentation, error handling, logging and authentication, and this code may have to be duplicated.

There are ways around these problems, but no solutions are trivial.