February 19, 2012

Top Myths of Moving Mission-Critical Applications to the Cloud

Research conducted by HP found that the majority of businesses in the EMEA region are planning to move their mission-critical apps to the cloud. Of the 940 respondents, 80 per cent revealed plans to move mission-critical apps at some point over the next two to five years. This is a fairly dramatic shift in how most companies and enterprises in particular plans to embrace the Cloud.

This would be a good time for a reality check, to look at some of the predominant myths about cloud adoption, and what we should change as we start to embrace mission critical applications in the cloud.

Myth 1: The cloud is a silver bullet solution

We have all borne witness to failures with Amazon and other major cloud providers over the past few years. Because of this, we need to realize that in the cloud, failure is prone to happen even more often than with traditional enterprise IT. This instability is built into cloud economics – to move mission-critical application into the cloud we need to cope with these failures, rather than simply try to prevent them from happening. Mission-critical apps are often built to survive failure, but the fail-over processes assumes manual intervention and static configuration.

Reality Check: To move mission-critical applications to the cloud we need to completely automate the fail-over and recovery processes.

Myth 2: The cloud cuts costs

Many people think that cloud economics starts to pay dividends immediately when you move to an on-demand usage model, paying only for what you use. Cloud can actually be fairly expensive when hosting environments in use are not elastic. I was surprised to see how many startups and SaaS organizations still run their applications in the cloud just as they would in any static hosting environment. While the pay-per-use model has a lot of promise for cost-savings if our applications aren’t designed for elasticity the cost of running the application in the cloud may end up costing you more. Most of the mission-critical applications have not been designed for elasticity and on-demand usage.

Reality Check: To benefit from the overall cloud economics, with mission-critical application we need to provide more flexibility in the way we employ elasticity. For example, for applications that were not designed for scale-out we could automate the move from small instances to large instances – this is basically an elastic scale-up model. We can also embrace hybrid models where most of our resources are statically provisioned and we can employ elasticity only to part of our resources that are easy to scale – such as the web tier.

Myth 3: The cloud is simple

When cloud came out it was touted as a much simpler model for running IT. The common example given was usually the time it takes to get a new machine into our data center. In traditional enterprises this could take weeks, where in cloud getting a new machine can be done in a matter of minutes. However, as IT becomes more efficient, this is no longer the case.

If we compare the process of running applications within our IT with the way we run applications in the cloud, we will see that the time it takes to bring in a new machine is only small part of the actual process of running and managing the application. Quite often this process is actually much more complex in the cloud. This is mostly due to fact that cloud is more dynamic in nature, and there is a lack of tools that can provide the level of control that is expected when dealing with mission-critical applications.

Additionally, most of the existing mission-critical applications come with the requirement for a high degree of management and control. However, a lot of the management and monitoring tools involve a high degree of manual configuration just to get the required monitoring capabilities in place, and manual processes to get a new version or feature of the application into production.

Reality Check: To move mission-critical application into the cloud all these processes needs to be completely automated from the development stage up to the production.

Myth 4: The cloud is inherently scalable

While cloud can scale to 100’s of machines via an API, the truth is that most applications were not designed to take advantage of this approach. So while cloud itself can be fairly scalable the application running on the cloud doesn’t become anymore scalable by simply running in that environment, unless they were designed for scaling from the onset.

Most of the existing mission-critical applications were not designed for cloud scaling. People believe to fully benefit from cloud scaling often involves a complete re-write of the application, and most enterprises just aren’t ready to make such as major shift.

Reality Check: To move mission critical application to the cloud we need to do this in baby steps, starting with only automation and repackaging of the apps, without any code changes. Later steps would involve changing of modules within the application, as needed.

Myth 5: Cloud Bursting

Cloud bursting is an economical model that enables you to combine statically provisioned resources for the part of your application that needs 24/7 utilization and use on-demand resources on the cloud only in cases where you’re running out of resources. In this model, you can design your cost at the optimum level between fixed and on-demand cost.

Many cloud providers offer network connectivity (a.k.a VPC) between private and public cloud resources to enable cloud-bursting and hybrid clouds. Having said that, many applications (mission-critical application in particular) tend to be data sensitive.

Reality Check: To implement cloud-bursting not enough to have network connectivity, you also need to be able to move data not just processes. Content delivery networks (CDN) now make it possible to bring static data closer to the processes. For mission critical applications the same is needed for transactional and analytics data – without it cloud-bursting may remain an interesting theoretical model.

Final Thoughts

As the industry becomes more mature and ready to move mission critical apps to the cloud, we need to manage our expectations from the cloud infrastructure. It’s important to realize that while cloud holds a lot of promise for cost savings, scaling and more, how we run our application and business in the cloud remains our sole responsibility. In this post I tried to outline more specifically the top misconceptions we need to make clear in order to start moving mission-critical applications into the cloud.

I also believe that Hybrid cloud is the way to go – not just for legacy applications but also for new applications. For this to happen we need to think of how do we make cloud-portability a practical reality, as well as how do we practically migrate mission critical applications that were not built for a dynamic environment into the cloud without forcing a complete re-write. Based on the experience with many of the DevOps automation tools over the past years I believe that we can gain a lot by starting with automation of deployment, fail-over and scaling processes as well as automation of the management and monitoring of our applications.

With Cloudify we took many of those lessons and packaged them into a product that makes the process of moving mission-critical applications into the any cloud vastly simpler. Our experience on that regard has proven to be tremendously successful as we proved to be able to take real life telco application that wasn’t written to cloud and migrate it into the cloud in matter of 4 weeks without any code change.

Comments

Research conducted by HP found that the majority of businesses in the EMEA region are planning to move their mission-critical apps to the cloud. Of the 940 respondents, 80 per cent revealed plans to move mission-critical apps at some point over the next two to five years. This is a fairly dramatic shift in how most companies and enterprises in particular plans to embrace the Cloud.

This would be a good time for a reality check, to look at some of the predominant myths about cloud adoption, and what we should change as we start to embrace mission critical applications in the cloud.

Myth 1: The cloud is a silver bullet solution

We have all borne witness to failures with Amazon and other major cloud providers over the past few years. Because of this, we need to realize that in the cloud, failure is prone to happen even more often than with traditional enterprise IT. This instability is built into cloud economics – to move mission-critical application into the cloud we need to cope with these failures, rather than simply try to prevent them from happening. Mission-critical apps are often built to survive failure, but the fail-over processes assumes manual intervention and static configuration.

Reality Check: To move mission-critical applications to the cloud we need to completely automate the fail-over and recovery processes.

Myth 2: The cloud cuts costs

Many people think that cloud economics starts to pay dividends immediately when you move to an on-demand usage model, paying only for what you use. Cloud can actually be fairly expensive when hosting environments in use are not elastic. I was surprised to see how many startups and SaaS organizations still run their applications in the cloud just as they would in any static hosting environment. While the pay-per-use model has a lot of promise for cost-savings if our applications aren’t designed for elasticity the cost of running the application in the cloud may end up costing you more. Most of the mission-critical applications have not been designed for elasticity and on-demand usage.

Reality Check: To benefit from the overall cloud economics, with mission-critical application we need to provide more flexibility in the way we employ elasticity. For example, for applications that were not designed for scale-out we could automate the move from small instances to large instances – this is basically an elastic scale-up model. We can also embrace hybrid models where most of our resources are statically provisioned and we can employ elasticity only to part of our resources that are easy to scale – such as the web tier.

Myth 3: The cloud is simple

When cloud came out it was touted as a much simpler model for running IT. The common example given was usually the time it takes to get a new machine into our data center. In traditional enterprises this could take weeks, where in cloud getting a new machine can be done in a matter of minutes. However, as IT becomes more efficient, this is no longer the case.

If we compare the process of running applications within our IT with the way we run applications in the cloud, we will see that the time it takes to bring in a new machine is only small part of the actual process of running and managing the application. Quite often this process is actually much more complex in the cloud. This is mostly due to fact that cloud is more dynamic in nature, and there is a lack of tools that can provide the level of control that is expected when dealing with mission-critical applications.

Additionally, most of the existing mission-critical applications come with the requirement for a high degree of management and control. However, a lot of the management and monitoring tools involve a high degree of manual configuration just to get the required monitoring capabilities in place, and manual processes to get a new version or feature of the application into production.

Reality Check: To move mission-critical application into the cloud all these processes needs to be completely automated from the development stage up to the production.

Myth 4: The cloud is inherently scalable

While cloud can scale to 100’s of machines via an API, the truth is that most applications were not designed to take advantage of this approach. So while cloud itself can be fairly scalable the application running on the cloud doesn’t become anymore scalable by simply running in that environment, unless they were designed for scaling from the onset.

Most of the existing mission-critical applications were not designed for cloud scaling. People believe to fully benefit from cloud scaling often involves a complete re-write of the application, and most enterprises just aren’t ready to make such as major shift.

Reality Check: To move mission critical application to the cloud we need to do this in baby steps, starting with only automation and repackaging of the apps, without any code changes. Later steps would involve changing of modules within the application, as needed.

Myth 5: Cloud Bursting

Cloud bursting is an economical model that enables you to combine statically provisioned resources for the part of your application that needs 24/7 utilization and use on-demand resources on the cloud only in cases where you’re running out of resources. In this model, you can design your cost at the optimum level between fixed and on-demand cost.

Many cloud providers offer network connectivity (a.k.a VPC) between private and public cloud resources to enable cloud-bursting and hybrid clouds. Having said that, many applications (mission-critical application in particular) tend to be data sensitive.

Reality Check: To implement cloud-bursting not enough to have network connectivity, you also need to be able to move data not just processes. Content delivery networks (CDN) now make it possible to bring static data closer to the processes. For mission critical applications the same is needed for transactional and analytics data – without it cloud-bursting may remain an interesting theoretical model.

Final Thoughts

As the industry becomes more mature and ready to move mission critical apps to the cloud, we need to manage our expectations from the cloud infrastructure. It’s important to realize that while cloud holds a lot of promise for cost savings, scaling and more, how we run our application and business in the cloud remains our sole responsibility. In this post I tried to outline more specifically the top misconceptions we need to make clear in order to start moving mission-critical applications into the cloud.

I also believe that Hybrid cloud is the way to go – not just for legacy applications but also for new applications. For this to happen we need to think of how do we make cloud-portability a practical reality, as well as how do we practically migrate mission critical applications that were not built for a dynamic environment into the cloud without forcing a complete re-write. Based on the experience with many of the DevOps automation tools over the past years I believe that we can gain a lot by starting with automation of deployment, fail-over and scaling processes as well as automation of the management and monitoring of our applications.

With Cloudify we took many of those lessons and packaged them into a product that makes the process of moving mission-critical applications into the any cloud vastly simpler. Our experience on that regard has proven to be tremendously successful as we proved to be able to take real life telco application that wasn’t written to cloud and migrate it into the cloud in matter of 4 weeks without any code change.