Microservices

This weeks article is about microsystems. Software in the past and some software currently have a monolithic structure, that is, all the services and utilities the system needs, are in a single server and all the code is in the same project. This has some advantages, for example, it is easier to connect software components and services because the developer or the team knows how other services work and will produce and receive data, but it also has many disadvantages, mainly, if something on the project breaks, it will affect the entire system. On the other hand, we have microservices that could be useful for many services and have many applications, for example, if one of the services is not crucial for the entire system functionality, if it fails, all other modules that doesn’t use that service could operate without any trouble, but a disadvantage could be that all modules need to use a standard, otherwise, they wouldn’t be able to communicate with each other, but on these days, almost every microservices uses http for passing information, and JSON for the structure of that information.

There are some characteristics each microservice needs to have to function properly, those are:

Componentization via Services: Components need to be broken up into services, so that they can be used as libraries.

Organized around Business Capabilities: Split the people into team so that they all can work with teams on specific business capabilities.

Products not Projects: Software has to be meaningful, it needs to provide the client with a useful product to make his life easier, instead of just a bunch of code.
Smart endpoints and dumb pipes: Endpoints should do all the heavy lifting when it comes to the computations, so the pipes only pass informatión and could be less cluttered.
Decentralized Governance: Developers need to have the skill to learn any language or technology the product needs, they should adapt to the basic idea, instead of adapting the idea to the language or the technology they know best.
Decentralized Data Management: Each microservice should use it’s own database, or different instances of the same database.
Infrastructure automation: automate all things, including testing and deployment.
Design for failure: If an external service fails, the current services should be able to handle all kinds of errors
Evolutionary Design: The code should be design in such a way that could be easy to evolve depending on the business needs.