We rent out microservices according to the rules by which boxed products are rented out. First, you must assemble a team to prepare the microservice for production fully. The development itself is, conditionally, 40%.
The rest is analytics, DevSecOps methodology, the right integrations, and architecture.
We pay special attention to the principles of building secure applications. Representatives of information security participate in each project at the stage of planning the architecture and during the implementation process. They also manage code analysis systems for vulnerabilities.
The Evolution Of Microservices
- We have already rewritten several interaction protocols.
- We improve safety and reliability.
- We started with enterprise technologies – Oracle and WebLogic. We are moving from technological enterprise products in microservices to open source. We refuse databases; we pass to what works more effectively for us in this model. We no longer need Oracle technologies. Security is critical; we had to change approaches to testing and monitoring, the team, the delivery management structure, and CI / CD.
Iteratively, a year is laid in terms of technology, something else in terms of backlog and needs. We connect one with the other. The team spends 20% on the group’s technical debt and technical support and 80% on the business entity. And we move, understanding why we are doing it, making these technological improvements, and what they will lead to.
The main challenge during our arrival in microservices is not to fall into chaos. The architectural office of MegaFon immediately joined us and even became the initiator and driver – now we have robust architecture.
The next question was: “And then how to exploit all this?”. And one more: “How to ensure transparent interaction between microservices?”. The service mesh helped us answer the last question. We piloted Istio, and we liked the results. Now we are at the stage of rolling into productive zones. We have a positive attitude to all challenges – to the fact that you need to constantly change the stack and learn something new. We are interested in developing, not exploiting, old solutions.
How Does The Transition To Microservices Change The Company’s IT Management?
We started with the fact that we had an architectural division. At the same time, architects are owners of the distribution of functionality and requirements for how it will look in the landscape. So they also act as coordinators of these changes. As a result, there were specific changes in the delivery process when we created the CI/CD platform.
Difficulties With Testing And Developing Microservices
There are difficulties when moving from microservices to a platform, but they are solvable.
For example, we are making a product that consists of 5-7 microservices. We need to provide integration tests across the scope of microservices. And our problem is only in a small team. One conditional product requires one QA engineer. And so, we ship a product from 5-7 microservices, of which third-party people can develop 2-3.
The landscape is becoming more complex, and overheads are rising, especially for testing. How to deal with this: switch to auto testing. Yes, you will have to additionally invest in writing autotests and unit tests. So that developers could not commit without passing the test, they could not change the code. So that even the push button does not work without an autotest, a unit test.
Sometimes we don’t do end-to-end testing on purpose because we don’t want to stop development, although we also cling to one another. The landscape is vast and complex; there are many systems. Sometimes just stubs – yes, you lower the security margin, and more risks appear. But at the same time, you release the supply.
Also Read: What Programming Language To Learn To Be Hunted By HR Of Large Companies
