Over a million developers have joined DZone.

Cloud Brokers Make the Cloud Fit for Enterprise Requirements

· Cloud Zone

Build fast, scale big with MongoDB Atlas, a hosted service for the leading NoSQL database on AWS. Try it now! Brought to you in partnership with MongoDB.

Sometimes it’s fun to look back at your predictions to remember what you were thinking at the time and see how accurate you turned out to be. Based on some recent conversations, I decided to revisit one of our early blog posts from 2009, where we were envisioning the direction this industry would take and the role our technology would play in it. 

That post, Dynamic Cloud Fitting — the Future in Automated Cloud Management, described a world where workloads would move automatically to the right environment to meet a customer’s business and technical requirements. It also explored how an entity called a “cloud broker” (initially defined by Gartner in 2009) would provide the technology and expertise to achieve that goal.

Fast forward to 2011. The idea of workloads being redirecting on the fly across different clouds for real-time optimized cost/performance is still a vision for the distant future – both because the technology is not yet available and also because customers have shown little interest to date. However the main concept of a cloud broker “fitting” a workload to a cloud environment based on technical and business requirements turns out to be very important to customers, and is already possible today. By providing an intermediation layer spanning multiple clouds, cloud broker software from companies like CloudSwitch can provide a range of capabilities beyond the scope of an individual cloud provider or service. 

In terms of cloud “fitting,” what customers want is the ability to set parameters on a number of dimensions in order to control usage and optimize workload performance. These parameters include (but are certainly not limited to):

  • Which cloud services they want to make available (and for which users)
  • Which geographic locations (regions, zones, data centers)
  • Cost limitations – per hour, based on quotas, etc.
  • Maximum latency that can be tolerated
  • Virtual machine requirements for CPU, memory, etc.
  • Maximum provisioning time that is acceptable
  • Minimum SLA required for reasonable availability

What’s clear is that cloud broker software must incorporate an algorithmic approach to mapping the requirements of the enterprise, user groups, individual users, and specific workloads against the possible cloud services that have been enabled. This is a non-trivial process and is based on capturing and tracking a mix of inputs from administrators and users, as well as real-time data from the virtual machines, networks, and cloud providers. Think of this as being somewhat similar to recommendation engines on websites like kayak.com that help “fit” travelers’ requirements and preferences against available flights. Only in this case, the “flights” are instances that can be provided by one or more cloud provider or by internal virtualized resources. 

Another important aspect for the cloud broker software is to implement the “fitting” algorithm in the context of a role-based access control (RBAC) system. Think of this in terms of layers of enterprise controls and permissions that guide users’ options for self-service access to cloud resources. For example, a global administrator may set up the initial constraints based on which cloud services are available for the entire enterprise, while a business unit administrator may have more narrow limits for her users based on quotas, geographic constraints for certain teams, etc. – and the final end-user just wants to get his work done quickly and cost-effectively without worrying about any of this.

One point we didn’t foresee in our original blog post on cloud fitting was how the cloud broker’s role would expand. In addition to on-boarding applications into the cloud, customers now look to cloud brokers to fill important gaps in areas that cloud providers either don’t want to deliver (such as multi-cloud capability) or that are hard to deliver because of architectural limitations. 

Security is a good example of the latter, where the shared environment of the cloud makes it hard to give individual customers control over encryption and key management, something that enterprises frequently require to get CSO sign-off. Extension of network configurations into the cloud with full configurability is also challenging for most cloud providers, since their network architectures are by definition fairly “flattened” and limited in options like multiple sub-nets (unless the customer is willing to pay for a dedicated network setup). This is another area where cloud brokers can help bridge the gap between what enterprise users need and what multiple cloud providers can deliver.

So the role of a cloud broker turns out to be evolving and growing broader over time, and no doubt will continue to do so. There’s a broad consensus that the broker’s role is important — not just here at CloudSwitch, but also among industry analysts like Gartner, other technology vendors, and our enterprise customers. The key insight is that cloud brokers allow enterprises to extend their control over their applications and data into the cloud. This ability to put control in the hands of the customer is what matters the most.

Now it's easier than ever to get started with MongoDB, the database that allows startups and enterprises alike to rapidly build planet-scale apps. Introducing MongoDB Atlas, the official hosted service for the database on AWS. Try it now! Brought to you in partnership with MongoDB.


Published at DZone with permission of Ellen Rubin . See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}