Microservices: A “Short” Review
When a services or digital product grows in scale, number of features or user base, it gets more and more difficult to maintain when using a traditional software architecture approach (a monolithic based design). Many issues start to emerge, not only turning the software engineering process into a nightmare but, ends up compromising the user experience in general.
A microservice approach end up being the ideal way to handle the majority of these issues.
Microservices divide a large program/application into a number of smaller independent services (applications).
This approach allows team to work independently and in different peaces of the application at the same time and even in different paces without compromising the functioning of the whole application. This allows scalability, makes it easy for different teams to work on different segments of the application and increases speed.
Each service should have it owns data storage, this makes possible to choose the right data store solution considering the requirements of the service and allowing independence.
While Microservices have a lot of advantages such as flexibility of development of new features, capability to develop and scale each service independently and ability to use different programming languages, depending on the requirement of each service (just to cite some examples), there are some cons associated to this approach such as: the increase of complexity when communicating to otherservices, increase of number of deployments, the need to handle potential issues generated by changes of version and have to maintain backward compatibility between the services.
One way to best design an efficient architecture for microservices applications is by defining boundaries among the services. One technique that follows this approach is the Domain Driven Design and can follows the bellow steps:
1. Decompose applications by features to minimize dependencies (ex: In the context of a e-commerce application those can be: Review services, Order services…).
Turning all of these features into applications makes it easier to implement them into multiple other microservices internally.
2. Organize services by architectural layer (ex: UI, Web, android, iOS)
Then, these microservices can be organized by architectural layers, being employable and scaled independently.
3. Isolate services that provide shared functionality (Auth. Services, Reporting services)
After identifying these shared services, they are isolated and deployed separately from all the other applications.
Another variable to take in to account when design a microservice architecture and before implementing it is the way states are going to be handled.
The problems faced when implementing stateful services are different from the ones faced when implementing stateless services.
Stateful services are hard to scale, to upgrade and back up because they manage storage over time, (over time, more and more data will be generated by the stateful services and stored into a specific database for that stateful service).
Stateless services on the other hand does not generate their own data, they get data from the environment and other stateful services, making it easier to migrate to new versions, to scale up and to administer.
