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 (TCO calculation)
- Technical Assessment (Classify application types)
- Identify the tools available, or necessary
- Internal resource assessment (re the Cloud)
- Security and Compliance Assessment
- License fees and impacts on contracts
- Create a plan and what success looks like
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:
- You own the data, not AWS.
- You choose which geographic location to store the data. It doesn’t move unless you decide to move it.
- You can download or delete your data whenever you like.
- 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.
- 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:
- applications that have an immediate business need to scale and are running out of capacity;
- applications that have architectural flexibility;
- applications that utilize traditional tape drives to backup data;
- applications that require global scale (for example, customer-facing marketing and advertising apps);
- applications that are used by partners
- applications that have so many issues (resiliency, availability, security) and are critical to the business
- VMs hosted on end of life infrastructure
- Applications on data centers which simply copy and replicate each other’s nodes as primary-secondary backup
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.
- 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.
- 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.
- 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.
- 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.