meddevo's way to a mature cloud

How kreuzwerker helped meddevo migrate their infrastructure to AWS
06.09.2021

The story of meddevo begins as early as 2016, when the idea was formed to develop a solution exclusively for medical devices. The requirements of the EU-MDR were only one benchmark. Over the years, meddevo developed into an all-rounder in the regulatory world. Not just a software solution, but a dynamic and flexible platform. So that the software adapts to the requirements of the manufacturer and not the other way around. meddevo is getting a little better every day. Our customers are of course pleased about that. And very soon you will be able to access top experts from the industry via meddevo. Right when you need them.

Partner

The project

meddevo provides an all-in-one solution for medical devices such as smart technical documentation, audit & submission management and enhanced quality management. Due to increasing requirements, regulatory affairs have to be administered differently. Meddevo lets the customer focus on the essential and important aspects of their medical business, and reduces copy-paste errors on documentation and cost with and increasingly more stringent compliance. meddevo ran their services in the first version on a single server cloud environment and the development workloads in a container environment on local machines to supply a secure, production-ready migration environment and multi-account strategy that aligned with AWS best practices. Kreuzwerker helped meddevo create an AWS Landing Zone environment to address security, compliance, and governance at scale. Furthermore, kreuzwerker migrated meddevo cloud-native microservices-based applications to the new environment.

Solution

The first step was to analyze the existing setup in a one-day workshop, deep-diving through the documentation and installing a local development environment in order to understand the communication and behavior of the components. Next, we started with the AWS accounts’ structure, network set up, software architecture, and operating model.

To align meddevo’s AWS multi-account environment with AWS well-architected patterns, automate the set up of multi-account services, and implement preventive and detective security controls, kreuzwerker designed the Landing Zone solution structure using AWS Control Tower in a new greenfield AWS master account.

In the design stage, kreuzwerker applied a re-hosting, also called Lift-and-shift migration strategy, to migrate meddevo’s microservice-oriented applications to AWS cloud by applying only a few configurations, but without changing the core architecture of the application. Also, we applied a defense-in-depth approach to use all available security mechanisms in the different layers of the application, such as tight security groups and VPC endpoints.

In the next step, kreuzwerker implemented the proposed Landing Zone solution by enabling AWS Control Tower, which provides the following key features:

  • Govern at scale, multi-accounts environment using AWS Organization.
  • Centralized identity management using AWS SSO and federated access to the AWS accounts using AWS SSO and Office 365 as an identity provider.
  • Centralized CloudTrail and AWS Config logging in Amazon S3.
  • Pre-configured preventive and detective Guardrails to ensure compliance and governance at scale.

The infrastructure was provisioned as code using reusable modules of Terraform and Terragrunt. Each module is represented as a sub-project aligned in a single GitLab repository. The Terraform/Terragrunt code was split into multiple states to allow a separation of each module and to allow the team to work independently on the infrastructure. This set up allows meddevo to manage the small, fast-changing subset of the infrastructure resources, requiring limited permissions without any effect on the other parts of the infrastructure. Furthermore, meddevo can control all Terraform states of all children accounts from one central location in a single repository. As part of the migration, no additional automation, such as a policy-based pipeline for changes, was introduced, but instead, was left for a later step.

As a microservices-based, cloud-native application, kreuzwerker leveraged many AWS managed services, so the underlying infrastructure does not have to be administered. Kreuzwerker deployed meddevo’s applications in AWS by using the following resources:

  • AWS ECS Fargate to host Docker-based backend and frontend microservices.
  • An encrypted AWS EFS for scalable cloud storage accessed by multiple ECS services.
  • ECS Service Discovery & Route53, for microservices discovery.
  • Internal Application Load Balancer in front of frontend and several backend microservices.
  • ECR container registry with automatic cleanup policies of untagged images.
  • MongoDB Atlas is accessed through a private VPC endpoint to keep the traffic within the AWS network and not pass it through the internet.

In addition to using AWS resource, kreuzwerker included other third party services:

  • Datadog as external logging and monitoring platform to have full visibility into the application and its metrics
  • Gitlab CI to continuously test for every commit and also CD to continuously deploy for commits to develop and master branches

Right from the start, kreuzwerker worked independently on the migration with dedicated synchronization milestones with the meddevo tech team leads to align the progress and evolution, and also enable them to manage the operations on their own after the end of the project. From the organizational and project perspective, kreuzwerker and meddevo led the project with a leading engineer, often exchanging information with managers on a timely basis.

kreuzwerker shared its knowledge during the milestones, screen sharing sessions, voice calls, technical documentation and in a final handover workshop. All analysis and design work steps are documented in meddevo’s knowledgebase. The code and documentation are maintained in the meddevo GitLab repository.

From the cultural perspective, the kreuzwerker engineers gave meddevo’s operations team confidence with best practices in AWS multi-account set ups by moving forward with proposals, explanations and implementations.

Advantages

meddevo now has a production-ready, secured, compliant, multi-account environment with the possibility of defining detective and preventive guardrails that can be implemented on each account within meddevo’s AWS Organization. Furthermore, meddevo’s microservices-based infrastructure is migrated to cloud-native applications on AWS. It can be easily extended due to the modular design of the infrastructure-as-code modules, and updated due to leveraging popular open-source terraform modules. The addition of Gitlab CI/CD features enables the team to iterate fast on the product and quickly push new features to production.

Conclusion

Adopting AWS Landing Zone using AWS Control Tower, pulling Docker images from meddevo’s ECR repository, and setting up central deployment pipeline in GitLab CI were technical challenges that the kreuzwerker and meddevo team solved together.

Meddevo’s team can now register and move their existing AWS accounts to the Control Tower-enabled secure environment and continue migrating other applications to the AWS cloud.