Microsoft IT Showcase

Migrating an open source PaaS solution to AzureModern Muse is a UK-based charity that’s designed to inspire and engage the next generation of female business leaders and entrepreneurs. Together with fellow technology partner Avanade, Microsoft IT is working to make www.modernmuse.org a modern platform that can scale and grow with the organization, and that’s accessible to everyone. We’re using Microsoft Azure and the latest standards in modern engineering. And we’re working with an advisory group of girls and teachers to evolve and refine the Modern Muse experience.

Bringing Modern Muse into modern engineering with AzureThe successful and seamless transformation of Modern Muse’s open-source systems from Amazon Web Services (AWS) to Microsoft Azure demonstrates the flexibility and range of Microsoft technologies and Avanade’s skill sets. This is significant for businesses that have built their applications using open-source technologies but have decided to upgrade and capitalize on the business value of the end-to-end Microsoft cloud and modern engineering practices—particularly its increased flexibility, agility, accessibility, and scalability. It also integrates with third-party applications, such as Google Analytics—this is further evidence that Azure can work with a broad ecosystem of open-source components. Modern Muse was built in a traditional, three-tier model: Front-end tier. This tier consists of the user interface and the web code to display it. It’s primarily

written in CoffeeScript, and is hosted in an AWS website that’s running Apache Tomcat. Back-end tier. The back-end tier hosted the Java-based code that supports data movement

throughout Modern Muse. It was hosted in AWS, as a platform as a service (PaaS)–based service. Database tier. The database for Modern Muse was hosted in a PaaS PostgreSQL database.There were several additional components built into Modern Muse, but we wanted to focus on the three tiers, which contained most of the Modern Muse functionality and architecture.

Planning the move to AzureOur first step in planning migration to Azure was to determine what we wanted to accomplish with the migration and how we wanted the migration to happen. We established several important goals: Migrate as much infrastructure as possible to Microsoft Azure. We wanted as much of

Modern Muse as possible in Azure to make it easier to take advantage of the Azure scalability, reliability, and performance. We also wanted it to comply with our development standards while we established a uniform monitoring and management environment.

Reuse as much Modern Muse code and architecture as possible. We wanted the migration to be non-intrusive. Although the existing code had its nuances and issues, we didn’t want to redesign the entire solution to migrate to Azure. We wanted to be as efficient as possible with time and cost.

Maintain a dedication to open-source technologies. Modern Muse was built on open-source technologies. We wanted to maintain those same technologies within the Azure solution, while incorporating them into the Azure environment.

Building an Azure architecture that supports modern engineeringWe wanted Modern Muse to be reliable and easy for our developers to work with. That meant adopting PaaS components to take advantage of scalability and availability, using continuous integration and continuous deployment (CI/CD) practices, and integrating our existing tools and monitoring practices.

Page 2 | Migrating an open source PaaS solution to Azure

When we designed how AWS components would translate to Azure, we performed feature studies on the existing AWS components. We worked with the Azure product group to determine corresponding Azure services and the suitability for each. We used a lift-and-shift approach—this means we wanted the closest possible feature match to avoid significant changes to code and functionality. Here’s how we broke down the primary tiers in Azure: Front-end tier. We used Azure App Service to host the front end. Because we used App Service,

we could use Apache Tomcat to host the existing code mostly as it was. We also incorporated CI/CD principles into the development of front-end code through the Azure CI/CD stack and integration with Visual Studio Team Services (VSTS).

Back-end tier. The code from the back-end tier was also hosted in an Azure App Service instance—this enables a similar level of code re-use and CI/CD benefits as the front-end tier. We also configured the back-end tier to integrate with the existing third-party components Modern Muse used before the migration.

Database tier. The database tier was hosted in a PostgreSQL PaaS database in AWS, and we wanted to maintain the database as a PaaS solution. Azure supports PostgreSQL as a PaaS database solution, so our ultimate goal was to leave the database tier in the PaaS model and shift it from AWS to Azure. We migrated the database tier into Azure Database for PostgreSQL, which enabled us to reuse the majority of the database code structure and patterns.

Platform and tools. The set of platform and tools was a large part of the migration process, although it didn’t explicitly involve app architecture. The AWS solution was using a variety of tools and development environments, which we wanted to simplify as much as possible. We now maintain the entire release process with VSTS using agile software development methods. VSTS tracks user stories that come in, which result in code changes that are checked in to the Git repository for Modern Muse. Publishing and deployment are part of the built-in CI/CD processes in VSTS, and the release management process is a literal push of a button.

Migrating Modern Muse into AzureMigrating from AWS to Azure was a simple process. We didn’t need a lot of platform architecture or functional information about the AWS solution. It was primarily a matter of taking the code and data from AWS and putting it into the tiers mentioned earlier. The migration process consisted of the following steps:1. Create Azure components. We created the Azure components, and we configured an automated

deployment of the components using VSTS and Azure Resource Manager templates. The entire Modern Muse solution—including networks and firewalls—can be auto-deployed into any Azure subscription with a click of a button. This makes Modern Muse completely portable to any Azure subscription in minutes. We’ve also used Azure Resource Manager template variables to specify configuration values so we can adapt Modern Muse to any Azure environment.

2. Import database. We imported the PostgreSQL database into an instance of Azure Database for PostgreSQL and made minor functional changes.

3. Move code into Azure App Service. We moved code by simply doing a straight file copy of the code base from AWS into Azure and then making minor modifications, including pointing to the new database.

4. Create and configure back-end components. We also used Azure Search, Azure Redis Cache, and Azure Notification Hubs to fill out Modern Muse functionality that was previously provided by corresponding AWS services. The configuration consisted primarily of pointing the Modern Muse code to the new Azure components.

5. Configure third party component integration. We also continued to use open-source components from third-party providers such as Google Analytics, MailChimp, Getstream.io, and Cloudinary. We simply created new accounts in each of the services for the Azure solution and changed references in the code to the third-party components.

After we completed our testing and migration phases, we launched www.modernmuse.org from the Azure platform. We retain the original three-tier architecture, all hosted in Azure PaaS components. The following figure shows Modern Muse architecture as it was in AWS and how it exists now in Azure.

microsoft.com/itshowcase June 2017

Page 3 | Migrating an open source PaaS solution to Azure

Figure 1. Modern Muse architecture migration from AWS to Azure

Assessing resultsAfter we completed our migration, we assessed ongoing results and made necessary changes to the functioning Azure-based Modern Muse app. The migration itself was a success for us. We lifted the existing AWS solution and shifted it to Azure without significant code changes, and we realized several other benefits from running Modern Muse on Azure: CI/CD support. The VSTS CI/CD stack built into Azure App Service immediately improved our

development practices. We get new features and functionality changes to production much faster and more often.

Standardized monitoring and management. We have visibility into Modern Muse in the same way as the rest of our Azure-hosted solutions, and the Azure monitoring capabilities make it easy to effectively monitor and manage.

Migration into a completely PaaS-based solution. The Azure-based version of Modern Muse was shifted from AWS PaaS-based components into Azure PaaS-based components. This was a huge win in the migration, because our code, app communication patterns, and integration with third-party tools could be retained without significant changes. The dedication to open-source software was retained across platforms, and the Azure solution remains portable and reusable for possible changes in the future

Retention of open-source code and third-party tools. Because of the lift-and-shift nature of the migration, we’re working with mostly the same code base as the original solution. And we seamlessly maintained connection to third-party components like Google Analytics, MailChimp, Getstream.io, and Cloudinary.

microsoft.com/itshowcase June 2017

Page 4 | Migrating an open source PaaS solution to Azure

Best practices and lessons learnedWe learned a lot from this migration. AWS and Azure each have their nuances, so this experience will help us to be more effective with similar migrations in the future: PaaS to PaaS migration is a reality in Azure. We did lots of research on AWS features and

functionality to make sure that we could reproduce that functionality in Azure, but being able to migrate AWS components directly into Azure PaaS components enable efficiency and feature parity.

Use sanitized and standardized code. We ran into several challenges with code during the migration. Some of the original code in AWS was using non-standard coding and AWS-specific references that didn’t fully support a platform-agnostic PaaS solution. To avoid setbacks and delays later in the migration process, it’s important to know your code and fix problems before a migration.

Azure and VSTS work well together. We used the built-in Azure capabilities in VSTS in several different areas of Modern Muse. In all cases, the existing integration between Azure and VSTS made it easy to create an effective development and deployment environment for Modern Muse.

Design for modern engineering. Even though the AWS solution wasn’t designed for modern engineering, we incorporated modern engineering standards into the Azure version of Modern Muse with small changes and broad support for modern engineering capabilities in Azure. CI/CD integration and the ability to adopt an agile software development process has enabled us to efficiently publish new releases of Modern Muse that include fixes and new features.

We were pleased with the results of the Modern Muse migration and thrilled to provide Modern Muse with a solution that gives them a reliable and available method to pursue their vision. We’ve learned lots from working with Modern Muse and we’re ready to take these lessons and apply them to future migration projects.

For more informationMicrosoft ITmicrosoft.com/ITShowcaseAzure Database for PostgreSQL

© 2017 Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

microsoft.com/itshowcase June 2017