Following my last post regarding hybrid cloud IT architectures, Steve Riley, the inspiration for this series of articles, commented about several potential models of hybrid deployment that can achieve the “local” feeling in different ways. Specifically, Steve mentioned:
In some cases, a ‘follow-the-sun’ approach may work best. In others, always-on global availability may be required… A third option might be keeping as many resources as possible in one particular cloud region and ‘projecting’ applications to wherever the users may be.
I took these ideas, and thought about how they represent an approach that is, as Steve put it when we spoke, “hybrid, not divided” meaning that the cloud and the enterprise premises portions of a solution work together, rather than an enterprise picking some application and wholesale moving it to the cloud. I found a few examples that I’ve already encountered in my day job that I realized demonstrate the models Steve spoke of in his comment. Each use case leverages elements of cloud models to enhance traditional enterprise capabilities.
Starting with an example of “always-on global availability,” one client I work with has moved to Office365 for email. Cloud-based email is not the interesting part for this discussion, however. As anyone who has worked with the O365 solution has found, there is an important authentication layer called Active Directory Federation Services which must be integrated between the O365 SaaS infrastructure and the enterprise infrastructure for user account maintenance and authentication. My client determined that they didn’t want their primary business site to be the single-point-of-failure in their cloud-based email system. Their solution was to turn up an ADFS server infrastructure in a popular public cloud environment and integrate that with local servers at their site. As a result of their hybrid architecture, they can make changes to their on-premise servers and allow the necessary replication to happen between their on-prem ADFS servers and the ADFS server in the cloud, but the Office 365 service looks primarily to the always-available cloud instance for the critical federated authentication layer for the email system. This is a perfect example of leveraging a piece of hybrid cloud architecture in a sensible way.
Another example came up when recently talking with an acquaintance that works for a multinational retailer that has the vast bulk of their operations located on the east coast of the United States. They found that remote offices in China had many challenges to good application performance, and latency halfway around the globe was a big one. They polled some of their contacts about solutions, and one answer was to house local copies of data in a nearby country (but not within China due to security concerns) to reduce latency. Interesting approach, but it requires locating, negotiating, and operating colo space very far from the rest of the ranch which can present its own challenges. This seems like a situation ripe for Steve’s approach of “projecting” applications to far-flung locations while master copies of data reside in one region. A cloud environment should be able to make this sort of thing much easier to accomplish by selecting geographic regions to run instances of enterprise apps in for optimal access from global resources.
The last example that came to mind was a company I’ve worked with in the past that was deploying an application performance monitoring solution. They wanted to monitor performance of the applications they host for their customers from multiple vantage points. To accomplish this, they deployed monitoring infrastructure within their data center, but also ran agents in several geographic availability zones of multiple public cloud providers to give them a view of their own customer-facing app performance from various locations around the US. This provided another good example of using a hybrid approach, with on-premises infrastructure performing part of the role, and cloud-based resources contributing where their strength is.
Each of the above examples demonstrate ways hybrid cloud architecture can be approached that differ from the “classic” (and perhaps unrealistic) example of cloud-based web/application servers accessing a database at the corporate data center. As described in this post, hybrid cloud architectures can leverage various features of cloud and enterprise premise environments for optimal solutions, large and small. Let’s keep thinking of ways we can integrate cloud solutions into corporate IT, rather than simply trying to replace corporate IT.
About The Author
Bob McCouch, CCIE #38296, is a networking consultant in Pennsylvania, USA, with over 10 years of industry experience. His blog can be found at http://HerdingPackets.net and followed on Twitter as @BobMcCouch.
This post is part of the Riverbed Hybrid Enterprise Sponsored Conversation series. For more information on this topic, please see the rest of the series HERE. To learn more about Riverbed’s Hybrid Enterprise Architecture, please visit http://Riverbed.com.
“Integrate rather than replace”… I like that summary, Bob.
In your research, did you encounter anyone attempting what you define as the “classic” hybrid example? I suspect your parenthetical (“unrealistic”) remark means either that you didn’t, or that any such implementations hadn’t progressed beyond laboratory experiments. In any event, it’s unlikely to be a useful approach because of the latency involved. Placing a WAN between the cloud-based application server and the on-premise database would seriously degrade performance.
Yep, that’s pretty much it. I think the reality is, as you mention, that trying to separate application tiers that have traditionally been architected assuming colocation of the servers (in terms of latency and bandwidth expectations) will present a challenge most of the time.
I think the models I describe above, and others where the hybrid deployment model would work well, involve batch transactions, applications that can tolerate periodic replication of data, and other applications where multiple tiers are not so tightly bound together. The application data flow and it’s expectations of inter-tier behavior play a major role in suitability for a cloud (particularly a hybrid cloud) deployment.