The reasons for the emergence of microservice-based architectures are diverse. First, it can be said that microservices and service-oriented architecture (or SOA) even struggle when it comes to decoupling business functions from executive information systems (EIS) for decentralized management.
On the other hand, SOA implementation and practice became too complex, and a new way of doing things more straightforward and less normative was required. This allowed the choice between different management techniques to get the most out of it.
What are microservices?
A microservice is a service (in the sense of SOA) that never shares its execution context with other microservices but can communicate with them.
The architecture on which these are based is not SOA, as microservices are a special case of services: they are small, stand-alone services that work together.
Over the years, architectures based on SOA principles have become as complex as the monolithic architectures they were supposed to replace and overcome.
Microservices assume that a service must do one thing and do it well. This principle is not new, as it underlies the development of UNIX from the beginning: do things right and keep them simple.
“This approach has emerged with the aim of responding more easily to operational problems.”
Microservice architecture establishes architectural principles, indicating possible and practical solutions for most problems.
Microservice Architecture
Most people are surprised that one of the basic principles of a microservice architecture is the lack of a shared database. A microservice is based on a persistence system that will be the only one to manage and use, in case you need to make a persistent state or store external data.
Microservice architecture eliminates the coupling between services through database schemas. The only one that must contain semantics is the services API. It is not the schema of a tablet. This also avoids coupling between machines.
On the other hand, partitioning the company’s data space in this way makes it necessary to compare data updates to avoid inconsistencies. One solution is to implement a master data management (MDM) program. The execution will by nature be shared among all databases, which goes against the ontological principles of the architecture.
-DevOps: Monolithic architecture vs Microservices-
It also avoids having to perform data cleansing and verification ensuring that update errors never occur. It is the responsibility of the microservice lifecycle team to make the decision to select implementation technologies.
Another consequence of the microservice architecture is that the team is responsible for its service throughout its lifecycle. This means that the team specifies, designs, implements, tests, integrates, implements the service, but most importantly, provides support and maintenance to the user.
Good practices for designing microservices
In general, the design of microservices must guarantee a weak coupling to allow services to be modified independently and to guarantee autonomy in their operation.
Services that are weakly coupled will take full advantage of the microservice architecture, such as fault tolerance, load adaptation, facilitation of implementations, etc.
In addition, it must have great unity to ensure that exchanges between these services are as coherent as possible through the following rules:
- Rule of modularity and composability: design simple microservices that can be composed or linked to others.
- Separability rule: requires engine interfaces to be isolated. Interfaces are structuring, internal microservices are not.
- Representation rule: design data-controlled microservices, which have a simpler operation, will be more robust and their scalability will be better.
- Generation rule: avoid encoding repetitive and trivial things and use programs to encode without limiting yourself to using WSDL files to generate code for the interfaces.
- Diversity rule: make the necessary technological and methodological decisions according to the problem to be solved and not because there is a software catalogue or a stack certified by a corporate guru.
- Rule of extensibility: take into account future changes in design choices. When designing a representation scheme, think about who will take the suite and who will need to add attributes without having to change the microservice code that works with the previous version.
-Find out more: Pros and cons of microservices-
Keys to implementing decentralized data management in a microservice architecture
Before implementing decentralized management, it is very important to ask yourself if it is really worth it. If innovation in the business is frequent and uncertain and the EIS must follow it.
An EIS designed on the principles of microservices is dynamic and scalable, even if its decentralized government has nothing to do with what prevailed when the EIS was composed of heavier functional blocks.
The development of a microservice by an autonomous and independent team is not an option, it is a necessary condition for this approach to be viable.
“By practising micro-service architecture, one seeks a form of stability in permanent change. In this context, the rules should be simple, few and relevant.”
In this regard, the Micro Services Architecture (MSA) supports decentralized information technology governance, so that organizations may achieve their goals through the effective and efficient use of technologies.
On the other hand, when talking about SOA, we must emphasize that SOA governance allows the creation of reusable services, defining how it will develop over time. Similarly, agreements can be established that benefit the organization and its users.
If you want to know more about microservices or want to implement them in your company, do it with an experienced technology partner, contact us!
Leverage the benefits of microservices built around enterprise capabilities with minimal centralised management
Talk to our Experts!
contact us about microservices
