|
| Figure 1: Timothy Chou, Cloud application workloads, March 2011 |
10. Does my workload profile match a cloud-based approach?
The first question to ask is whether cloud computing has an advantage for you. That answer starts with checking what workload represents your business best.
Figure 1, “Cloud Application Workloads,” shows four models that can benefit from cloud services.
High Growth: Many startups move to the cloud because they have no legacy systems and expect rapid growth.
On-Off: I often tell my customers: “a key advantage of cloud computing is not when you use it but when you don’t”. Your cost in off mode is virtually zero, which can’t be achieved by an in-house solution.
Aperiodic Bursting: When you have brief unpredictable spikes in workload, the ability to spin up extra capacity can save your customer’s website experience. Think of the Red-Cross that has to respond rapidly to events it won’t know ahead of time when they will happen.
Periodic Bursting: Similar to aperiodic bursting but with a frequency and pattern that allows you to better predict additional resource requirements and optimize cloud infrastructure utilization accordingly.
One of the possible outcomes of answering this question is the realization that merely transitioning current workloads into the cloud might not be the most effective method since a premium is paid for pure on-demand resources.
Another possible outcome is that it might not be feasible to find a matching provider for your workload today.
However, a lot of innovation is happening and new providers that optimize for your specific workloads might emerge shortly. Example: High Performance Computing (HPC). Initially, the thought of large memory footprints and core counts – let alone GPU availability -- in the cloud was not possible. Today certain providers have emerged to provide specific HPC solutions.
9. What is my computing profile?
The compute infrastructure profiles (cores/RAM/OS) provided by a cloud service need to match your requirements. Some providers use a well-known architecture, while others are more hardware-agnostic. Answering this question helps identify technical capabilities or restrictions.
As an example, Amazon’s ECU metric is a great way to normalize compute units but requires a translation from traditional GHz and number of cores to an ECU-based profile.
An ECU represents a 1Ghz core for 1 hour while most computers today use multiple cores at higher clock speeds than 1 Ghz.
In addition Providers charge differently or have different ways to make a specific profile available.
8. What is my storage workload profile?
It is important to understand not only how much data storage an application needs, but also the performance profile for that storage. For example:
- Databases are notoriously sensitive to latency, while most static data can be provisioned through network-attached solutions with high throughput.
- How often is data written vs. read? Some providers charge for outgoing but not incoming.
- Should it behave like a local disk or can it be network-attached?
The answers to these questions drive technology requirements that affect which providers will be able to deliver.
7. How protected do I need to be?
How much “security” do you need? This really is a specification question and far from absolute or binary (am I secure or not secure?).
Security is a shared responsibility between you and the provider. In the scope of this article (IaaS), you will have to provide and manage the security platform from the OS up. However, providers have a vested interest in avoiding security incidents, so they often have tools, methods and expertise to support your efforts beyond what you could do alone.
Some examples of protection aspects you want to consider:
- User authentication
- Network encryption
- Data Encryption
- OS vulnerability prevention (how systems are patched)
- Intruder Detection (IDS)
6. What level of availability do I need?
Consider how your application handles network, system and other failures. Does the platform have to be highly robust, or can individual components fail without causing a service interruption?
Ask the provider what types of SLAs are available. SLAs typically include availability aspects and give you an idea of what the baseline is. Since most providers use a shared hardware platform, the impact of a failure is very significant to them. As a result, the standard availability profiles are often much higher than the average in-house compute deployment.
For example: A Tier III Data Center has N+1 redundancy for all vital components. Due to scale it ends up being 3 + 1 or more, while in an in-house solution it often means 1+1. You notice the overhead going down from 50% for in-house to 25% for a large Data Center.
5. What level of manageability do I need?
The ability to integrate a cloud service with your processes and automation systems can be a key competitive advantage. Check what measurements, reporting and integration capabilities (API, web-services, email etc.) are available. These will also help you manage your internal SLAs if needed.
Some providers surround their infrastructure with management tools to augment processes like software development and systems management. In essence, some of them are adding platform services.
4. Where is my cloud?
It is important to know where the physical infrastructure is located, especially if you are regulated and have to be mindful of information flow restrictions. It is also an important question to answer in context of a possible Disaster Recovery scenario or addressing how to get data into and from the cloud service.
The distance to a cloud service provider also impacts your ability to integrate existing systems by having an effect on latency and cost for networking. Some of the more established providers are deploying localized solutions in Europe, Asia and the United States.
3. What scalability do I need?
If you burst, how much will you burst? How many instances do you need to spin up at what rate?
The time to scale is largely dependent on the time to boot a system. It can take 5 to 15 minutes, which can be too slow for some use cases.
Other workloads require the use of thousands of cores. Most providers will tell you to “give them a call” before you do so. Don’t expect any provider to have true “unlimited” resources, even though relatively speaking, it might seem this way.
Judge long-term needs in the context of scale, and map those needs to the provider’s capabilities and roadmaps.
2. How much is this going to cost me?
One major challenge with all the options available today is to normalize the offerings and get a fair comparison. Providers differ not only in functionality, but also in billing and metering methods.
To address this challenge use pricing benchmarks to compare offerings. For example:
- Compute benchmark: 2 Core (@2.5GHz) with 2GB RAM costs $x.xx /Instance/month
- Storage benchmark: Cost of 1 GB Usable storage, SAN/NAS based on 10TB base infrastructure = $x.xx/GB/month
- Backup benchmark ($x.xx/GB backed-up)
- Network benchmark: ($x.xx/GB/Month transferred in and/or out)
1. No really, how much is this going to cost me?
Aside from the operational cost of running a project in the cloud, key long-term considerations impact the cost profile of cloud solutions. Think about the following:
- Should I (and what would the cost be) re-architect an application to take advantage of this new business model?
- What would be the Return On Investment over time?
- What is the cost to reorganize IT around this new compute and storage paradigm?
- What new skills do I need to invest in?
Conclusion
It is clear that cloud services will change how we use IT. Not only will usage and cost profiles change but it will also allow for different uses of IT infrastructure allowing for different problems to be solved and new business models to be created.
The complexity of the matter requires careful planning and analysis of your requirements and matching cloud services. It will be up to you to find the right balance between functionality, quality and price for your project. Answering the above questions will be a good start to get there.