Many planners and architects still think of the cloud as only a place where applications are hosted. While you can certainly do that, users report that cloud utility is enhanced if you host selected pieces, or components, of apps in the cloud. This "component cloud" model is essential when a company has adopted software component architectures such as SOA or embraced agile development practices. A component model could be a glimpse into the future for the next evolution of cloud.
Enterprise cloud commitments today tend toward one of two models: server consolidation hosting or extensions to online apps that support Web access to retail or support portals. These apps are simple in a structural sense; they tend to be monolithic rather than made up of separate components -- but these simple applications create challenges in deployment and integration.
A component cloud model can help overcome these challenges, but at the tradeoff of increasing complexity. Without careful planning, component cloud's risks will destroy cloud's value proposition and threaten its evolution.
A component cloud is essentially a "component as a service" model. It differs from the typical Software as a service (SaaS) model in that components are deployed and redeployed independently, then integrated into apps through a series of specific steps. The model is similar to one companies use to manage service-oriented architecture (SOA) applications developed to exploit shared components -- but it has the added dimension of cloud hosting, scalability and workflow management.
In the long run, many planners and architects see the component cloud as the basis for a whole new application development model based on the true nature of 'as a service.'
In the long run, many planners and architects see the component cloud as the basis for a whole new application development model based on the true nature of "as a service." In this new cloud model, a pool of components is mapped to a pool of resources as needed to sustain quality of experience (QoE). Applications are then created by steering work among the components. This is the foundation of the modern principles of agile development, united with a model of cloud hosting in which public and private cloud resources are different only in the policies under which they can be used.
When does it make sense to use component cloud? The model is ideal for failover and scalability apps of public cloud services because they can host a single component of an application. Component cloud is also an ideal, and perhaps essential, part of a cloud SOA strategy. SOA applications that can accept multiple copies of a component can be made more resilient and achieve higher levels of performance by controlling component instances to match transaction load -- which is exactly what a component cloud model supports.
Automation decreases complexity of the component cloud model
The component as a service model is complicated because requires IT pros to think of every application component as an individual cloud application that needs to be deployed and integrated. This multiplies the challenges of sustaining a pool of applications as well as getting apps deployed, linked with workflows and managed.
The as-a-service model is an important step toward building a component cloud without exploding complexity. If every component is a service represented by a URL, the workflow processing -- such as ESB -- can simply link to the components via the URL, making it possible to move them around as needed.
The key requirement in supporting a component cloud model for your own business is strong automation of your applications' deployment and management processes.
The goal of component cloud operations is to converge both the workflows and the component deployment processes on the as-a-service URL, so that standardized tools find all the pieces to properly integrate into one app. Rapidly evolving DevOps tools and application lifecycle management (ALM) will help you place components in the cloud and connect workflows without explicit human operator support.
Major issues facing the component cloud model
The biggest problem users report is not knowing whether a component deployed by one application is available for use by another. Architects and cloud service planners need to review the ways that applications find and share components to ensure that cloud deployment of components doesn't distort or break this process. Take special care to be sure that multiple copies of a component, added to improve performance, are available to all the apps that are expected to share the component. This may involve careful management of load-sharing among components and fine-tuning any cloud platform tools, such as AWS Auto Scaling, you expect to use.
For public cloud services in the component cloud, there are two specific issues most likely to impact cloud admins: network integration of workflows among components -- inside and out of the public cloud -- and harmonization of public cloud tools for scaling and replacing components with application workflows. When a new component is added to the cloud through explicit deployment -- e.g., via DevOps -- the component's integration into application workflows can be part of the DevOps requirements. If the cloud spins up its own copy, you will still need the necessary integration, but unless the cloud provides some notice of the change, how do you know when to run the necessary DevOps processes? Cloud bursting and failover are more powerful in the component cloud because per-component replacement and scaling are more responsive and less destructive to transaction integrity -- but they are going to be more complicated.
Taken to extremes, the component cloud could support ad hoc component integration into workflows, creating the potential to build applications quickly to respond to problems or opportunities. This highly dynamic model of applications could create a partnership between devices, application agents that draw processing from component cloud resources, and software sources that could publish useful application components in "as a service" form for integration. It could also facilitate per-worker customization of applications and the integration of contextual variables, such as worker location and presence.
Applications and software development are being driven to a component model already. Cloud hybridization and contextual services -- including LBS -- are certain to accelerate the componentization trend. That's why it's important to reflect the inevitability of component clouds in cloud planning.
About the author: Tom Nolle is president ofCIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
