Divertica offers an unique approach for solving specific problems related to Cloud Computing.  Our model is fundamentally different from a Systems Integrator.  The reason for this is practice areas such as AWS to Azure Migration have many aspects which are repetitive and deeply technical as opposed to tasks such as implementing SAP which inevitably needing to be deeply customized to the organization’s processes and requirements.  This allows us to offer the ability to migrate any application regardless of size for $1M or less if there is not refactoring required due to AWS proprietary services.

For our AWS to Azure practice, this means we have staffed with experts including personnel on the original Azure core development team and built proprietary tools which allow us to rapidly execute projects with a speed and cost that can not be achieved by a Systems Integrator.   Our focus is not on being a mile wide, but on being a mile deep in our areas of focus.  Most systems integrators focus on breadth which means the tradeoff is not being able to have depth everywhere.

As Amazon’s juggernaut continues to expand into a growing number of industries, we are seeing more and more customers look to migrate from AWS to Azure.  The challenge is that there is a relatively poor understanding of the challenges and how to do this optimally.  As a result, many firms end up either not moving or relying on large systems integrators who charge tremendous amounts of money for the migration. 

The key to moving the application is to understand how much of the application is dependent on proprietary AWS capabilities versus generic capabilities that are a duplicate of what is available on other platforms.  In many ways, this comes down to the type of services being used:

•  Infrastructure as a Service – AWS started as an IaaS platform selling off the capabilities being used internally by Amazon.  IaaS provides hardware infrastructure for applications on demand.  It allowed companies to quickly create test environments or move to a scalable platform not constrained by their internal IT department.  AWS ended up with a major lead in the market because it focused on IaaS first whereas others with a long history in Software focused on PaaS first.  The application is moved into the cloud environment just relying on hardware infrastructure.  The new code required is primarily for DevOps in order to set up the AWS environment and maintain the environment to meet the application requirements.
• Platform as a Service (PaaS) – with platform as a service, middleware and runtime services are offered to aid in the development and growth of an application.  This has become more and more valuable as more applications are “Born in the Cloud”.  As PaaS services have evolved, AWS has added both open and proprietary services.  For example, AWS offers both Mongo DB and Document DB as options for Document Databases.
•  Software as a Service (SaaS) – with SaaS, the customer is purchasing an application such as Salesforce.com and these are the most provider specific capabilities.

Appendix A shows a nearly complete list of AWS services and how they break out into IaaS, PaaS, and SaaS. The graph below shows AWS has evolved since 2006.  AWS launched initially with Iaas services and then focused on rolling out Management and Basic PaaS services.  Over the last few years AWS has accelerated its pace of development and put a higher percentage of the development effort towards Big Data and Advanced Paas services.  While this can be attractive in terms of allowing for more rapid development of advanced applications, the use of these services can also increase lock-in to AWS.  The best approach is to carefully encapsulate use of AWS proprietary capabilities in an object or function that can be substitute more easily.

New amazon services image goes here.

For applications that do not utilize any proprietary AWS services, the key to migration is developing the DevOps code to build and maintain the equivalent test and production environments in Azure. 

• Select Azure Elements Required in Azure Environment – including Hardware, Storage, Network, VMs/Containers, File Systems, Databases, Security, Deployment Zones
• Develop DevOps Code for Instantiating Azure Environment
• Develop Migration Strategy for Data – Snowball or via Network Connection
•  Launch Azure Test Environment
• Load Data Sample in Test Environment
• Run Test Bed in Azure Environment
• Debug and Modify as Needed
• Scale Test Environment and Complete Full Data Load
• Move Azure Environment to Production during Downtime Window
  
  

The key to this process is having a deep understanding of cloud architectures and how to translate AWS to Azure.

The following are the steps required to move an application from AWS to Azure which has dependencies on AWS Proprietary Functionality:

• Initial Assessment of AWS Proprietary Function Usage – Divertica’s first step is to assess with a customer the AWS services used for the application.  This quickly allows to assess the amount of refactoring required to move 100% of the application.  This assessment also allows us to know if there are components that can be moved more quickly.
• Develop Data Migration Strategy – for data to be moved from AWS to Azure, either a network connection can be used or the data can be moved through a service such as Snowball (on a storage device).
• Create Test Environment – for partial or complete moves, a test environment must be created to test the application on Azure.  This requires the development of DevOps code for building the desired test environment in Azure.  If a hybrid AWS/Azure environment is being created, it will require the development of DevOps code for the combined environment.
• Test Components that Can be Moved Immediately – Application components which can be moved immediately can be tested for quick movement.
• Deploy Hybrid Application – if there is an intermediate hybrid AWS/Azure environment, this can be deployed from the test environment configuration.  This deployment will require the development of a Cloud maintenance approach to ensure proper scaling of cloud resources both up and down and managing of the environment and alerts.
• Turn Down AWS Service – eliminate AWS services no longer in use
• Create Refactoring Approach – an approach must be taken to refactoring the application to eliminate AWS specific functions.  The goal should be to maximize portability across clouds but the approach will be dependent on the specific application requirements.
• Create Azure Test Environment for Full Migration
• Refactor Application
• Deploy Application to Azure
• Turn Down AWS Service

Divertica has invested in capabilities to accelerate both of the outlined processes.  It has inventoried almost every AWS to Azure non-proprietary scenario and has built tools and a methodology that allow for rapid migration to Azure as well as maintenance of the Azure environment.  The includes encapsulating triggers in the production environment that allow Divertica to quickly scale the environment up or down as well as instantiate new services.  Divertica’s capabilities include:

• Tools and Expertise to Rapidly Develop DevOps code for Azure for Deployment of Test and Production Environments
• Expertise in identifying AWS specific functionality being accessed within an application
•  Expertise in the architecture of both Azure and AWS allow for rapid development of a refactoring approach and how to architect to avoid Cloud “Lock-In”
• Tools and Expertise for developing a cost efficient approach to the ongoing maintenance of the Azure environment