> Archive > Issue LXVI, September 2012 > Hybrid Cloud Solutions
Dan Rosanova

Dan Rosanova


Dan Rosanova is a three-time Microsoft BizTalk Most Valuable Professional (MVP) with over fourteen years of experience delivering solutions on Microsoft and Solaris platforms in the financial services, insurance, banking, telecommunications, and logistics industries, where he has specialized in high volume and low latency distributed applications. Dan has extensive experience with WCF, .NET, XML, web services, and queuing technologies. His recent focus has been on evolutionary computation, Advanced Message Queue Protocol and GPU computing. Dan is the author of Microsoft BizTalk Server 2010 Patterns Packt Publishing, UK.

Dan is a senior architect in the Technology Integration practice at West Monroe Partners, an international, full-service business and technology consulting firm focused on guiding organizations through projects that fundamentally transform their business.


rss  subscribe to this author


Hybrid Cloud Solutions: Combining On-Premise and Cloud Components to Build Reliable, Secure, and Scalable Applications

Published: September 20th, 2012 • Service Technology Magazine Issue LXVI PDF

Abstract: Cloud-based solutions are increasingly gaining traction, although technical, regulatory and attitudinal reasons are preventing many systems from transitioning to the cloud. Combining existing on-premise solutions with cloud-based components will increase flexibility and reach, while improving reliability and security. This article explores hybrid cloud scenarios that combine cloud with traditional delivery methods; these include cloud-based front-ends, secure service tunneling, elastic computing and cloud-based disaster recovery.


Cloud is a force to be reckoned with-its technology and architecture are steadily maturing and becoming increasingly more stable. The market is healthy and expanding, guided by industry experts with the influence and sophistication to successfully man the changeover. There are, however, several major obstacles preventing full cloud adoption; one is the existing software ecosystem, another is a lack of trust in what is still an unfamiliar technology paradigm.


Technical - Many applications were carefully designed to function in highly specific physical configurations, and are sensitive to locality and latency among or between their components. It is usually difficult to move these applications to the cloud. Applications may also rely on platforms that are currently incompatible with cloud computing, such as mainframe or UNIX systems. These systems are oftentimes the result of considerable investments over decades, and cannot be simply rewritten. These technical and legacy hurdles exist for numerous large enterprises and government agencies; however, they should not prevent transitioning to cloud computing.

Regulatory - In Germany, for instance, data cannot be stored in systems outside of EU boundaries so as to protect the privacy of customers identified by data as well as enforce existing privacy and security regulations. Other regulatory issues include interstate and international commerce impacts.

Attitudinal - Finally, there are issues of trust and comfort with cloud computing. Organizations are usually wary of technology that they do not know or understand. This same reluctance has met every major wave of technological innovation, including the mainframe, the PC and Internet. Cautious attitudes and low comfort levels can hinder an organization's growth since they create both a barrier to entry and a roadblock to testing and experimentation. For those who live on the cutting edge of technology, this obstacle may seem like a minor distraction; however, it is a real and legitimate concern. The solution must be accepted by the organization in order to be truly successful.

Fortunately, the emerging field of hybrid cloud solutions can resolve all three problems, while making the move to the cloud more of an incremental transition rather than a complete system upheaval. This reduces risk while providing a solution that meets the unique needs of your organization.

Cloud Offerings

Before we explore different hybrid cloud scenarios, here are the three major types of cloud offerings currently in wide usage:

Infrastructure as a Service (IaaS) - This is the hardware in the cloud. This generally refers to current generation operating systems and network equipment used on a pay-per-use basis, often through virtualization. There are many vendors in this space-the line between public cloud and private cloud is rapidly blurring, as products and services entering the market make transition between the two increasingly seamless.

Platform as a Service (PaaS) - In some ways more sophisticated than IaaS, these offerings are higher-level services such as queuing, workflow, database and storage. These represent a layer above the operating system or hardware, and are the platform that the software is subsequently built on. This is an area of cloud computing that is largely dominated by Microsoft and Amazon.

Software as a Service (SaaS) - Perhaps the forerunner of the entire modern cloud movement, this type represents an entire software package as a service. The first to become widely successful in this area of cloud computing was Salesforce.

Hybrid Cloud Scenarios

All three cloud offerings can be implemented in a "pure cloud" fashion, although they are increasingly paired with non-cloud components to create solutions that are part cloud, part traditional offering. These types of solutions can serve as a practical gateway to the cloud that bridges the gap between current systems and some undetermined future state. The following are typical examples of hybrid cloud solutions that are being used by an increasing number of organizations.

Cloud Front-end

A widely useful function of cloud computing is the calling by front-end applications adapted to modern technology paradigms into existing lines of business systems. An example is booking airfare online. Although not cloud-based, their front-end web interfaces are modern and almost completely disconnected from their back-end systems. These web front-ends simply call back into legacy applications-often Saber-while using caches to prevent legacy back-end overload, since these legacy systems were generally designed for high-speed batch processing. Most travel websites ultimately connect to legacy systems in a fashion that is both appealing to the user and technologically effective.

To the user, there appears to be only one system and experience-the disconnect is subtle, but it exists. This is why a confirmation number, and not a receipt, is generated when you place an online ticket reservation. The email containing your receipt arrives within seconds or minutes of the transaction. The entire process is technically asynchronous, but it produces a synchronous experience, which is the user expectation. This type of asynchronous processing has been the best of breed design for high volume systems for some time as it allows for horizontal scaling and load leveling. Scalability and durability are the core strengths of this architecture; it easily scales out to accommodate more user requests by adding more web tier nodes.

A typical implementation of the cloud front-end architecture contains the following components:

  • web / front-end
  • distributed cache, i.e. fast buffered data access
  • messaging layer
  • existing back-end systems

All of these components work together as expressed in Figure 1 below.


Figure 1

As the workload on the front-end increases, more capacity can be added to handle the volume; the back-end systems will not be directly affected. Often the back-end system will pull from a queue or topic so the processing remains disconnected and durable. This type of architecture can even be leveraged with batch-oriented systems to combine queued messages into a batch for processing by a legacy application. This is an excellent technique to bridge the gap between the growing real-time environment and existing batch-based systems.

This architecture works well when using IaaS-, PaaS- and SaaS-based front-ends, although IaaS and PaaS are the most common. In the case of IaaS, an existing web application can often be hosted in the cloud-many are already externally hosted. Over time, this IaaS platform can be migrated to PaaS or SaaS to leverage more fluid scaling. One variant of this architecture involves SaaS front-ends being bridged to existing back-end systems via PaaS, as shown below (Figure 2).


Figure 2

The key points of this scenario are:

  • commonly used with IaaS and PaaS offerings
  • often requires asynchronous processing and caching
  • scales extremely well for widely used front-end or user-facing errors

Cloud as Reliable-secure Bridge / Cloud Endpoints Connecting On-premise B2B

Also growing in popularity is the utilization of cloud-based bridges to connect two disparate systems, cloud and on-premise. This is particularly useful in B2B and disconnected messaging scenarios. This is not an entirely new concept-EDI systems have used Value-added Networks (VANs) since the 1980s. These networks allowed both parties to act as clients in a data transfer, and thus removed the burden of being a server, e.g. providing a service with the SLAs and other responsibilities that accompany such a role. Although most VANs went out of use due to high costs, the concept behind its technology has grown and evolved over time.

VANs were a store and forward mechanism that allowed the decoupling of sender and receiver in terms of time. Some cloud vendors now offer relay and messaging technologies that go beyond this paradigm while allowing connectivity between two endpoints that simultaneously play the role of the client. In this type of arrangement, the cloud platform provides a tunnel between two client endpoints that are both essentially clients of this internet-based service. These services can even be used to provide load balancing and distribution across nodes, be they on-premise servers or IaaS. The diagram below (Figure 3) outlines this approach of using the cloud as a bridge between on-premise applications.


Figure 3

The key points of this scenario are:

  • commonly used with PaaS offering
  • requires less online availability / uptime
  • wide variety of authentication options
  • message routing capabilities including content-based routing and load balancing
  • little or no network configuration changes for the "service provider"-usually doesn't require the opening of firewall tunnels

On-premise With Elastic Cloud Scaling

Ideal for seasonally variable workloads or spikes, this scenario involves augmenting processing capability with cloud-based resources. Unlike the web front-end example, this architecture uses the cloud to increase total back-end processing capability. Typical examples include the holiday sales season for online retailers, April 15th for tax services, and any major sporting event for online gaming services. These businesses function at a much lower demand level for much of the year-they are only occasionally required to procure hardware and software to accommodate peak seasonal loads. These resources remain underutilized for the remainder of the year, but require a large upfront capital outlay. Incorporating an elastic cloud computing capability alleviates the need for large upfront expenses in hardware while leveraging existing non-cloud investments and capabilities.

These types of solutions generally leverage IaaS platforms to allow for the rapid provisioning of nodes in a distributed computing environment. Organizations wishing to leverage this architecture need only create a virtual machine image with installation/configuration scripts to scale out to a nearly unlimited level for variable loads.

An extreme example of this architecture is High Performance Computing (HPC) products. These can incorporate both on-premise and cloud-based resources, or "nodes," to increase processing power in grid or scientific computing applications. The ability to auto-enlist additional resources that join an application group automatically without requiring manual configuration enables extremely rapid scaling at a very low cost. These scaled resources replicate most or all of the services and capabilities of the permanent on-premise solution and, in this way, can increase total throughput and processing without creating new bottlenecks. Additional resources are provisioned in proportion to their role on a cloud platform.

In the diagram below, web servers and back-end processing servers are added into the application resource pool on demand to provide further processing capabilities (Figure 4).


Figure 4

These resources can be quickly and easily scaled up or down-it is even possible to automate this scaling with predetermined thresholds and cutback periods. An increasing number of tools are being created to enable easier implementation. This architecture is compatible with current systems, making it perhaps the most immediately useful of the various cloud computing techniques. The cost savings are compelling and the unlimited scalability is noteworthy.

This approach does require upfront planning as well as impacts the architecture and implementation of the constituent components used across a system. Most often this will be the use of messaging and queues, and the removal of single points of failure or overload. However, these are generally required for any highly scalable implementation with or without leveraging the cloud. The primary criteria is that the system must be built to scale out (i.e. increasing number of servers) and not up (i.e. increasing size of servers)-there is a limit as to how powerful any single server can be.

The key points of this scenario are:

  • IaaS solution works with existing applications
  • can leverage PaaS for backup storage
  • requires horizontally scalable architecture
  • benefits from upfront investment in auto-scaling and prepared images
  • extremely flexible solution for variable loads

Cloud for Disaster Recovery

A growing area of interest is the Disaster Recovery (DR) capability that cloud platforms can provide to traditional systems. This allows an organization to create a backup environment that is either warm (idle) or cold (offline) that runs completely in the cloud. Recent advances in IaaS have allowed this model to become viable. Unlike the elastic model, this is purely a disaster recovery pattern and not actively processing under normal conditions. All of the services and applications needed to run an enterprise or organization are transitioned to this environment in the case of a catastrophic disaster that renders the primary data center inoperable. Fires, earthquakes and floods are examples of such disasters. Below is a diagram of a typical front-ends disaster solution that leverages IaaS and PaaS (Figure 5).


Figure 5

Cloud disaster recovery can also be leveraged to provide more robust DR than current on-premise solutions. In the example of fire, the effects are likely to be local to a particular data center, but in the case of an earthquake, flood or hurricane, whole regions could be affected. A DR site could be rendered inoperable by the same event that brings down the primary site. The cloud gives us the ability to easily choose the location of our DR as well as modify according to need. Furthermore, the cost savings realized by using the cloud model can be re-invested to provide secondary or even tertiary DR capabilities. These solutions are generally not fully automated, but could be heavily automated, requiring only one person to perform an entire cutover.

When considering this model, the primary issue to keep in mind is distance. This is a common thread with any of these scenarios; cloud-based DR, in particular, generally deals with relatively large data volume over what could be long distances. Distance and its effect on network speeds and latency will impact the type of Recovery Time Objective (RTO) that is achievable, as well as how far behind the data is when a cutover happens. Any DR cutover is likely to involve data loss; minimizing this loss, as well as the time to restore service, is the key metric for this scenario. This is generally referred to as the Recovery Point Objective (RPO). Both RPO and RTO can be lowered by having warm standby infrastructure in the cloud and synchronizing on short intervals.

This approach also heavily leverages the IaaS capabilities of the cloud to provide low-cost disaster recovery that can be implemented quickly while accommodating existing non-cloud solutions. Additionally, if coupled with the elastic computing model, these DR implementations can be expanded in place to carry the full load of the primary data center.

The key points of this scenario are:

  • IaaS centric
  • can provide more robust capabilities than traditional solutions
  • lower costs than non-cloud solutions
  • easy to scale up after disaster cutover
  • RTO and RPO must be well understood


The scenarios presented here represent common hybrid cloud architectures, but they are only a cursory list-many other scenarios exist and are currently in use. New ways to leverage the cloud are emerging all the time, which is part of what makes the entire movement so exciting. The capabilities are constantly evolving and expanding while the costs are continually dropping. Furthermore, the release cadence in the cloud is much shorter than in traditional delivery mechanisms, enabling new features to enter the market more quickly.

Ultimately, the cloud will not replace traditional computing platforms anytime soon; however, it can provide augmentation while driving down costs, increasing capabilities and delivering a rich user experience. If you have not already begun the transition to the cloud even in an exploratory or auxiliary manner, now is the time to do so-a hybrid cloud may be your solution.