Microservices

I didn’t know about the term Microservice until one friend explain it to me for a proposal of a project. Her a read the article Microservices by James Lewis and Martin Fowler I understand it more deeply.

The microservices architectural style is like the quote Dīvide et īmpera. You separate the functions of your application in different service that you need. Each one is independent from another and they only communicate between them. This gives the characteristic of scalability for every single module. Although there isn’t a formal definition of this architecture design, there are common characteristics that can be or not in project with this style. The first one is Componentization via Services, that means that it is has components and it is a unit of software that is independently replaceable and upgradeable. Microservice splits up into services organized around business capability, making this the next characteristic of it. In microservice it is preferred that a team should own a product over its full lifetime. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden. Also, they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response.

It is preferred the idea of producing useful tools that other developers can use to solve similar problems to the ones they are facing. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems. A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services.

In my opinion I think that this new type of design might be useful specially for big projects. Specially this have the advantage that you can recycle code for further applications.