One of the most important cloud computing developments is the realization that cloud isn't the be-all and end-all of IT. Enterprises will likely retain -- and even expand -- their data centers. This increases interest in hybrid cloud technologies that exploit data center and public cloud services.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Early hybrid cloud applications were static, focusing on a "front-end" cloud and "back-end" data center. However, emerging application models for hybrid cloud are different -- they're migratory.
Migratory applications can run anywhere, including dedicated servers, virtual machines, containers, private clouds and public clouds. Enterprises can quickly move migratory apps among these hosting environments to respond to performance and availability issues, or to manage costs.
What makes a migratory application?
Three properties distinguish migratory applications from hybrid applications. Firstly, because they are designed for virtual deployment and management, migratory apps are resource-independent. Secondly, because moving data in and out of public cloud can compromise efficiency, migratory apps organize into component clusters based on workflow. Finally, migratory apps are compliance- and governance-aware to avoid compromising audit and regulatory requirements.
To be resource-independent, application components cannot directly reference resources. This means an app component shouldn't load another component, make a location-specific reference to a database, or use any of its host systems' management API. These direct references make it difficult to move between the data center and cloud. They also interfere with cloud applications' benefits, such as horizontal scalability and failover.
To make application integration or component workflow connections migration-friendly, reference all elements through directories rather than directly -- which is already a common integration practice. However, if the hosting locations don't have a common DNS server, DNS-based coupling can be problematic. Therefore, other directories, such as LDAP and UDDI, may be better options. While these techniques are suitable for mapping component workflows, they aren't for management.
There are two ways, however, to achieve management-level independence. First, create a management component that integrates with a group of application components. When the component group moves in or out of the cloud, the management component will change to reflect the selected execution environment. The second method is to use out-of-application management tools that independently manage both applications and resources.
Creating workflow-based component packages
The second requirement for migratory applications deals with performance at the cloud boundary. Data center networks typically provide high-speed connections between applications and components. However, because cloud computing is supported through the WAN, there may be lower performance at the boundary. Workflows that continually cross this boundary suffer lower response times, which is a big and often unacceptable price to pay.
A migratory application creates workflow-based component packages that exchange information among themselves. The idea is to analyze how work flows among app components, and then group components to minimize workflow performance requirements between groups. To manage cloud border-crossing issues, packages are migrated instead of individual components.
Compliance complicates migratory apps
The final migratory application requirement is likely the most complicated -- compliance and governance. The challenge is that migratory applications are location-independent, so security and compliance practices have to adapt as applications move.
To do this, the first step is to maximize environment auto-detection. In most cases, moving an application changes the affected components' address. And it's usually possible to relate that address to the type of resource running it, such as servers, VMs, containers or public cloud. As a result, compliance and governance policies can accommodate different hosting environments.
The second step is using what you learn about those environments. There are three approaches: using external tools; making applications compliance- and governance-aware; or using management information to detect movement, which works best when combined with one of the first two approaches.
Compliance normally requires a combination of security and governance. It's possible to centralize security management for migratory applications, as well as use central key management and distribution to accommodate component movement in and out of the cloud. Unless all database access is abstracted into a set of APIs that are used instead of direct DBMS access, data security is more complicated. The abstracted APIs represent database components that can be secured and backed up through a central and consistent policy.
Migratory applications are the next generation of cloud. They're the first applications to exploit cloud's capabilities, and not just its cost. They also expose cloud's profound impact on development and operations. If users properly manage the migratory apps transition, cloud's rewards will be much greater.
About the author:
Tom Nolle is president ofCIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
SaaS apps change role of enterprise IT
Do cloud migrations always reduce app TCO?
Which apps are best for Docker containers?