Phase 1: AWS Cloud Assessment Phase

 

This phase will help you build a business case for moving to the cloud.  Aspects to consider could include the list from the preceding section.  Other items could of course be added:

Financial Assessment

It is not that simple to compare current on-premise and co-location costs with AWS.  It requires some thought and work.  It can be said that most C-Suite Directors view AWS as cheap, free, or a source of unlimited magic at no cost.  Training staff, buying tools, automating, changing processes and operational management of AWS are seldom fully considered.

There is a basic TCO methodology given below, which relies on Amazon EC2 Cost Calculators which use industry data, AWS customer research, and user-defined inputs to compare the annual fully-burdened cost of owning, operating, and maintaining IT infrastructure with the pay-for-use costs of Amazon EC2.  RightScale and other CMP (Cloud Management Platform) vendors, and Cloudberry (Cloud backup) also provide compute resource price comparisons. 

Note that the table below compares only the direct costs of the IT infrastructure and ignores the many indirect economic benefits of cloud computing, including high availability, reliability, scalability, flexibility, reduced time-to-market, and many other cloud-oriented benefits. Decision makers are encouraged to conduct a separate analysis to quantify the economic value of these features.

Pricing Model

One-time Upfront

 

Monthly

 

AWS

Co-lo

On-Site

 

AWS

Co-lo

On-Site

Server Hardware

0

$$$

$$

 

$$

0

0

Network Hardware

0

$$

$$

0

0

0

Hardware Maintenance

0

$$

$$

0

0

$

Software OS

0

$$

$$

$

0

0

Power and Cooling

0

0

$$

0

$$

$

Data Center/Co-located Space

0

$$

$$

0

$

0

Administration

0

$$

$$

$

$$

$$$

Storage

0

$$

$$

$

0

0

Bandwidth

0

$$

$

$$

$

$

Resource Management Software

0

0

0

$

$

$

24X7 Support

0

0

0

$

$

$

Total

 

 

 

 

 

 

 

Table: Cloud TCO Calculation Example (some assumptions are made)

You can estimate your monthly costs using the AWS Simple Monthly Calculator.

Note that this is not entirely accurate and usually the costs in reality will be higher as the platform usage matures.

Security and Compliance Assessment

AWS is more secure – or can be made more secure – than most on-premise or data centers.  AWS’ security model is a shared model.  AWS takes care of the security of the physical infrastructure; you must secure the application, databases, networks and data.  

Data security can be a daunting issue if not properly understood and analyzed. Hence, it important that you understand the risks, threats (and likelihood of those threats), and then based on sensitivity of your data, classify the data assets into different categories (discussed in the next section). This will help you identify which datasets (or databases) to move to the cloud and which ones to keep in-house. It is also important to understand these important basics regarding AWS Security:

  1. You own the data, not AWS.
  2. You choose which geographic location to store the data. It doesn’t move unless you decide to move it.
  3. You can download or delete your data whenever you like.
  4. You should consider the sensitivity of your data, and decide if and how you will encrypt your data while it is in transit and while it is at rest.
  5. You can set highly granular permissions to manage access of a user within your organization to specific service operations, data, and resources in the cloud for greater security control.

 

For more up-to-date information about certifications and best practices, please visit the AWS Security Center.

                                              Figure:  Security

 

Application and Functional Assessment

Enterprises need to assess which applications to move into the cloud first, which applications to move later and which applications should remain in-house, which need to be rewritten, and which others will be decommissioned. In this stage of the phase, enterprise architects should ask the following questions. The following framework can be applied.  We can then rank application readiness by putting applications into these categories, and estimating costs to cloudifying the applications.

Figure Classification of Apps for the Cloud

 

Application analysis should also include a thorough examination of the logical constructs of your enterprise applications including their dependencies, risks, and security and compliance requirements. We need to create a dependency tree that highlights all the different parts of your applications and identify their upward and downstream dependencies to other applications. Create a spreadsheet that lists all your applications and dependencies or simply “white-board” your dependency tree that shows the different levels of interconnections of your components.

 

This diagram should be an accurate snapshot of your enterprise application assets. We need to map out all IS assets including: ERP systems, HR services, Payroll, Batch processing systems, backend billing systems and customer-facing web applications, internal corporate IT applications, CRM systems, existing SaaS, COTS and off the shelf apps.  We should also include DNS, AD or LDAP servers.

 
   

Figure: Example of whiteboard diagram of all the IT assets and its dependencies (Dependency Tree). AWS image.

 

Move Cloud-friendly apps

After you have created a dependency tree and have classified your enterprise IT assets, examine the upward and downward dependencies of each application so you can determine which of them to move to the cloud quickly.

For a Web-based application or Software as a Service (SaaS) application, the dependency tree will consist of logical components (features) of the website such as database, search and indexer, login and authentication service, billing or payments etc. For a backend processing system, interconnected processes like workflow systems, logging and reporting systems and ERP or CRM systems, will be present.  You could move the CRM for example into AWS and connect a parser and loading database with the batch system on-premise.

Post-it Note: In most cases, the best candidates for the cloud are the services or components that have minimum upward and downward dependencies. Identify systems that have fewer dependencies. Some examples are backup systems, batch processing applications, log processing systems, development, testing and build systems, web-front (marketing) applications, queuing systems, content management systems, or training and pre-sales demo systems.

To help identify which workloads are good candidates for the cloud consider this list:

 

Tools and Automation

Quite likely you can reuse most of your existing system tools and/or add AWS support very easily. All AWS services expose standard SOAP and REST Web Service APIs, and provide multiple libraries and SDKs in the programming language of your choice.

  1. Resource Management Tools: In the cloud, you deal with abstract resources (AMIs, Amazon EC2 instances, Amazon S3 buckets, Amazon EBS volumes and so on). You are likely to need tools to manage these resources. For basic management, see the AWS management Console.
  2. Resource Configuration Tools: The AWS cloud is conducive to automation, and as such, we suggest you consider using tools to help automate the configuration process. Take a look at open source tools like Chef, Puppet, and CFEngine, etc.
  3. System Management Tools: After you deploy your services, you might need to modify your existing system management tools (NOC) so that you can effectively monitor, deploy and “watch” the applications in the cloud. To manage Amazon Virtual Private Cloud resources, you can use the same security policies and use the same system management tools you are using now to manage your own local resources.
  4. Integration Tools: You will need to identify the framework/library/SDK that works best for you to integrate with AWS services. There are libraries and SDKs available in all platforms and programming languages. Also, take a look at development productivity tools such as the AWS toolkit for Eclipse.

 

Define Your Success Criteria

A business justification and ROI calculation is mandatory.  There has to be visibility into the costs and benefits of moving into AWS.  Financial and Business rationales for moving into AWS could include (examples only):

Success Criteria

Old

New

Examples on How to Measure

Cost (CapEx)

$1M

$300K

60% savings in CapEx over next  2 years

Cost (OpEx)

$20K/Year

$10K/Year

Server-to-Staff ratio improved by 2x 4 maintenance contracts discontinued

Hardware procurement efficiency

10 machines in 7 months

100 machines in 5 minutes

3000% faster to get resources

Time to market

9 months

1 month

80% faster in launching new products

Reliability

Unknown

Redundant

40% reduction in hardware-related support calls

Availability

Unknown

At least 99.99% uptime

20% reduction in operational support calls

Flexibility

Fixed Stack

Any Stack

Not locked into particular hardware vendor or platform or technology

New opportunities

10 projects backlog

0 backlog, 5 new projects identified

25 new projects initiated in 3 months

Table 4: Examples on how to measure success criteria

 

 

Create a Roadmap and a Plan

By documenting the dependencies, creating a dependency tree, and identifying the tools that you need to build or customize, you will get an idea of how to prioritize applications for migration, estimate the effort required to migrate them, understand the one-time costs involved and assess the timeline.  It is advisable not to skip over this step and quickly directly to a pilot project.  The pilot or proof of concept (POC), should be based on a clear understanding of the items listed in this section.

 

                                       Figure: Migration Plan

 

This would conclude the first phase of migrating to AWS.