New cloud-native technologies for iQM
Keeping costs to a minimum
The software developed by iQM provides solid quality assurance services for the German health-care sector. Being at the start of their cloud journey, iQM is designing for cost effectiveness and preparing for scale. The migration of their current on-premise environment to AWS was initiated to improve resilience, flexibility and automate operational tasks, while keeping costs to a minimum.
All parties involved were very open-minded about moving to the cloud and changing existing operational processes. However, little experience or knowledge about cloud technology was present amongst the core developers and operators of the application. This meant that taking time for knowledge transfer was crucial.Communication was complicated by the fact that face-to-face contact was very limited, since all parties (development, operations and CloudNation) were working in different countries. Having clear, centralized documentation accessible to all parties and regular video-conferencing calls lowered this communication barrier.
An increase in automation and flexibility are the main reasons for moving towards the AWS cloud. To modernize the stack, deployments were automated using serverless services. The application components were refactored to stateless containers where possible.The application could not be made completely serverless during the migration stage, since some of the operational processes still required container access, which could not be changed easily within the given timeframe. These further improvements will be tackled in the optimization stage.
Designing a high-performing, easy to maintain web application and migrating from on-premise in three months while keeping costs to a minimum is the main challenge. Also, since application development has been outsourced, getting a holistic view on the application is challenging.
This complicated the design and refactoring process. Also, for these new cloud-native technologies to work, established operational processes had to be changed. This required significant knowledge transfer about cloud operations in a limited amount of time over long distance (Germany, Poland).
Furthermore, the limited timeframe was tackled by splitting the refactoring process into two stages. In the first stage (the migration stage), only changes with the most significant benefits to the application are made and the application is migrated to AWS. In the second stage (the optimization stage), the application is optimized in AWS to further reduce cost and automate operations.