What not to put in the cloud
This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
The cloud promises unlimited capacity, pennies per hour to operate, 4+ nines of uptime and infrastructure managed by a dedicated staff. Even technical challenges around security and compliance can be achieved and are no longer suspect. So why wouldn't you send everything to the cloud?
Obviously there is much more involved than tossing out your current plan and bringing in a "magic cloud" to solve all problems. Some apps are a better fit for a private cloud or no cloud at all. Some apps are a better fit for public cloud. And, often the same app's best-fit environment isn't the same for its entire existence. That makes the answer to the question, "What should I put in cloud?" a bit more complicated.
TROUBLESHOOTING: 5 signs that you've lost control over your cloud apps
Cloud success is all about strategy. If all your team is worried about is cutting your IT budget and that's your only success metric, cloud may not be right for you. But the benefits can't be reaped by simply dumping the old infrastructure for new, and your goals can't be reached if you try to manage the new infrastructure with an old way of thinking.
If, however, your strategy is to reduce overall cost of managing your IT infrastructure, and you tackle the project with an eye toward transforming your way of thinking, cloud could be a good fit for you.
Not only do you need a strategy for how cloud will work with your existing infrastructure, but you also need a strategy for each application or workload you're evaluating. One popular strategy to optimizing your cloud is to look at specific workloads and applications and determine which placement will help achieve the highest ROI at what time.
The cloud application life cycle
The life cycle of an application is dynamic. In the beginning when the application is new and less known, you can make educated guesses about what kind of bandwidth, storage memory and compute it will need. But new workloads can be bursty and behave unexpectedly. The cloud is perfect for new and emerging applications because they are low risk. You can commit fewer resources than you think you need and then burst into more resources as you watch and learn how it behaves. Emerging applications could be anything from test/development all the way up to the mission-critical application.
As those applications stabilize, they begin to become more predictable and mature. As they evolve the resources required become more predictable and you may benefit from moving the application from the public cloud to an internal environment where it can live out its stable time frame. The costs benefits of agility and scalability can be wasted on stable, mature apps. [Also see: "Gartner: 5 things a private cloud is NOT"]
Legacy applications seem to take too long to go away. They have passed the point of maturation and the resources used are in decline each month. They may be taking up valuable IT manpower, time and space in your internal environment. You can't just make them disappear. Cloud is quickly becoming a perfect-fit retirement home for applications. The biggest benefit is being able to tie real costs to the application, and show the costs back to the owners of the legacy app. They may reveal that the application's usage is not nearly worth it and speed up its decommissioning. After that, the cost simply goes away.
What doesn't work
From patterns we've seen, there are a few types of applications you should beware of moving to the public cloud. They might not achieve a greater ROI in public cloud than they could in private cloud or another internal environment. However, applications are dynamic and there are always exceptions to the rule.
RULE: Mature, stable mission-critical apps should not live in public cloud. As mentioned in the life cycle description, value from cloud typically doesn't come from the stable, predictable time frame of its life. Bursty and growing or declining applications get more value and a higher ROI in the public cloud than stable applications do, which is why it's recommended to host stable apps in your private cloud.
EXCEPTION: SaaS mission-critical applications often thrive in public cloud. A mission-critical software-as-a-service (SaaS) application often lives its entire life cycle in the public cloud. The main reason SaaS applications stay in the cloud forever is because in most cases they are green-fielded in the cloud and constantly rely on the elasticity of IaaS to continually grow and contract the environment as usage patterns swing. SaaS apps usually follow a similar pay-as-you-go billing pattern and it's most cost-effective to match infrastructure costs with revenue.
RULE: Highly integrated, business-critical apps should stay where they are. Any highly integrated business app, like your ERP or your finance applications, should stay where they are because it would be nearly impossible to move the application without causing problems that would grind business processes to a halt. Your ERP is your logistics system and you can't get more integrated than that. Any application that would halt operations if you moved it wouldn't be worth moving.
EXCEPTION: Only rarely will you have an exception to this rule. One exception might be that you don't have an ERP solution yet and you're looking to start one. As long as you aren't already integrated into the business, it can make sense to start off in the cloud so you have the benefits from the start and don't have to worry about the mobility of it later. It's possible that if you're young and looking for integrated solutions, than going to a SaaS solution will make sense. The key question is, "Have you already done the integration?" If not, then you can do a cloud-based SaaS because it's probably better in the long run.
RULE: Bursting into the public cloud doesn't work. There's a general understanding that you can have your application live in your internal environment and when it needs more room you can "burst" those extra resources into the public cloud. It's an idea of bursting between clouds and owning the base while renting the burst. That idea isn't widely in use because it hasn't been successful yet. The required technologies are not as agile as they need to be to create the desired efficiencies.
EXCEPTION: There are two types of cloudbursting that are in wide use and capitalize on the benefits public cloud has to offer: horizontal burst and vertical burst. Vertical cloudbursting refers to intracloud application burst when your application lives in a cloud with enough room and resources to burst up to a certain percentage. This is intracloud burst because it's bursting into the same cloud in which it's living. [Also see: "Gartner: Cloud computing's most over-hyped terms"]
Horizontal burst, or intercloud burst, is how bursting between clouds is working most commonly right now, but it isn't following the "burst-into" philosophy commonly thought of. Rather, it refers to moving other smaller applications off to the public cloud purely so you have the room and resources to allow your private cloud applications to burst within their private cloud without reaching capacity. There may be no more benefits from moving those smaller, stable workloads off to public cloud other than allowing room for your private cloud applications to be able to burst.
Based on the characteristics and life cycle of enterprise applications running in the cloud, you should start to have a good idea what will and won't work. You shouldn't try to shoehorn cloud into your strategy by dumping every app you have into public cloud immediately; it might not get you the most efficient, economic results possible.
Don't just rush to pick the applications that are consuming the most pain, or consuming the most resources, or the most data. Chances are those are your mission-critical apps which could be highly integrated to other apps that would also need to move to the cloud. Cloud is not a cure-all prescription for your IT pain points; rather it works harder for you when you're strategic about which applications are placed in which environments. Success is about executing a total cloud strategy for each application.