A PRACTICAL GUIDE TO CLOUD ONBOARDING Critical Success Factors for application workloads
INTRODUCTION
Do you feel confident you can deliver a smooth, trouble-free switchover to a cloud environment?
The complexity of the migration process is a big part of why enterprises are hesitant about cloud adoption, despite being sold on the benefits of cloud delivery.
There are three critical areas of preparation that are necessary to ensure successful negotiation of those steps:1. Workload analysis
2. Getting the application ready for cloud
3. Choosing the right service provider
CSF 1: WORKLOAD ANALYSIS CHECKLIST
Business impact How business-critical is the workload? Consider the answer against where you are on your cloud journey. Where does the workload fit in the application lifecycle? What does that mean for its cloud environment requirements?
Business
requirements
Given the workload's business use, what are the implications for required service levels, transaction rates, response times, number of simultaneous users to be supported, or other relevant availability and performance-related measures?
What supporting service requirements does the workload have (eg, in terms of backup, disaster recovery, monitoring) and what are the implications for cloud deployment?
Are there any specific security and compliance requirements (eg encryption, isolation, data sovereignty) and what does that mean for cloud deployment?
Application
architecture
Is the application architecture cloud-friendly in any way (eg, is it horizontally scalable in the way that native cloud applications are, or only vertically scalable as traditional enterprise applications tend to be)?
If not, what's involved in refactoring the application for a cloud environment? Are the time and cost acceptable when weighed against the benefits?
Computing resource
and dependencies
What OS, databases and application servers are being used and how hard are they to migrate to the cloud? What are the CPU, memory, network and storage requirements and what will it cost to provide these in a cloud
environment? What other software supports the workload? What are the dependencies or integration touch points with other
workloads?
Operational and
support requirements
How many hours/people are required to support the workload and what do they cost? What are the costs of licensing? What are the operational costs for space, power and cooling? For these and other operational and support costs: will anything be saved by migration to a cloud environment?
CSF 2: CLOUD READINESS
1. PERFORMANCE
2. ELASTICITY
3. RESILIENCE
4. SECURITY
If the app doesn’t perform in the cloud, your desired savings evaporate
Applications must be designed to scale up for agility and down for cost savings
Less control and visibility, build your application ready for failure – rescue
may take longer in the cloud
New risks and vulnerabilities in a shared environment. Security should be built-in,
verified and monitored.
• Identify and fix performance constraints• Decouple compute-intensive components• Fine tune using actual usage patterns
• Don’t design a monolithic application• Break it into scalable components to maximize
scale-up AND -down
• Ensure the application can recover from failure• Build components loosely coupled• Perform tests for failure scenario’s
• Check security, use https / VPN • Encrypt privacy sensitive information• Test all 3rd party components (yourself)
KEY APPLICATION CONSIDERATIONS HOW TO ADDRESS IT
CSF 3: CHOOSING A CLOUD SERVICE PROVIDER
• Do cost model and billing options offer the flexibility that you need?
• Do you have clear visibility of performance, usage, costs and billing?
• Is security built in and of the right standard?
• Does the provider offer the resilience, business continuity and disaster recovery support that you need?
• What kind of support is offered and how is that charged?
• Avoid vendor lock-in: Is the provider using open standards and API’s?
Mig
rati
on
Application ArchitectureNetwork Architecture
Ease of use
Commercials andBilling
Sec
uri
ty
PerformanceGuarantees
Su
pp
ort
Business Continuity
Future
CSF 3: CLOUD PACKAGINGTiered / pre-packaged: Specified amount of CPU core, RAM and disk space There is no room for custom configurations You have to buy the tier that satisfies your requirements
Per-node / VM: Very similar to the tiered approach, each node is a pre-
packaged set of resources When you need more resources, simply buy more nodes Nodes are more granular making customization a little
easier
Independently customizable: CPU, RAM and Storage are not grouped together, nor
are they forced to scale together You need to know exactly what resources the application
requires Only pay for what you use, no tiers to lock you in
Amsterdam • Brussels • Copenhagen • Dublin • Dusseldorf • Frankfurt • Hilversum • London • Madrid • Paris • Stockholm • Vienna • Zurich
www.interxion.com
THANK YOU
Download the full whitepaper here