00:00:11.910
Hello, everyone! Today, I'm going to tell you a story about a monolithic Rails application that escalated into a significant challenge. It all started with a simple concept, a project aimed at lead generation for the education industry. The application began humbly but eventually grew into a cumbersome beast, overwhelming with happy functionality yet plagued with business logic held together by duct tape. This application was indeed the business, but at the same time, it turned into a real liability. So how did this happen, and what did our ragtag team of developers accomplish?
Imagine you are a user filling out a survey on a landing page, matching your educational background and interests with schools. Your contact information is then delivered to the school of your choice, leading to a promising future. Initially, it was a simple application, but as businesses began requesting more features, we quickly added functionalities. As the business grew, the site became more complex, and soon we realized we were dealing with an application that was incredibly difficult to maintain due to its numerous dependencies.
Business started complaining about the performance: the site was slow to load and deploy new features. After much discussion, we came to a conclusion that we couldn't continue with the existing model. We needed to transition to something better. Thankfully, our company supported this decision. We aimed to evolve from a monolithic Rails application to a distributed architecture comprised of independent services interacting asynchronously.
00:01:45.590
For our transformation, we started with the understanding that we needed to separate responsibilities, proceed asynchronously, and make incremental changes. The first step was to identify the core business needs of the application. This process was crucial for determining the services we wanted to build around those responsibilities. We focused on the core tasks: qualifying leads, delivering those leads to clients, and remarketing to potential customers.
As we worked through the business logic, we found that responsibilities were scattered all over the map — some were well-tested, while others were neglected. To tackle this, we partnered with legacy experts here on the team to help refactor and focus our efforts on new services. This collaboration involved reviewing and updating tests for the legacy code to ensure we understood existing functionalities and could replicate them in the new system effectively.
00:03:14.660
We realized that while legacy systems lacked comprehensive test coverage, we could improve our approach. By establishing strong tests for the new system, we could confidently emulate and implement the business logic necessary for its operation. We recognized that the legacy tests, though incomplete, provided valuable insight into behaviors we needed to replicate, so we didn't simply copy all the old code but instead extracted essential functionalities.
Through this process, we maintained single responsibility principles by clearly defining distinct classes for different behaviors instead of merging them all into one massive class. This led to cleaner code and improved testing practices which helped us frame our initial iterative phases efficiently.
00:04:45.360
We prioritized the concept of 'single responsibility' across our services. Just like a well-designed class in object-oriented programming should focus on one task, our services must adhere to this guideline by having clear, focused purposes. This approach ensured that our application architecture was cohesive, as highlighted in a recent blog post discussing the concept of cohesion. The root term 'cohesion' suggests that functions and components that naturally belong together should be grouped as such, contributing to the application's effectiveness.
We also learned to offload long-running tasks by implementing an event-driven architecture. Initially, our legacy application processed lead deliveries synchronously, which resulted in a poor user experience; users had to wait for each lead to load and process sequentially. By offloading these events to a message broker, we were able to handle leads asynchronously, significantly improving the application's performance.
00:06:49.000
This shift allowed our application to accommodate much higher volumes of messages processed in parallel, meaning the user would experience faster response times, regardless of how many deliveries were being processed. This newfound responsiveness greatly enhanced the user experience. Moreover, messaging allowed services to operate more independently, facilitating better communication and flexibility between applications. As we established our message contract in JSON, we made sure each service could evolve independently while still being fully compatible with the overall system.
00:08:16.050
We took incremental steps while rolling out these changes, creating boundaries between the old and new systems. For instance, we defined clear lines when new delivery services came into play while keeping the legacy system functional until we were confident in the transition. This meant that if we needed to revert to a legacy delivery temporarily, we could do so with minimal interruptions to our service. Each new service was developed while the legacy code was slowly strangled out of the equation, allowing us to take our time and ensure that everything was working before making any final cuts.
00:09:52.440
We wanted our services to focus solely on specific responsibilities and quality. The last thing we wanted was to repeat the mistakes we made in our previous architecture. To accomplish this, we ensured every service maintained a cohesive purpose while also being structured to encourage adaptability. We recently read a blog about cohesive coding practices that reinforced the idea of creating pieces of code that fit well together without reliance on duct tape or external links. Unlike the legacy application, our new architecture aimed to keep things tightly integrated within each service.
00:11:18.570
To enhance performance, we also introduced strategies for offloading long-running tasks. This involved having the application listen to message queues for incoming events. By enabling our system to handle events asynchronously, we avoided user interface delays stemming from long-running processes. In practical terms, when a user made a request or performed an action like selecting a school, the application would fire off a message, allowing the request to be processed independently from the user's experience, thus improving overall efficiency.
00:13:27.370
Moving to a message-driven approach also led us to recognize the importance of testing. We adopted a robust testing philosophy that allowed us to define clear contracts between services without tightly coupling them. Our services did not need to worry about the internal workings of one another, instead focusing on their own parameters and event-driven behaviors. We knew that we needed to implement just enough integration tests to verify overall operations while identifying critical points, such as data transmission between connected applications. This balanced approach ensured that, as the architectural landscape evolved, we could still validate interactions effectively without being bogged down by intricately interconnected tests.
00:15:55.110
Beyond the technical aspects, we also considered the impact of an event-driven architecture on the business model. As we began to build this structure, we found that our newly designed services were benefiting from increased maintainability and flexibility. Instead of tangled code within one massive application, we could now modify smaller, distinct services that were focused on their own tasks — making it far easier to identify and resolve problems. Each service maintained separate responsibilities, allowing us to track down issues more effectively each time an incident occurred.
00:17:35.370
Ultimately, we ended up with a more modular system that could adapt to changes quickly. Instead of a cumbersome monolithic architecture, we developed a streamlined service-oriented architecture that provided greater flexibility for evolving business models — which is essential for small businesses aiming to stay competitive. Additionally, we ensured each service became its independent entity, capable of evolving based on its operational needs. This new architecture allowed us to react to changing requirements seamlessly and proved essential when we started to consider expanding our offerings and exploring new opportunities.
00:19:48.620
As we reflected on this journey, it became clear that moving away from a monolithic approach to a service-oriented model came with its own set of challenges. While we improved overall maintainability and adaptability, we also had to manage the complexity that came from numerous independent services interacting with one another. Each decision on architecture needed to be carefully weighed with the understanding that complexity would not be eliminated but rather distributed across these interconnected systems.
00:21:15.210
In conclusion, if you find yourself in a similarly challenging position, consider a gradual approach to transforming your monolithic Rails application. By integrating services tied closely to core business needs, you can strategically refactor existing processes rather than restart from scratch. Opt for iterative changes, transitioning old and new components in parallel. This method helps maintain the business while embracing smart, service-oriented design principles that fosters improved testing, reliability, and operational efficiency.
00:22:55.550
Finally, I want to emphasize the importance of planning and designing for future integrations and scalability. Two key points to remember are to separate responsibilities effectively and ensure that each service can stand alone. This foresight will assist you in adapting your application while minimizing dependencies, thus allowing your architecture to remain flexible as needs evolve.
00:24:13.720
Thank you for listening, and I hope this overview of our journey has provided some valuable insights into refactoring monolithic Rails applications. Let's open the floor for questions and dive deeper into the challenges and solutions we encountered along the way.
00:25:34.020
If there's one takeaway I want you to have, it’s to judiciously evaluate when to separate functionalities into services. This decision hinges on the complexity of your application. For us, some aspects were complex enough to warrant distinct services, while for others, it might have made sense to keep them within the same application. It’s vital to find a balance, ensuring that you don’t overcomplicate interactions unnecessarily.
00:26:38.700
We made sure to build around core needs and use well-defined boundaries so that each service could evolve independently. Continuous testing and refactoring were integral to our progress as well. You want your services to remain manageable as their numbers grow, striking a careful balance as functionalities expand.
00:27:58.000
Lastly, I encourage you to always look for opportunities to streamline your architecture. Every time you consider an enhancement or update, ask yourself if it can lead to a simpler, more efficient service structure. This way, you remain focused on creating solutions that benefit both your application and your users.
00:29:05.400
Thank you once again! Now, let's do a round of applause for our journey towards more effective service-oriented architecture!
