Development and Deployment Changes in the Hybrid Cloud
In a hybrid cloud environment, you may want to work with your partners via a hybrid cloud service or develop and deploy some cloud-based applications specifically for your sales team. You’ll need to know how to build, deploy, and manage applications in the cloud and for the 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.
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: 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 designed and built 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 use 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, 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 understand how to abstract away some of the complexity. 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.