Examining Changes for Development and Deployment in a Cloud

There are numerous scenarios in which you might want to write an application for the hybrid cloud. Here are a few:

You want to write an application for the cloud that will work with the customized applications you already have in place.

You want to write applications that can work on-premises and reach into the cloud. For example, these applications may burst into the cloud for peak situations.

You may want to write applications for the cloud that can be leveraged across multiple clouds.

Of course, the market is still very nascent when it comes to building and deploying hybrid cloud–based applications. So, what’s important? Some parts of the puzzle include

Service orientation: In Chapter 3, we discuss service orientation in the cloud. As we mention in that chapter, service orientation is an architectural approach based on implementing business processes as software services. These business services consist of a set of loosely coupled components — designed to minimize dependencies — assembled to support a well-defined business task. Enterprises that have invested in designing infrastructure with a service-oriented approach will be in a better position to integrate internal services with cloud services. Enterprises that have focused on taking existing infrastructure and wrapping key components so they can be exposed as services are ready to begin to integrate service in a hybrid environment.

Scalability: Applications will need to be architected to work in a cloud so they can scale out across cloud boundaries. It’s not just about writing an application that’s going to live on a few servers. It’s about building them to utilize potentially many servers. When people familiar with the cloud talk about scalability, they use the terms scale-up versus scale-out. Scale-up refers to increasing memory/CPU on the server, and scale out refers to scaling resources across many, many nodes. You need to architect an application in a way to work across machines. You also need to predict how an application behaves because it needs to be built in a way that can support this cloud horizontal scalability. In other words, the code needs to potentially work as pieces across multiple machines. This includes the facts that the application will need to support a stateless protocol model (that is, each call on an object can stand alone), that each piece of code is modular with loose coupling (as described in the previous bullet), and that the same code can be run across multiple machines.

Service synchronization and dependencies: An application might include databases, message services, and other services. Traditionally, if an application needed a certain service, say a database service, the service was handled by mapping references to physical addresses. Of course, this changes in the cloud because you may not know the IP addresses beforehand, which means that finding resources needs to be part of the application.

Availability: Experts also advise that developers need to consider a plan for failure, including considerations around Mean Time to Failure (MTTF, the predicted elapsed time between system failures) and Mean Time to Recovery (MTTR).

If you look at any one enterprise, there’s a good chance you’ll find a mix of development environments and processes. Development may be done in silos for siloed applications. Developers may be restricted by the lack of resources. Perhaps the tools they’re using were developed to handle the most complex problems. As companies transition to developing in the cloud, it’s important for them to begin understanding how to abstract away some of the complexity. Of course, doing so will take time.

Big benefits of developing and deploying applications to the cloud are its elasticity and scalability. The infrastructure you need for development and deployment can be automatically scaled up or down, based on the requirements of the application. This field is evolving, however, and it pays to do the math. Many vendors will charge based on the utilization of underlying resources, which might include usage per hour, processing, bandwidth, and storage.

We’ve been talking about developers in both medium- and large-sized corporations that are building applications to run complex businesses. There’s a whole different class of developers — the Internet-scale developer— who may be interested in different sets of problems than enterprise developers. These Internet developers address problems that, from the get-go, are ready for scale and building for performance and failures of the Internet. One example of an Internet-scale developer is a social media analytics services company that develops analytics that cull through massive amounts of social media data. This developer may be using new suites of tools like those we mention in Chapter 11 for data and big data.