Alexander Kalikov, backend developer at Miro, at Java Meeting Point on June 23, will tell how his team made the first microservice in the company. It’s about how to organize development on Kubernetes and meet production ready criteria: CI / CD, Monitoring, Alerting, Scalability, Security.
In this interview, Alexander shared some details of his case: why it became necessary to leave the monolith, what were the difficulties, and who will benefit from this experience.
At Java Meeting Point, you will share a case study. Tell us, what was your task?
Miro is a collaboration platform. We create whiteboards to help organize workflows.
About a year ago, my team got the task of versioning content on boards. We had to make sure that users have a version history. The task was initially interesting: it was necessary to choose databases, decide on the architecture of the application so that it would be scalable.
Our product is implemented as a monolith. With the growth of the team, development became difficult: long releases, teams overlapped when the functionality was withdrawn. Therefore, we decided to move to microservices in order to more clearly define the boundaries between the components of the system. The task of content versioning has just become a very successful candidate for implementation in the form of a microservice. At the conference I will tell you what we have encountered, what experience we have gained.
What difficulties did you have when moving to microservices?
The approach itself is new for the company, there is little expertise. There are guys who have worked with microservices on other projects, they helped us, but most of the developers did not have such experience. For us, the first difficulty is to study, to do it right, not to step on a bunch of rakes on the way.
Then there were a number of technical points: the choice of a communication method between the existing monolith and new microservices. It was necessary to decide how to organize the development: where to store the code, how to deploy it.
Separately, there was the task of choosing a technology for orchestrating the entire system. But this was not solved by the forces of our team – DevOps engineers helped here. We went in small steps in parallel with the DevOps team.
What will the conference participants learn?
Those who have not worked with the technology will get a live example of use and form a clearer idea for themselves whether it is worth trying, whether it will be useful for them.
Those who are already doing something similar will be able to adopt interesting practices, share their own – there will be an opportunity to ask a question after the report or talk in the conference chat. In the report I will tell you how and what technologies we applied: Kubernetes and its various extensions, Docker and various utilities for it, Prometheus, FluentBit. In addition, we use various managed Amazon services, since we are hosted in its cloud.
Register on Java Meeting Point: the conference will take place on June 23rd.