Want more wrestling news, rumors, and results? Be sure to visit PWInsider.com and PWInsiderXtra.com.
Microservices! This is the answer you are most likely to hear if you ask any IT manager what he thinks about the prospects of business app development. Microservices are small, lightweight modules, each of which performs a specific task well and interacts with other modules when creating larger applications. They are the best fit for a native cloud environment.
The attractiveness of microservices is easily explained. Programmers can function concurrently using the programming language, microservices management platform, and data types of their choice. From a business point of view, microservices are attractive because more diverse functionality can be provided faster.
However, the first users faced a serious problem – data management. Basic business apps exchange information through shared databases. In the world of microservices, this is against the rules: ideally, there should be enough app programming interfaces (APIs), and message transmission.
A perfect microservice should totally isolate its data (encapsulation) and provide it only using the API. The aim is to prevent "data binding" (data coupling). However, strict adherence to the rule that microservices cannot exchange data will inevitably entail greater costs and difficulties than regulated data exchange.
As an example, it is useful to look at the problem from the point of view of the requirements of a typical application, such as an online store site, where constant upgrades are required. We will look at standard data handling difficulties that arise when using microservices, and then we will suggest the easiest way to overcome them.
It often turns out that particular data, such as client and product info, is used in many components of a large app. In the case of a "pure" microservice architecture, one microservice will be responsible only for processing information about the client and associated data items, and all the others will request data and update it only through the API of this microservice.
When creating microservices, developers must take into account all potential requests from other modules. If a new requirement appears, you will have to update the microservice that is responsible for processing a certain type of information. In relation to our example with an online store, this means that a microservice with product data may receive a request for additional information from other microservices, so it needs to be changed.
Such a necessity to manage all prospective use cases of the microservice's "own" information can negatively affect the productivity of developers and slow down the implementation of new functions.
Another problem is data analysis within the entire application. In the classical microservice architecture, analytical components need to receive data from each integral part - extract, transform and load the relevant data as needed, therefore, each microservice must generate or store data for analytics.
In the case of our hypothetical e-commerce application, it may be necessary, for example, to get an idea of how great any item of the application functions at any step of an online store visitor. This involves evaluating data from many modules.
With a basic microservice strategy, extra resources will be needed to create an analytical representation at the scale of the application, both on the part of analysts and on the part of developers of microservices where data is processed.
Even more complicated is the task of rolling back lengthy business transactions consisting of several actions, for example, canceling an order reservation if it is not available or the loan is not approved. In a normal world without microservices, this is done using transaction monitors and a two-phase commit: either the entire transaction completes successfully, or none of its actions are saved.
Unfortunately, in the world of microservices, this proven strategy is considered an "anti-pattern" that should be avoided at all costs. Instead, the coordinating process uses a "saga template" to manage complicated operations. Each microservice involved should provide for the possibility of canceling the previous transaction if necessary. Such a structure leads to potentially greater complexity and increases the likelihood of errors.
In the end, the resulting data management architecture may be too difficult to work with. Each of the database software tools used needs to be downloaded, set, monitored, and upgraded. And for each of the available data stores, it is necessary to ensure high availability, the possibility of recovery, if necessary, and protection against illegal entry.
The microservice architecture is attractive primarily for its speed: development teams can act independently of each other, and new functions can be quickly added without coordinating work between several teams.
However, the transition to microservices may not be easy – these are new tools, new methodologies, new operational processes, and new skills.
If you enjoy PWInsider.com you can check out the AD-FREE PWInsider Elite section, which features exclusive audio updates, news, our critically acclaimed podcasts, interviews and more by clicking here!
Bang On Casino
