In recent years, the concept of microservices has become increasingly prominent in the information technology sector. After careful consideration, we have chosen to transition to a microservices architecture. During the following presentation, we will provide insight into the rationale behind our decision, our implementation plan, and the key takeaways we’ve gained.
Initially, Works‘ systems employed a “monolithic” software architecture, comprising a limited number of web applications, each with its own database, and each responsible for a specific business purpose. As an example, we developed a suite of online applications in order to facilitate processes fundamental to developing high-quality software engineers, such as the identification, evaluation, and recruitment of potential candidates.
The expansion of our application portfolio presented us with three significant hurdles:
- Numerous applications had the same core functionality.
- It was difficult to link data from different programmes.
- Longer times to release new versions of software due to expanding monolithic codebases.
Rather than developing an interconnected network of data-driven applications, which is more in line with our organisation’s operational model, we were instead designing isolated, single-purpose applications to meet specific business needs. In order to ensure scalability, it was clear that we needed to rethink our existing software infrastructure. During our investigations into different design approaches, we encountered an nginx blog article that persuaded us to transition to microservices. We created a convincing business justification for this migration and began the process of transitioning to the new architecture.
At the outset, we conducted a thorough assessment of microservices, investigating their advantages, disadvantages, and possible impacts on our current team culture and agile processes. We tapped Ikem Okonkwo to lead this inquiry and created a core group of five developers to assist him. In this article, he explains the conclusions of the research and the design choices that were made. After reaching a consensus we were content with, we quickly crafted a plan and started to put it into practice.
In order to successfully launch our new platform, our core team took the initial steps of creating microservices templates in different programming languages, transitioning our hosting from Heroku to Google Cloud, configuring Kafka (a distributed streaming platform), establishing Kubernetes (a tool for managing servers and clusters), as well as configuring continuous integration (ConcourseCI).
All of our feature teams have begun transitioning our products to microservices once we met our minimal infrastructure requirements.
Over the course of a six-month period, our team of fifteen dedicated developers worked tirelessly to decouple five monolithic systems into thirty-five microservices. These microservices communicate with the front-end applications through an API Gateway, dramatically improving the effectiveness of our platform.
Despite the challenges encountered during the relocation process, we are pleased to report that it was ultimately successful. We have been able to take away valuable lessons that have enabled us to further our growth. In hindsight, some of the points we should have taken into account prior to the commencement of the move are outlined below.
- Gradient of learning: It is essential to be cognizant of the fact that the process of constructing distributed systems can have a significant effect on the structure of teams and their communication and collaboration protocols for projects. Therefore, it is important to shift the mindset from developing applications as a single unit to constructing applications out of modular, decentralised components.
- UUIDs: While using auto-incrementing integer identifiers may be convenient when dealing with only one entity, they can create challenges in a distributed environment. We have been able to successfully keep track of different business processes and build relationships between them in our ecosystem thanks to the use of Universally Unique Identifiers (UUIDs).
- Preparatory Sets: Using starter kits, the development process and onboarding of new developers have been expedited significantly with the introduction of boilerplate code containing everything required to create and launch a new microservice.
- Automation: By implementing a continuous delivery pipeline and automating the environment setup process, we have granted our employees a great deal of autonomy in terms of developing, testing, and deploying code. This has enabled them to work independently and with greater efficiency.
- Have It over with quickly: At our organisation, we were continuously engaged in a competitive process of introducing new features to our existing codebase as we shifted the system to a new platform. To make a successful transition, it was essential that the process of migrating the system be completed quickly, and for this, we required a highly skilled group of engineers to expedite the relocation.
Despite the numerous challenges we have faced, we are confident that our decision to migrate was the right one. Our platform and software development processes will continue to benefit from the valuable lessons we have learned. We are more certain than ever that we can quickly and effectively make improvements to our products, while still delivering constant value to the company.