ra2 studio - Fotolia
Unless you don't believe in public cloud computing at all, your company will become a hybrid cloud user. That means...
all of your application testing and deployment will have to accommodate the hybrid cloud, and most companies' application lifecycle management processes just aren't ready. Getting yours ready means mapping the specific differences in ALM driven by hybrid clouds, understanding how your hybrid goals expose your applications to hybrid issues, reviewing your ALM practices and tools to address these areas of change, and projecting the impact of hybrid cloud adoption to futureproof your solutions.
Application lifecycle management is driven by a lot of small issues on both the technology and business side, but basic ALM approaches are usually threatened only by something big. Hybrid cloud adoption will change small things, but the big thing it changes is the mapping between applications and resources. Architects and development managers are already addressing personalized productivity enhancement and mobility with Agile application architectures. Hybrid clouds then demand these applications be deployed on a resource pool with vast differences in cost and performance.
Hybrid clouds are often presented as a step in evolution from a pure data center-driven IT model to a pure public cloud model, but most enterprises know they aren't going to totally replace data centers. The real driver in hybrid cloud is the need for ad hoc resource augmentation. You can't easily expand and contract your data center, but you can add cloud capacity when needed and retire it when the need passes. Resource control is challenging in hybrid clouds, but resource dynamism is probably the only current justification for them. The question is what specific driver demands the dynamism?
The most common reason businesses look to a hybrid cloud adoption strategy is that they are building worker-customizable or mobile-driven front-end processes to augment their current transactional applications. In effect, the front-end processes are migrated to the cloud and integrated with legacy workflows at a fixed point. Both sides of the hybrid relationship are largely independent except at this hand-off.
Cloud bursting, or the allocation of public cloud resources to augment data center capacity when workloads increase or in a period of failure, is the second reason for hybridization. With cloud bursting, the pool of resources expands and contracts with work, and, in theory, each application component that is capable of being used in a load-shared way can be replicated then scaled back as needed.
Most businesses agree that ALM in front-end-driven hybridization can be addressed in the same way as Web front-end integration or even multi-platform -- Linux and Windows, for example -- data center ALM is addressed. Detailed ALM tools and processes are first selected for the public cloud and private IT resources, and the two are then harmonized at the point, in time and technology, where they meet.
Cloud bursting is more difficult because the application's components move in terms of resource commitments. Each piece of an application, each step in a test or workflow, might be supported in or out of the cloud. Information must then flow along different paths, with different integration and different quality of service.
Making ALM work in a cloud bursting application starts with having massive test data generation capability. While some businesses rely on simple tools for data generation in ALM, that's not going to work in cloud bursting ALM because you'll be unable to force the scaling in and out of resources. Random data generation for functional testing is still important, but you may want to separate it from volume test data generation to cut ALM testing time and complexity. Verify workflows overall, then verify cloud bursting performance and integrity second.
One of the important things to test in hybrid cloud ALM is the specific details of the DevOps processes used for application component deployment and decommissioning. For cloud bursting, it's critical that you get a new component instance up and running quickly and taken down gracefully, meaning that all the pathways used for connection of the instance are removed without impacting the rest of the application.
While dictating application design and operation may not normally be considered an ALM mission, hybridization dictates the use of DevOps if there's to be any hope of creating a robust application environment and a stable and effective test process. In the cloud, there is a visible trend toward model-based rather than script-based DevOps, and model-based systems will require careful testing of each model and all of the model's operating states. In fact, truly integrated development and operations practices makes hybrid cloud ALM easier and more reliable.
In most cases, the best results in hybrid cloud ALM will be obtained from integrated development-testing tools, or from suites of tools that are designed to work together. Users of development tools from IBM, Microsoft, CA and others can be assured the pieces will all fit. For those who want to assemble development and ALM tools, it may be wise to use a hybrid cloud application as a testbed to ensure you encounter all the conditions hybridization will create.
For those who may have felt comfortable with the notion that their cloud-front-end mission for hybrid cloud adoption would keep them out of the most complex areas of ALM impact, then be prepared. The long-term trend is toward "Agile applications" whose workflows and structures are assembled almost ad hoc according to worker need, and that use both data center and public cloud resources based on worker and data location and pricing and performance policies.
This Agile-application future for ALM raises many questions, even without considering hybrid cloud adoption resources. The traditional notion of an "application" is weakened as worker productivity gains depend increasingly on microservices tuned to events. ALM will have to evolve to meet this challenge and also to accommodate the dualism of resource ownership that hybrid clouds demand -- now and likely for a long time to come.
Migration strategies for hybrid cloud
Hybrid cloud benefits may fall short
Performance and security issues in hybrid cloud adoption