Tag Archives: hybrid clouds

Why Cloud Brokers Are The Foundation For The Resilient API Network

Amazon Web Services crashed spectacularly, and with it the illusion that cloud is reliable-by-design and ready for mission-critical applications. Now everyone knows that cloud SLAs fade like the phosphor glow in a monitor when someone pulls the plug from the wall. Amazon’s failure is an unfortunate event, and the cloud will never be the same.

So what is the enterprise to do if it can’t trust its provider? The answer is to take a page from good web architecture and double up. Nobody would deploy an important web site without at least two identical web servers and a load balancer to spray traffic between them. If one server dies, its partner handles the full load until operators can restore the failed system. Sometimes the simplest patterns are the most effective.

Now take a step back and expand this model to the macro-level. Instead of pair of web servers, imagine two different cloud providers, ideally residing on separate power grids and different Internet backbones. Rather than a web server, imagine a replicated enterprise application hosting important APIs. Now replace the load balancer with a Cloud Broker—essentially an intelligent API switch that can distribute traffic between the providers based  both on provider performance and a deep understanding of the nature of each API.

It is this API-centricity that makes a Cloud Broker more than just a new deployment pattern for a conventional load balancer. Engineers design load balancers to direct traffic to Web sites, and their designs excel at this task. But while load balancers do provide rudimentary access to API parameters in a message stream, the rules languages used to articulate distribution policy are just not designed to make effective decisions about application protocols. In a pinch, you might be able to implement simple HTTP fail over between clouds, but this isn’t a very satisfactory solution.

In contrast, we design cloud brokers from the beginning to interpret application layer protocols and to use this insight to optimize API traffic management between clouds. A well-designed cloud broker abstracts existing APIs that may differ between hosts, offering a common view to clients decoupled from local dependencies. Furthermore, Cloud Brokers implement sophisticated orchestration capabilities so they can interact with cloud infrastructure through a provider’s APIs. This allows the broker to take command of applications the provider hosts. Leveraging these APIs, the broker can automatically spin up a new application instance on demand, or release under-utilized capacity. Automation of processes is one of the more important value propositions of cloud, and Cloud Brokers are means to realize this goal.

For more information about Cloud Brokers, have a look at the Cloud Broker product page at Layer 7 Technologies.

Advertisements

How to Secure vCloud Director and the vCloud API

This year’s VMworld conference saw the announcement of VMware’s new vCloud Director product, a culmination of the vision for the cloud computing the company articulated last year and a significant step forward in providing a true enterprise-grade cloud. This is virtualization 2.0—a major rethink about how IT should deliver infrastructure services. VMware believes that the secure hybrid cloud is the future of enterprise IT, and given their success of late it is hard to argue against them.

vCloud Director (vCD) is interesting because it avoids the classic virtualization metaphors rooted in the physical world—hosts, SANs, and networks—and instead promotes a resource-centric view contained with the virtual datacenter (VDC). vCD pools resources into logical groupings that carry an associated cost. This ability to monetize is important not just in public clouds, but for private clouds that implement a charge back to enterprise business units.

Multi-tenancy is a basic assumption in the vCD universe, and the product leverages the new vShield suite to enforce isolation. Management of vCD is through the vCloud API, a technology VMware introduced a year ago, but which has now matured to version 1.0.

The product vision and implementation are impressive; however, a number of security professionals I spoke with expressed disappointment in the rudimentary security and management model for the vCloud API. vCloud is a RESTful API. It makes use of SSL, basic credentials and cookie-based session tokens as a basic security model. While this is adequate for some applications, many organizations demand a more sophisticated approach to governance, buttressed with customized audit for compliance purposes. This is where Layer 7 can help.

Layer 7’s CloudSpan virtual gateways are the ideal solution for protecting and managing the vCloud API, vSphere, and vCloud Director. CloudSpan provides an intuitive, drag-and-drop interface for securing vCloud services and providing the visibility the modern enterprise demands. Do you need to protect the interface with 2-factor authentication? A few simple key clicks and you add this capability instantly—to a single API, or across a group of similar services. The CloudSpan policy language gives administrators the power to customize the access control and management of vCloud to incorporate:

  • Authentication against virtually any security token (SAML, Kerberos, X.509 certificates, OAuth, etc).
  • Cloud single sign-on (SSO).
  • Fine grained authorization to individual APIs.
  • Fully customizable audit.
  • Virtualization and masking of APIs.
  • Versioning of REST and SOAP APIs beyond vCloud basic versioning.
  • Augmentation and extension of existing vCloud functions.
  • Transformation of any GET, POST, DELETE, and PUT content.
  • Orchestration to create new APIs
  • Validation of XML structures such as OVF containers.
  • Threat detection, including threats embedded in XML OVF files.
  • Automatic fail-over between hosts.
  • Mapping between SOAP and REST
  • JSON Schema validation
  • Management of federated relationships.
  • Live dashboard monitoring of API usage.
  • etc

Figure 1: vCloud Director API management and security with CloudSpan from Layer 7.

CloudSpan is the basis of real cloud governance. In contrast to other solutions that run as third party services or attempt to broker security from you own local data center, CloudSpan runs as an integral part of the vCloud Director environment. CloudSpan runs as a VMware virtual image that is easily incorporated into any VMware virtual infrastructure. At Layer 7,we fundamentally believe that the security, monitoring and visibility solution for cloud APIs must reside inside the cloud they are protecting—not off at some other location where the transactions they proxy are subject to attach as they traverse the open Internet. Local integration of the security solution as an integral part of the cloud infrastructure is the only way to properly secure cloud APIs with sophisticated access control and to offer protection against denial-of-service (DoS) attacks.

For more information about how to secure and manage the vCloud API and vCloud Director, please see the cloud solutions page at Layer 7 Technologies.

Public vs. Private Clouds

Christian Perry has an article in Processor Magazine that I contributed some quotes to. The article is about the ongoing debate about the merits of public and private clouds in the enterprise.

One of the assertions that VMWare made at last week’s VMWorld conference is that secure hybrid clouds are the future for enterprise IT. This is a sentiment I agree with. But I also see the private part of the hybrid cloud as an excellent stepping stone to public clouds. Most future enterprise cloud apps will reside in the hybrid cloud; however, there will always be some applications, such as bursty web apps, that can benefit tremendously from the basic economics of public clouds.

Clouds May Be Big, But You Should Start Small

James Urquardt, from Cisco, published a review of the US Government’s recently announced cloud initiative. I had the pleasure of sharing a panel with James recently at GigaOm Structure, and his CNET column should be on your must-read list if clouds are of interest to you.

In this article, James makes an interesting point that the government is really following the “Adopt at your own pace mentality” with respect to cloud. Obviously this isn’t about moving IT completely into the cloud–let’s face it, governments, of all organizations, hold data that will always be inappropriate for public cloud deployment. But it does demonstrate that a perfectly reasonable strategy is to create the opportunity to move select applications into the cloud (such as blogs, as the article mentions), and provide a mechanism so that these can coexist with existing internal IT. This is the so-called hybrid approach (particularly if there is a private cloud as part of the “internal” deployment).

But hybrid clouds face a big problem. To be useful, there must be secure communications between internal applications and new services deployed in the public (or semi-public) cloud. Amazon recently announced it’s Virtual Private Cloud initiative  to address this issue. I was encouraged by their efforts; clearly, Amazon is taking the hybrid model very seriously–no doubt they’ve had a lot of customers asking them to solve this problem. However, I do question the strategy of deploying a VPN tunnel between internal IT and a public cloud. Despite efforts to secure and make private the operating environment of the public cloud, the VPN solution remains a risky proposition.

The trouble with VPNs is that they are indiscriminate over traffic. The trust model of VPNs is based on both ends being equal secure. A VPN makes sense when you integrate a branch office into your central corporate network, as the later is subject to the same corporate security standards and policy. It can be dangerous if the remote site is one where you have any less control over the entire security model, as is the case in the cloud. Imbalance in security implementation is an opportunity for attack. If a single application on the cloud side is compromised, a system cracker can then leverage the VPN tunnel to get full access into the internal network. (This same problem exists with conventional VPNs and laptops, and believe me, it keeps security guys up at night.)

A better solution is to constrain communications on a service-by-service basis, managed under policy control. That way, if a system is compromised, it provides limited opportunity to launch a further attack. Here you are creating zones of trust between services, which is much more finely grained and deliberately constrained. The Layer 7 version of the secure hybrid model looks like this:

cloud VPN

Here, virtual and physical SecureSpan appliances coordinate communications between internal applications and services residing in the cloud. All transactions are managed under policy control. They are rigorously monitored, scrubbed for threats, and constrained to the appropriate parties. Architectures like this allow organizations of any size to move at their own pace into the cloud. It’s a model we’ve been advocating for some time. SecureSpan is already the security foundation of what is arguably the largest private cloud in the world, which is an existing government initiative that predates this latest announcement.

NIST Perspective on Cloud Computing

Earlier this month, NIST went public with their perspective on cloud computing. This is important because NIST is a well-respected, public standards organization, and there is still a lot of confusion about what cloud really is (the *-aaS affect).

They released only  a short, two page document and a longer, 72 slide PowerPoint (you can find their main page here). They are offering a broad definition based on essential characteristics, delivery models, and deployment models:

Essential Characteristics:

On-demand self-service

Ubiquitous network access

Location independent resource pooling

Rapid elasticity

Measured Service

Delivery Models:

Cloud Software as a Service (SaaS)

Cloud Platform as a Service (PaaS)

Cloud Infrastructure as a Service (IaaS)

Deployment Models:

Private cloud

Community cloud

Public cloud

Hybrid cloud

There’s not really anything new here, but that’s fine; it’s more important as a validation of the emerging models and ideas from a public standards body. I do like the three pronged approach, acknowleding that cloud is a lot of things but at the same time keeping it simple and concise. Brevity is the soul of great standards.

It’s worth keeping an eye on this effort.