Result

Big benefits for digitalization projects

The architecture style known as microservices is entering the mainstream. Many companies have now realized that microservices are particularly useful for the development of services relating to various aspects of digitalization, the creation of services for end customers, and the establishment of new functions at the periphery of traditional monolithic applications. To date, no other style of architecture has been able to meet the requirements of DevOps delivery models and cloud applications as well as microservices do.

For one thing, they make it possible for dispersed teams to implement and change individual features very rapidly. However, in order to efficiently utilize this architecture style, which is employed more so within applications rather than at the enterprise level, you need to have an “external architecture” that provides guidelines for the numerous implementation options available, as these guidelines ensure the efficient utilization of microservices at a company.

The Microservices workstream recommends using the modern architecture pattern in projects that have the following requirements with regard to quality:

• Need for a high degree of scalability
• Individual components should be easy to change
• Need for a high degree of platform independence
• Functions should be easy to replace

Workstream Coordinator Hischam Abul Ola warns about using microservices without a good reason, however: “Using this style of architecture makes things significantly more complex and costly, which is why it should only be used to design those applications for which it is actually needed. If none of the four quality requirements listed above are relevant, you should start out with the development of a monolithic application.”

The results achieved by the workstream to date show that digitalization and end customer-focused projects in particular can benefit greatly from microservices. “Microservices allow for a much greater degree of technological freedom when implementing individual functions,” says Ola. “Moreover, because they are easy to alter and replace, they are a perfect tool for trying out different options.”

The high degree of scalability offered by microservices make them especially attractive for projects in which certain functions are used to a different degree at different times. “For example, my company has a car configurator that’s used heavily between 5 p.m. and 10 p.m.; at all other times the use levels are normal,” says Ola. “Fine granular scalability helps us absorb the higher level of use at peak times.”

Digitalization projects benefit extensively from microservices. Much still needs to be tested in the relatively young discipline of digitalization, and only a few best practices have yet to be established, which is why the high degree of technical flexibility of microservices and their varied implementation options offer a very strong argument in favor of their use. “It is exactly in a situation in which it is not one hundred percent clear where we are headed that one needs to make changes along the way – but such changes may not be so elaborate as to endanger ongoing projects,” Ola explains.

At the same time, the large number of implementation options poses a problem for small components at the enterprise level that can be deployed independently of one another. If every DevOps team were to align its microservices exclusively with its own projects, the result would be a variety of parallel superordinate functions and a correspondingly high level of confusion. This would be the case, for example, if every project group were to develop its own log system to record, analyze, and ultimately eliminate errors in its microservices. 

That’s why along with their “internal architecture,” which is managed by the relevant solution architects in the various teams, microservices also need an “external architecture” that address the gaps between the various applications and systems implemented in the microservices . The main issues here, according to Ola, are communication, transactions, operational aspects and, of course, security: “We are developing this external architecture in the workstream to ensure that every team doesn’t have to reinvent the wheel, which would ultimately lead to situation of absurdity in terms of the efficiency of the microservice architecture.”

This “external architecture” will take the form of a product-independent but nevertheless sufficiently specific guideline that companies can use. Along with the guideline, the workstream is also providing a clear definition of microservices, defining the lines between the microservices architectural style and SOA, working to determine the best areas for using microservices, and developing integration scenarios.