At QCon London, Leander Vanderbijl, senior engineer at Livi, discussed the journey of migrating an on-premises solution to the cloud, including the challenges he faced and the thinking behind the choices he made throughout the journey. The session was part of the "Connecting Systems: APIs, Protocols, Observability" track.
Livi, a healthcare service provider, operates MJog, a complex system that combines on-premise and cloud components. MJog has multiple installations nationwide, each using different technologies, including Delphi, and supporting various SQL databases within a Windows-based environment. The architecture of MJog is a mix of on-premises and cloud-based components, reflecting a variety of technologies and architectural patterns.
According to Vanderbijl, organizations can struggle with modernizing their infrastructure and often face the dilemma of opting for a "lift and shift" approach or undertaking a complete cloud rewrite. While the former is quick to implement, it often incurs high costs, making it less attractive for budget-conscious entities. Conversely, while addressing financial concerns by leveraging cloud-native services, a cloud rewrite demands significant time investment, potentially delaying the resolution of immediate customer needs.
Livi successfully navigated this challenge by adopting a hybrid strategy detailed in by Vanderbijl in his session. The company’s approach effectively mitigated the drawbacks associated with both options, preserving customer satisfaction while ensuring a cost-effective transition to the cloud. By taking the time to understand the underlying problems thoroughly and strategizing, Livi devised a solution that addressed technical challenges and upheld its commitment to maintaining strong customer relationships throughout the transition.
Embarking on a migration project requires a good understanding of the existing landscape and a comprehensive assessment of what needs to be migrated. Livi's strategy involved cataloging functionalities and languages, revealing a diverse technology stack. Livi organized functionalities into coherent domains to untangle this complexity and grouped related ones into repeatable services. They focused on synchronizing and connecting Electronic Medical Records (EMRs) through an EMR API, streamlining data flow into messaging services. Livi also deliberated between microservices and monolithic structures, ultimately opting for microservices due to scalability needs. Their commitment to enhanced observability and tackling spaghetti code underscored a strategic approach focused on understanding underlying requirements to pave the way for cleaner, more maintainable solutions.
After the session, InfoQ interviewed Leander Vanderbijl about his migration journey from on-premises to the Cloud.
InfoQ: Could you delve deeper into how your team navigated the internal and external political challenges inherent in the healthcare industry during your cloud migration journey?
Leander Vanderbijl: The biggest challenge in big projects is getting consensus. We gathered a small group of decision-makers and analyzed our options to reach a decision. Managing relationships with third-party providers can be complex. We had to accept that change was unlikely to occur on our timelines and work around those limitations. For example, one of the systems we integrate with only supports on-premise access.
InfoQ: What strategies or approaches proved effective in aligning diverse stakeholder interests and overcoming resistance to change, especially when introducing new technologies and workflows?
Vanderbijl: Early decision-making helped us manage resistance to change. However, some teams struggled more than others. We learned that we should have done more to prepare our support teams for the change. We're building better tools and providing training sessions on the new system to address this.
InfoQ: With the myriad of technology options available, including API patterns, modern frameworks, and cloud-native technologies, how did you determine the right time and context for adopting these innovations within your healthcare application's transformation?
Vanderbijl: We faced a complex decision involving tech debt, infrastructure, customer requests, and staff leaving. Ultimately, we realized we needed to address our customer requests and replace the knowledge leaving our team. Rebuilding Mjog as a cloud-native app allowed us to do both simultaneously.
InfoQ: Lastly, can you share insights or frameworks that helped guide these decisions, particularly when balancing the allure of "the latest and greatest" against the practicality of "good is enough" in a complex and regulated industry like healthcare?
Vanderbijl: Not counting time and money - the two standard decision factors - there are probably three factors we use to help guide our decisions:
- Evolution - We took ‘MVP’ to heart, knowing that our system would and could evolve. We made sure that if we could build "the greatest," we could at least create "good enough" and have a platform to migrate to the "greatest" when time and money allowed.
- Know the unknown - You can’t always see the future, so don’t solve it, but that doesn’t mean you shouldn’t prepare for it. Operating our application in the cloud was a big unknown. We had no idea how it would perform, how our integrations would work, or how much infrastructure would be required to manage throughput and processing. So we didn’t worry about it. We didn’t build for a massive scale. We built for a reasonable load and allowed for massive scale in the future. For example, instead of moving everything to serverless, we decided containerization was good enough to start with - and that we could deconstruct our application further if we needed the serverless scale.
- Know your limits - Remember that you and your colleagues will be responsible for maintaining whatever you build—your team must possess those skills. This was especially true of our decision to stick with containerization instead of serverless. Our team did not have much expertise in running and managing large decoupled serverless applications, mainly when it came to understanding observability and logging. Thus, a more classical "monolith" approach suited our "microservices" better.
Access recorded QCon London talks with a Video-Only Pass.