Building a cloud strategy can be a challenge, and moving existing applications to the cloud can be downright stressful. You don't want to miss out on the business and technical benefits of doing so, but you also don't want to risk disrupting customers in the process. 

In my previous blog on this topic, I discussed the business criteria around determining what should move out to the cloud. In this installment, let's explore the technical criteria — and rewards — to help determine which parts of your applications should move into the cloud

What Goes Up ... Stays in the Cloud

As an enterprise architect, your biggest motivation should be to solve business problems. But sometimes the reasons for an architecture decision are purely technical. And, in the case of cloud computing, what goes up will not come down, so to speak. When I've helped corporations build a cloud strategy, the main technical drivers for determining what should become a service have been the following:

·         Scalability: Will moving a key component into the cloud help increase scalability? If the answer is yes, this is a good choice. Sometimes, the cloud even presents opportunities to increase scalability that cannot be reached otherwise. For instance, REST-based services, with the low overhead of XML over HTTP compared with other component technologies (such as .Net and CORBA), provide extreme scalability. This scalability can be enhanced by Web-based technology such as highly tuned Web servers and load balancers. Also, individual services can be scaled differently, according to usage patterns. When part of a monolithic application, all of your components must be scaled identically.

·         Elasticity: Building on scalability, on-demand computing applies resources to a cloud-based service based on application demand. Cloud providers often offer provisioning services that automatically scale a service to meet demand, or provide management services to allow you control this according to key parameters – i.e. bandwidth, transaction rates, and so on.

·         Portability: Often, moving legacy systems to the cloud via Web adapters or an enterprise service bus can provide portable, platform-independent access to an otherwise proprietary system. Doing this can help expose a specialized system with a restrictive API, or with single-platform access requirements (i.e., a Windows API or a Unix signal handler) to other applications, regardless of platform or language. If you have a legacy application that's tied to a single platform or technology, consider moving it to the cloud (by building a cloud-based adapter service) for platform-independent reuse. Note here: service enabling an application can be a considerable task, and require a great deal of investment in terms of time and money.

·         Stateless components: If an application contains components where the logic is stateless by nature (i.e., transaction-oriented, message-oriented and so on), it is an easy candidate for the cloud. Moving these apps preserves their stateless contract, helping to further isolate their logic and more easily black-box unit test them. The benefits are often higher-quality services and applications, and a more iterative development and deployment process. For example, once moved to the cloud, the decoupled nature of the related services allows them to be revised and deployed according to their own independent schedule, decreasing the number of dependencies within a single application.

·         Data intensiveness: Software components that are data intensive (particularly around CPU loads) and thus usually requiring extensive database access can be moved to the cloud with many benefits. For instance, the cloud abstracts database access and hides it from the consuming application, as opposed to having access to a database scattered throughout your application. It also helps to provide increased scalability and performance, as you can scale and distribute a cloud-based service more easily than a database server.. Third-party technology, especially open source packages such as Terracotta's Ehcache, can yield benefits only when the applicable logic is moved to the cloud. If abstraction and independent caching can help your application performance, moving the applicable components to the cloud can quickly achieve this.

Administration

Crossing the boundary between business and technical reasoning, ease of administration is another factor to be considered when determining what can be moved to the cloud. For example, the cloud can help to remotely deploy, administer and configure individual components in new ways. Existing third-party software, such as CA Technologies' IT Management Software as a Service (SaaS) — is a good example of this.

Often, managing smaller, individual portions of otherwise monolithic applications in the cloud ensures quicker deployment, lower costs and greater system uptime. Simply put, if moving a component to the cloud helps you outsource its management, the cost savings over time can justify your decision. Centralizing administration in this way also serves as a gateway in your architecture, helping to fight duplication and wasted effort reinventing the wheel.

We’d love to hear about your own considerations around moving workloads to the cloud, both on the business side as we last discussed and on the technical end. Please weigh in on what factors into your discussions around business, technical and administration issues.