How does it all started::

FieldCircle began as a proof of concept for a field force management solution. Utilizing SpringBoot, the team successfully built the initial application. As validation of the concept was achieved, the backend team expanded rapidly and the source code continued to grow as a single monolithic service.

Initial structure of our source code::

To prepare for future code refactoring, the team structured the code in a modular way by creating separate Spring projects as submodules within the main application and most importantly we kept each submodule in a separate git repo. This approach helped to keep the code organized and easier to break up into smaller microservices in the future.

Problems and Headaches:

As FieldCircle developed and added more applications to the single monolithic service, several bottlenecks began to arise in the development process. The team faced issues such as long code compilation and build deployment time, difficulty in debugging and running the code on local machines and a laborious process for applying hot fixes by cherry-picking from different sub-modules. Additionally, the release cycles for new features became longer, taking up to a month to complete. These challenges highlighted the need to refactor the code and move to a microservices architecture.

Strategy and Execution::

Breaking this monolithic service into microservices was a bit complex and time-consuming process, but it brought many benefits such as scalability, flexibility, and improved maintainability, here are some detailed execution steps that were taken to break this monolithic service into microservices:

1: Identification of common components: We first identified common submodules, such as helper classes, which would be used by multiple microservices. These submodules were included as jar dependencies. Since we had taken a submodule approach from the beginning, much of the work was already done, and we only needed to address the remaining bits and pieces.

2: Decomposition of the system: Our approach to breaking down a monolithic system into microservices was a carefully planned strategy. Keeping in mind our limited resources and the need to support the existing live system, we focused on identifying the high-usage services that could be separated and deployed independently, in a phased manner. This allowed us to increase availability and scalability, while minimizing disruption to the existing system.

3: Service Decomposition Strategy: Our approach to decomposing a monolithic system into microservices involved a two-fold process: defining the service boundaries for each microservice and creating a comprehensive inventory of the services, their interfaces, and the data they use. In terms of service boundaries, we determined the inputs, outputs, and responsibilities of each service to ensure proper functionality and maintainability.

4: Interprocess Communication: A crucial aspect of our microservice architecture was ensuring smooth and reliable communication between services. To achieve this, we employed the use of the AWS ECS ServiceDiscovery SDK and developed a custom library for it. This library was integrated into each microservice to facilitate seamless interprocess communication. This was a key factor in ensuring that our microservices architecture functioned without disruptions, find out more details about this implementation using this open-source Github repo here.

5: Testing Approach: To ensure that our microservices were functioning as expected, we implemented a thorough testing process. This included both individual testing of each microservice as well as testing of the overall system. This was a continuous process that involved multiple rounds of testing, including functional, load, and performance testing. Our goal was to catch any issues early on and guarantee that the system was stable and reliable.

6: Deployment Strategy: Our approach to deployment involved utilizing Docker Images stored in ECR for each service. Along with that Terraform simplifies the creation of ECS Task Definitions and Services. Finally, we utilized Jenkins for the CI/CD process. This streamlined approach ensured that each service was deployed quickly and efficiently.

7: Service Monitoring: To ensure the ongoing stability and reliability of our microservices, we implemented a robust service monitoring process. This includes ongoing monitoring of all services using tools like Sentry, NewRelic, and CloudWatch. This monitoring allows us to keep track of performance, logs, and errors, and make updates and improvements as needed. By continuously monitoring the services, we can proactively identify and address any issues that may arise, thus ensuring the optimal functioning of our system.

Infrastructure Scaling::

In 40 days, we were able to effectively address the technical debt accumulated over the last couple of years, while maintaining the existing system. Our efforts resulted in the successful decomposition of the system from 7 to 30+ microservices. To support the running of these additional microservices, we upgraded our infrastructure from standard machines to high-memory machines to ensure optimal performance in a separate environment.

Summary::

It’s important to note that there is no one-size-fits-all solution when it comes to choosing an architecture for a software application. Different projects may have different requirements and constraints, and what works well for one team or organization may not be the best fit for another. Additionally, as technology and software development best practices continue to evolve, new tools and approaches may become available that can further improve the development process. Therefore, it’s important to carefully evaluate the specific needs and goals of your project, and stay up to date with the latest developments in your field, to make informed decisions about the architecture of your application.

Feel free to write me at ankurlnmiit@gmail.com for any queries and assistance.