(Phase One - Architecture) Strategy to migrate Software Applications to Cloud

Series:

·        (Prologue) Strategy to migrate Software Applications to Cloud

·        (Phase One – Strategy) Strategy to migrate Software Applications to Cloud

·        (Phase One - Architecture) Strategy to migrate Software Applications to Cloud

·        (Phase One – Monitoring) Strategy to migrate Software Applications to Cloud

·        (Phase One – DevOps) Strategy to migrate Software Applications to Cloud

·        (Phase One – Security) Strategy to migrate Software Applications to Cloud

·        (Phase One – Performance) Strategy to migrate Software Applications to Cloud

·        (Phase One – Testing) Strategy to migrate Software Applications to Cloud

·        (Phase One – Plan) Strategy to migrate Software Applications to Cloud

·        (Phase Two – Strategy) Strategy to migrate Software Applications to Cloud

·        (Phase Two – EA Integration) Strategy to migrate Software Applications to Cloud

·        (Phase Two – Application Architecture) Strategy to migrate Software Applications to Cloud

·        (Phase Two – DevOps) Strategy to migrate Software Applications to Cloud

·        (Phase Two – Testing) Strategy to migrate Software Applications to Cloud

·        (Phase Three) Strategy to migrate Software Applications to Cloud

 (Disclaimer: The manuscript is my personal view and is not affiliated to any groups or organizations)

The first phase is where the entire team encompassing all the players are in steep learning accelerated ramp-up curve.

The application architect should take into considerations at the minimum:

The application architect should take into considerations at the minimum:

1.      Cloud auto scaling feature

2.      Dependent software services applications e.g. SMTP relay servers

3.      Ant-patterns such as usage of shared folder, multi-cast needs of the application, etc.

4.      Security of different layers of the application and data (at rest and in motion)

5.      High availability (could piggy bank on the solution for DR need)

6.      Monitoring of the application

7.      Ancillary: Adjustments to:

a.      Release Process

b.      Build processes, and

c.      Tools involved in the ALM such source control, CI, and CMDB

8.      Replication

a.      User data

b.      Code

9.      Backup and archive

10.   Test…test…test and ready to iterate following one of the iterative processes such as Scrum, etc.

Please note that Brownfield and Greenfield projects possess a different set of challenges. But there is a lot of common problems that both types of projects shares. I will strive to keep my explanation simple and try not to deviate from the main intention of the topic.

Recommendations:

• Cloud doesn’t like multicast…you will have to re-architect…conspicuously a big change.
• Use SendGrid (or Amazon SES) for SMTP relay services.
• Use your own DNS service to cname your public host name to traffic manager (Route 53 in case of AWS.)
• Use ELB, Vnet, Subnets, and NSG with ACL to adequately control the inbound/outbound traffic.

• Use judiciously IP address spaces. 
• Keep a note of RFC1918 private addressing. 
• Use CIDR for subnets. 
• Don’t use couple of first and last addresses which includes network, broadcast, and Azure used addresses.
• Don’t use 168.* or 169.* address space.

• Use vnet to vnet tunnel to sync User data and possibly code (if not taken care by CI tool already.)
• Use storage block(blob or page) /table/queue/file (SMB) for various assets. (S3 in case of AWS).
• User Azure File (SMB 2.1) for shared folders. Rearchitect application to avoid this need. It has other implications such as latency in Cloud.
• Use Availability set and turn on auto scale based on traffic needs (use ASG in case of AWS.)
• Configure Traffic Manager with Fail over from Region 1 to Region 2. In other words, let TM route all traffic to Region 1 and only in case of unavailability of the region (disasters when the entire datacenter of Azure is unavailable), TM will send traffic to Region 2 (thus effectively used as a DR site.)
• Use AppInsight to measure performance of the application, to conduct web analytics, and to monitor application for high availability. 
• If your application is already using CDN (Akamai, Limelight, etc.), web analytic tool (Ominiture, Clicky, ClickTale, Google Analytics, etc.), and web monitoring tools (KeyNote, Monitis, etc.) then it is not mandatory to make the switch to Azure CDN (CloudFront if you are using AWS) or AppInsight.

A typical simple 3-tier deployment diagram of a web application in Cloud in Azure (very similar if AWS is selected instead) demonstrated below:

3-tier web application Azure/Cloud network application deployment diagram.