Microservices - Recommendation

Based on the first article about benefits and challenges of microservices and the examples of some big internet companies, this article collects the lessons learned, in order to collect recommendations. What is necessary to avoid mistakes and to be successful with microservices?

Align organization and architecture

All organizations working successful with microservices are organized in real independent, self-contained and self-responsible teams. One team works on a microservice from the first idea to the decommissioning. There is no distinction between business and IT departments. All these organizations are following the DevOps approach. There are no dedicated departments or groups for analysis/design, development, architecture, test, operations and maintenance.

It may be too difficult in the next year to completely melt together business and IT departments in a financial services organization. But at least the IT division must be restructured to get these independent, self-contained and self-responsible teams, and the gap between business and IT must be narrowed as much as possible in a constant optimization process. The whole reorganization should be started with a check and, if necessary, a refinement of the business strategy. If these measures are not adopted, the regularities of the Conveys Law take effect again, in consequence of which the microservices will mirror the complex and potentially inefficient, current organizational structure.

Provide microservice infrastructure

In all articles and discussion, the importance of central infrastructure components is frequently mentioned. These infrastructure components can be split into two areas. On the one hand all kinds of tools are needed to ease the developers’ work and the handling of code. On the other hand, central services directly used as libraries or directly called by the services are indispensable. Most important topics in this area are:

Security
Storage
Logging and Monitoring
Anomaly detection
Messaging (with enough capacity and performance)

The service covering these topics should be developed by special infrastructure teams.

Establish microservice governance

Even if Rodrigue Schaefer (ZALANDO) stated at the GOTO 2016 in From Monolith to Microservices at Zalando: “If you kill your variance, you limit your innovation. Because innovation is variance.” it is necessary to have some governance limiting the use of languages, libraries and tools. As described in the chapter above it is crucial to provide central infrastructure services. This is impossible for an unlimited range of technologies and languages. Some companies provide infrastructure services for a limited number of desired main technologies. These infrastructure services ease the work of projects following these main technologies. All projects not following these main technologies must implement all the infrastructure services themselves. In the end most s will follow the main technologies as long as they are carefully maintained and up to date.

Setup a service repository

With a rising number of microservices a repository is needed with information about all services. It should contain:

Name
Purpose
Description incl. APIs and Messages
Ownership
Dependencies
Deployment
Configuration
Problems

This repository helps to find and maintain the microservices. Otherwise there is a high risk of multiple services for the same requirements.

Check cloud strategy

If you are not already used to build and maintain an infrastructure for a microservice architecture, you should use one of the cloud offerings of one of the cloud providers. It is difficult to build up the knowledge in your organization and the cloud providers will always be ahead. Additionally, you should focus on your core business. The classical main microservice infrastructure is becoming a kind of standard product. There is no competitive advantage inside your organization. In the meantime, all big cloud provider offers additional service for compliance with EU and German laws and regulations. This must be checked by the legal departments very early in the provider selection process.

Don’t underestimate complexity

The business rules for Netflix and Spotify may be complex with different payment models for each video or song in each country depending on the content owner but, compared to the business model of an insurance company, they are simple. Insurance contracts are much more complex than the contracts the internet companies are dealing with. Because of the long-term contracts insurances have to handle a lot of different older versions of each contract type. Furthermore, some companies accept customer specific contract adaptions.

In his presentation Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned at the GOTO 2016 conference Ruslan Meshenberg statet as follows: “They (the billing services) deal with money. So, you have to be more careful. These services took us the longest to migrate in the cloud and to break into microservices.”

Christian Posta explains in The hardest part of microservices is your data that businesses in financial sector are far more complex than most internet companies like for instance Twitter. The challenge for most of the internet companies is the number of requests, not the complexity of each request. The number of requests requires special effort for scaling and workload distributions, whereas the complex requests lead to complex logic inside the microservices or a complex structure of microservices with orchestration challenges.

Invest in production disaster testing

In general, a distributed system is harder to handle. Microservice architectures are extremely distributed systems. It is practically impossible to simulate all situations that can occur in the production environment in a test environment. This test environment would be very large and expensive. Thanks to the spread end-to-end responsibility without a central deployment group it would be extremely difficult to make sure that every change in the production environment is also done in the test environment. The only way to prevent outage time is to test disasters in the production environment in a controlled way. From time to time some components must be shot down to see what happens. For these tests special strategies and tools must be defined and implemented. A special group should work on this topic. This leads to significant effort.

Data Management

Establish a data management answering the questions:

Which data are stored?
Where are the original data stored?
Where are copies of this data stored?
How long are these data stored?
Where are these data processed?
What is the business reason to work with the data?

All these questions are not easy to answer in most of the current IT landscapes, but it gets harder in a heavily distributed microservice environment. Based on current and most likely upcoming regulatory requirements it is or will get necessary to have answers to all these questions.

To facilitate the data management and to avoid data inconsistencies data redundancy should be avoided as much as possible. If it is really necessary, it should be clear where there is the master and which are copies of the data.

Conclusion

During the research for this article one aspect emerged, that is not related to technological questions. All three companies have an extremely strong customer focus. They spend a huge effort to collect as much data about the customer behavior, test new ideas with groups of chosen customers and always ask what comes next. Already in the year 2000 - long before the broader discussion about big data and analytics - Spotify offered customers DVDs, based on the DVDs they rented so far. Together with a culture fostering innovation this seems to be the biggest success factor of these companies. All three companies started with a monolithic architecture and were already successful with this architecture. The success and their innovation culture forced them to microservices because of their flexibility and scalability.

There is a big difference between these companies and most companies in the financial sector. Companies like Netflix, Spotify and Uber do not have this strong differentiation between business and IT departments. Their assets are the IT systems and the data, all other functions are grouped around it. The strong differentiation between business and IT on the financial sector is caused by the long history of most companies and the complexity of the financial business. This gap is hindering innovations. For innovations business and IT people must get together and find new solutions for customer demands.

A microservices-architecture in the end is an issue of technology. This technology can be implemented on its own. But the real benefit will take place if it is combined with a special culture and some supporting technology approaches.

A strong agile and innovative culture characterized by trust and autonomy is vital. The architecture must provide a framework to build small and as independent as possible components. Microservices are one approach to reach this goal. For all often used or centrally needed functions (rights, logging, monitoring, persistence etc.) central infrastructure services must be provided. The daily work of the engineers (coding, deployment, testing, finding and managing services etc.) must be supported as much as possible with automation. A strong focus on testing and disaster simulation in the production environment is needed. But not only the architecture is depending on the other pillars. In the long run an agile innovative culture will not be successful without an architecture with small most independent components and an environment that eases quick changes and mitigates risk by frequent full automated tests.

A microservice architecture will only become a success factor for a financial sector company, if it is combined with a deep cultural and organizational shift. Complexity of business processes needs to be reduced as much as possible. Freedom and responsibilities must be core values of the company culture. A concept and a roadmap need to be in place for a full replacement of the legacy systems. Otherwise microservices are just another technology working somehow together with all the legacy systems.

References

Rodrigue Schaefer [Zalando], From Monolith to Microservices at Zalando, 08.08.2016, href="https://www.youtube.com/watch?v=gEeHZwjwehs, found 04.09.2019