Moving apps to the cloud: Why, when and how

Commentary - You’ve known this was coming. It started with that small voice in the back of your mind that said “maybe it’s time to start putting some apps in the cloud.” Now it’s an actual question from the CTO: “why aren’t we using the cloud yet?” So, it’s time.

But before you make your move, make sure you’ve really thought through all of the key considerations: What’s in it for your business? Which apps should you migrate first? How can you maximize the advantages and minimize the risks and costs? How will your development teams be affected? How can you make this easier on them? In short, how can you transform this initiative from a source of heartburn into a source of new business advantages? Here is some practical advice for moving apps to the cloud.

The move to the cloud is a business decision
Let’s start by being clear about the answers to two key questions: What exactly does it mean to migrate an app to the cloud, and why would a business want to do it?

Moving an application to the cloud simply means running the app “somewhere” on the internet other than on your own servers. And of course, there are multiple options. You could build your app using your own platform and deploy the entire app-platform bundle to a cloud infrastructure (Infrastructure as a Service, or IaaS). You could create your app using a particular middleware platform and deploy it to a cloud service that supports the same platform (Platform as a Service, or PaaS). Or, if you found an existing cloud-based application that provides the functionality you needed, you could simply use it on a subscription or pay-as-you-go basis (Software as a Service, or SaaS).

These options represent a spectrum of benefits and trade-offs. At the IaaS end, you have maximum flexibility, but developers have a lot of work to do. At the SaaS end, there is less flexibility, but developers have minimal work to do. Most businesses need and want something in the middle, which is why the PaaS model is rapidly gaining momentum.

Now to the second question: Why put apps in the cloud? First and foremost, this should be driven by fundamental business considerations, not simply the desire to offload overburdened IT professionals. The business advantages of moving to the cloud are numerous and compelling. In the broadest terms, there are three key categories of business benefits:

• Agility: The cloud model keeps your business more agile over the lifetime of the app. If IT has to specify, order, receive, install, and configure hardware for each new app, that slows your business down. A self-service interface on the Web is far faster and easier. And as the load on the app grows or spikes, you just add compute cycles, storage, and bandwidth with the click of a mouse—or even automatically with auto-scaling. When it’s time to iterate your app, you can push out the new code in minutes, with no heavy IT process to get in the way.
• Focus: Deploying apps to the cloud lets you focus on higher-value activities. For example, you can focus on hiring top-tier application developers—and these extremely competent developers can focus their time and energy on creating differentiating apps, without the distractions and time-sinks of system administration.
• Cost: Cloud computing cuts costs in two main ways. The first is simply through economies of scale. Cloud service providers can offer focused expertise, standardized components and practices, and massive scalability at a far lower cost than most companies can achieve on their own. The second benefit is the ability to pay for only what you use. You no longer have to over-provision and sink capital into compute capacity (that all too often lies idle) in anticipation of future growth or as insurance against unpredictable spikes.

Pick the apps to move before you select a cloud vendor
You can’t make an informed decision about where to put your apps until you’ve decided which ones to move, and in which order. This, of course, is a complex calculation, but here are a few general guidelines.

• For enterprises, it often makes sense to start with the lowest-risk, lowest-value apps—those with minimal customer data and other sensitive information—or apps that take maximum advantage of the cloud’s elasticity (e.g. apps with extreme spikes in demand or “bursty” behavior that churns CPU cycles for short periods). Alternatively, you might start by determining which apps you do not want to move to the cloud initially. Apps running on servers with very high utilization rates or apps with extremely high I/O requirements may be better off left alone, at least until you’ve gained more experience with operating in the cloud.
• For startups creating cool new Web apps, performance and availability may be determining factors for prioritizing app migration. You might want to start your foray into the cloud with your least bandwidth-hungry apps, or apps that don’t require five-nines availability, so you can get a feel for how your apps run in the cloud. Later, you can move core business logic and/or databases. Also, it makes sense to take an approach that minimizes re-writing, and to trim down unnecessary customizations and special configurations of legacy apps before attempting to migrate to a cloud provider. This way you can simplify and verify before migrating and thus minimize the complexity of transferring components and getting them back up and running.
• Many enterprises and startups alike are now focusing on building new applications specifically for the cloud. If this is the case for your company, you’ll need to carefully consider the capabilities of prospective cloud service providers before moving forward with any specific app development projects.

The single biggest challenge developers face in getting their apps to run effectively in the cloud is deployment. To make this transition as smooth and painless as possible, your company should choose a vendor that supports your development environment and delivers a complete open-source stack devoid of proprietary technology. This will allow you to build your apps using as “vanilla” a configuration as possible for each of the open source technologies in the stack, and avoid vendor lock-in with future platform choices.

The PaaS model, in particular, allows you to focus on your core competency and provide maximum value to customers because it allows you to offload the maintenance of the platform. This gives your development teams more time to innovate and build new features that give your business an edge.

When considering PaaS, it’s important to choose an offering that provides the right range of options for the stack, so you can configure the platform to support the needs of your applications. If you've made changes to your stack in the data center, then you’ll want a vendor that allows you to make those same changes in the cloud. This will not only ease the migration to the cloud, but it will also prevent your application from being constrained by the platform. Specifically, choose a PaaS vendor that:

• Is as open and non-proprietary as possible
• Provides the reliability and performance you're used to in your existing environment
• Gives you the transparency, access, and configurability you need
• Has the expertise to help you if you encounter problems
• Offers the best instrumentation to help you with benchmarking and tuning

Maximize the value of the cloud—with minimal disruption
Once you have some apps up and running and you’ve started to get comfortable with the cloud model, it’s time to start taking some additional steps to optimize your experience.

If you want the best system performance, find a vendor that doesn’t insert their own proprietary technology into the open source stack. Keeping a lean stack will increase performance and reduce the risk of outages related to problems in the vendor’s code. In addition:

• Architect the application so components have minimal dependencies and can be distributed across multiple virtual machines. Architect the components so each can be horizontally scaled as needed (in the cloud it’s faster and safer to scale horizontally by adding more nodes to a cluster rather than vertically by moving the component to a bigger virtual machine).
• Use a language such as Ruby or PHP that supports an agile programming environment, so you can be constantly improving your application in a fast, iterative way, and focus on the application itself rather than the underlying platform.
• Don’t build platform-level infrastructure—use the PaaS provider's (non-proprietary!) functionality where possible.
• For each component or feature you set out to build, ask yourself, “is this truly differentiating business logic that enables me to better compete, or is this a basic capability that should be provided by the platform?”
• Avoid or minimize writing scripts related to deployment, installation, configuration, monitoring, and management.
• Choose a vendor that supports the kinds of transparency, access, and configurability you need. There may naturally be some areas where it really is important for you to customize some technologies in certain ways.
• Fully evaluate the vendor’s pricing before you commit. Find out what the pricing will be by defining some benchmarks of success: 1 server, 10 servers, 100 servers, 1000 servers—whatever makes sense for your situation. Also, be sure to calculate the expected monthly cost at various scales you might reach in the future; compare costs at a given scale for multiple vendors; and compare vendor costs at a given scale to the cost of doing it yourself.

Conclusion
Companies are putting more and more apps in the cloud because the business case is compelling. As organizations gain experience with migrating to the cloud, new opportunities for increasing agility, focus, and cost savings will emerge, and forward-looking companies will find new ways to transform them into competitive advantage. In the meantime, here’s hoping that your move to the cloud is fast, efficient and effective.

biography
Mike Piech is Vice President, Product Management and Marketing at Engine Yard, a leading Platform as a Service (PaaS) provider, headquartered in San Francisco, Calif.