The most effective hybrids take advantage of the favorable properties of all components. The hybrid cloud of the future must take advantage of the new capabilities of public cloud, but also perpetuate the benefits of and investment in private IT. If you don't consider the needs of the data center side of the hybrid,
When you design public cloud applications that are intended to support hybridization, there are four factors you must consider or you risk using components' downfalls instead of their benefits: the application model, the platform, database access and how your components will link together.
Choosing your application model
The foundation of easy hybridization at the technical level is platform harmony.
The first critical consideration when designing a public cloud app for future hybridization is the application model -- either a front-end or backup model. Businesses report that about two-thirds of their current public cloud applications are "front-end," in which cloud technology is added between the user and current app systems. This is the model most commonly used in Internet retail applications. Most of the remainder of companies look to cloud bursting or failover applications that back up existing systems.
If you are developing a public cloud component for hybridization, be sure to accommodate the architecture of the current, on-premises side of the hybrid or adjust your existing architecture to accommodate the cloud side. This is something you'll want to find out in the planning phase, so consider carefully both the initial requirements for the application and your future needs. What's essential in optimizing hybridization is control over the workflow between the public and private components. You need to support current IT practices, but you also need to exploit the unique elasticity and extemporaneous nature of the cloud.
Creating a harmonious relationship with the platform
The foundation of easy hybridization at the technical level is platform harmony. A hybrid cloud can theoretically support a workflow through any set of interfaces that both public cloud and on-premises or private IT support. In practice, having different OSes and middleware in the public cloud can complicate things and be expensive -- particularly in the operations support of the public cloud side.
If you have a unified on-premises IT architecture, give strong consideration to that same architecture in the cloud. If you're planning on a hybrid application for cloud bursting or failover, it's almost mandatory to use the same OS and middleware in both the data center and the cloud. Even when building a Web-like front end to a current IT platform, adjust architecture so some critical components might run in the public cloud for performance enhancement or as backup.
Allowing database access to public cloud and on-premises IT
The third issue to consider in designing public cloud applications for hybridization is how you will provide both public cloud and on-premises IT resources with the data needed. There are cost and security issues related to storing critical company data in the cloud, so most users elect to keep their databases on-premises. So, when the cloud component of a hybrid application must access data, the access has to cross the WAN connection between the cloud and data center, which is both costly and performance-intensive.
For cloud bursting or failover applications, the preferred solution is to use a query-service database management system rather than to have cloud components accessing databases using standard disk I/O. For front-end applications, it may be valuable to create a logical "split" in current databases. For example, a retail cloud front end might use a product catalog derived from the standard retail inventory application but not including on-hand information; the user browses a static catalog but is connected to the real database only when an order is placed.
Determining your application's 'link'
The final consideration is the most technical: How will your hybrid application link at the application program interface (API) level, and how does your app manage context, or state? In software development, components are linked using APIs, and these APIs also typically define how the components keep track of activity progress they're intended to support.
The challenge for developing public cloud apps for hybridization is that most enterprise software is based on the rigorous API definitions of service-oriented architecture (SOA) and the simple object access protocol (SOAP). Cloud applications most often use the REST and HTTP architectures. The difference is that SOA and SOAP link components through multiple phases of a transaction, and all components synchronize their behavior through their APIs. When REST or HTTP is used, the client -- in most cases, the browser interface -- keeps track of the context, and that context is explicitly delivered to each component through the API.
The practical difference is that any copy of a software component that has access to the proper database can process any REST request, but a SOA-SOAP request has to be processed by the specific software elements picked at the start. The REST architecture supports easy load-sharing and load-balancing, but that's harder with SOA-SOAP. This means that any hybrid application that involves cloud bursting or failover should strongly consider a REST architecture. Front-end applications can use an application component, running in the cloud or on-premises, to bridge between a REST or Web-friendly structure in the cloud and the more traditional application architectures of the data center.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in January 2014