Enterprise IT
Blended Cloud Environments – A Financial Services Use Case
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Damon Miller, Director of Technical Field Services
One of the most interesting trends in cloud computing is the emergence of “hybrid” solutions which span environments that were historically isolated from one another. A traditional data center offers finite capacity in support of business applications, but it is ultimately limited by obvious constraints (physical space, power, cooling, etc.). Virtualization has extended the runway a bit, effectively increasing density within the data center, however the physical limits remain. Cloud computing opens the door to huge pools of computing capacity worldwide. This “infinite” capacity is proving tremendously compelling to IT organizations, providing on-demand access to resources to meet short and long-term needs. The emerging challenge is integration—combining these disparate environments to provide a seamless and secure platform for computing services. CloudSwitch provides a software solution that allows users to extend a data center environment into the public cloud securely without modification of workloads or network configurations. I’d like to discuss a specific example of how CloudSwitch delivered a solution which spanned environments in a corporate data center and external cloud.
A large financial services company approached us some time ago with an ambitious plan to leverage cloud computing as a strategic initiative within the organization. Their goals were to reduce operating costs, improve responsiveness to the various business units, and differentiate themselves within the industry through technological innovation. Security was a fundamental requirement and a number of risk assessment groups were involved throughout the design and evaluation phases of the engagement. Finally, this company also wanted to leverage a traditional colo environment from their cloud vendor to provide high-speed access to shared storage while also supporting their traffic monitoring equipment. After a period of technical diligence, we established a reference architecture which satisfied all internal security requirements while remaining true to the fundamental goal of moving to a dynamic cloud environment. The result was a true realization of the hybrid model.
In the customer’s reference architecture, there are three primary components:
- Internal data center environment hosting the CloudSwitch Appliance (CSA)
- Private colo environment hosting the CloudSwitch Instance (CSI) and CloudSwitch Datapath (CSD) as well as shared storage for cloud instances
- Public cloud environment hosting customer workloads
The CloudSwitch Appliance is deployed into the customer’s data center environment to allow central management of one or more colo environments. Each of these environments supports an isolated cloud deployment, for example for a particular business unit. CloudSwitch’s virtual switch and bridge components are implemented for high-speed connectivity between cloud servers and shared storage. Finally, the public cloud environment is used to host actual customer workloads (operating systems). Network communication and local storage are protected through CloudSwitch’s secure overlay network and transparent disk encryption functionality.
This approach yields several benefits:
- Multiple instances of this dedicated environment can be independently deployed to support different business units
- High-speed access to the enterprise cloud environment is available since the colo environment is physically located in the same facility
- Physical infrastructure can be deployed into the colo environment in support of cloud servers—for example, shared storage devices
- Dedicated firewalls can be deployed and traffic inspection is possible, satisfying the security groups’ requirements
The reference architecture supports the organization’s high-level goals while remaining compliant with all existing security and regulatory requirements. Cloud servers have high-speed access to shared storage as a result of the colo deployment alongside the public cloud environment. All network traffic and storage is encrypted automatically through CloudSwitch’s security capabilities, and through CloudSwitch’s role-based access controls (RBAC) the security team has centralized control over who is able to access each cloud environment. The end result is a deployment model which truly implements a hybrid environment combining resources from the public cloud with traditional colo resources to deliver a secure, scalable platform for dynamic computing.
The Trouble with Legacy Apps
By Ellen Rubin
Last week, I was on a panel at the CompTIA Breakaway conference in DC, with Scott Crenshaw from RedHat and Ron Culler from Secure Designs. Scott made an interesting comment about the three types of applications out there: (1) new apps that are being architected from scratch for the cloud; (2) legacy apps that are being re-architected for the cloud; and (3) everything else. It was a useful framework for our discussion about cloud migration and security, but it also made me think a bit about the issue of legacy apps and why these remain so controversial for the cloud industry.
If I had a dime for every panel discussion that led to a heated debate around whether or not to re-architect for the cloud… I think the heat around this issue reflects some underlying confusion about how to handle all those “annoying” legacy apps. It’s an area of particular interest to us here at CloudSwitch, so I’d like to share our thoughts and hopefully generate some additional productive discussion in the industry.
Let’s start with (1) new apps. High-profile customer stories from companies like Netflix are creating momentum around the idea of building enterprise apps – even mission-critical ones – to run specifically in the cloud. Of course, start-ups and SMB’s have been doing this for years, since they quickly realized that the cloud provides a low-capital way to get their businesses started and frees them from long-term expensive contracts with hosters and colos. But the idea of building greenfield enterprise apps that take advantage of the cloud’s agility & scalability is only slowly gaining traction.
This is due to several concerns of enterprise stakeholders. While individual developers love the idea of coding directly for the cool new platform of the cloud (without fighting corporate IT for access to servers), corporate IT often feels threatened by a new process/platform that may make them less relevant or able to set policies and standards. Corporate IT also recognizes that as the cloud apps go into production, all the serious issues around reliability, performance and integration will fall on them and may be extremely complex and difficult to manage. Security and networking teams have the expected concerns about changes to existing policies and access, and overall loss of control. And all groups share a fear of cloud lock-in since you’ve essentially built your app to run in a specific cloud.
Next there’s (2) teaching old legacy apps new tricks by re-architecting them for the cloud. This is appealing because it allows enterprises to move off outdated (and often costly) OS’s and hardware. It also allows the app to get true benefit from the scalability, geographic distribution and rapid provisioning of the cloud—and to run better in an environment where server performance and availability can be highly variable. Traditional legacy apps are often limited to scaling up vs out, and have requirements for network and storage configurations that may not exist in the cloud.
So why not re-architect? Most of the legacy apps we see at enterprise customers are either non-mission-critical (tier II, III) or less frequently used, with occasional bursts during peak periods. It’s not always economical to re-architect these or to spend precious developer resources on building/testing/supporting the new apps. Plus, the apps themselves may have some inherent limitations due to the age of their architectures (think SAP, SAS, Oracle Apps, etc. – apps that were designed long before the cloud gained attention, and that may not behave well if re-architected or may pose licensing challenges).
And finally, there’s (3) the “everything else” category – legacy apps that include all sorts of custom apps designed for specific purposes and business uses that may or may not still be important to the enterprise. You’d be amazed at how many of these there are. A typical F1000 enterprise can have hundred or even thousands of apps, and very few are mission-critical or worth the effort to re-architect. But there they are, sitting in your data center, still important for some particular group or maybe for compliance reasons, so you don’t want to get rid of them, either. The cloud is a great place to relocate these apps, and provides options for closer geographic proximity to the actual users, as well as the cost benefits of shutting down apps when not in use.
I find that among the “clouderati” there’s often a lack of interest in this last category of apps, mainly because they’re not very sexy or high profile. Enterprises, on the other hand, are pretty interested in them since they represent a large plurality (if not majority) of the apps that need to be considered in a broader cloud strategy. Also, since by definition these are not the critical apps that the enterprise depends on, they’re the easiest to try first in the cloud to show a low-risk success story to potential cloud users.
Large cloud providers and cloud enablement vendors are starting to take greater notice of legacy apps (both the kinds that should be re-architected as well as those that should be left alone). Amazon’s VPC strategy and VM migration tool reflect a growing recognition of legacy app requirements, as does VMware’s vCloud Director strategy, and Citrix’s CloudStack/CloudBridge. The industry as a whole has begun to focus on making it easier to migrate legacy apps and keeping them integrated with the enterprise environment they rely on.
This is good news for enterprise customers, and no surprise to us at CloudSwitch, where legacy apps have always been part of the vision. We believe that unless legacy apps can be safely and seamlessly run in any cloud environment with full enterprise control, enterprises will hold off adopting cloud in a major way. For every Netflix out there, there are hundreds of enterprises that will not build apps specifically for the cloud, or will only do this for a tiny percent of their application portfolios. And regardless of which category of app we’re discussing, you still need these apps to tie into enterprise management/monitoring systems, data, networking and security. Legacy apps are the proving ground for the cloud’s enterprise-readiness and maturity, and the industry should embrace this challenge head-on.
SharePoint in the Cloud
By Pavan Pant, Director of Product Management
As customers continue their march to the cloud we have heard from a large number who want to use SharePoint Server in the cloud. Two major concerns that show up frequently are migration of existing custom deployments and data security.
These organizations have spent years customizing their SharePoint deployments so they work just right in their environment, and moving to the cloud is a daunting proposition. Consider a scenario where a customer has deployed SharePoint and each department has its own intranet and individual sites for employees – the proliferation of these sites across organizations and the customization required has created a situation where customers typically stay away from using the cloud for their existing SharePoint deployments and start from scratch in the cloud.
We’ve also heard from customers who already have SharePoint deployed in their data centers with sensitive content (e.g., PII information) and would love to take advantage of the elasticity the cloud has to offer but have security concerns about using the cloud. In a shared multi-tenant environment customer data needs to be protected from unauthorized access at all times, and must be off limits to cloud providers. This essentially means that customers need full disk and network encryption to protect their data while it is at rest and in motion.
CloudSwitch allows you to take your existing SharePoint deployments and run them the cloud without requiring any changes to your application or networking. In addition, all your data remains secure – we provide full network and disk encryption (including encryption of the boot partition) in the cloud to ensure that your content remains secure while in transit to the cloud and in the cloud itself. Most importantly, the disk encryption keys remain in your control as opposed to being stored and managed with the cloud provider.
One of our customers is a large health insurance company that has sensitive patient data and other information in their SharePoint content management system. Their primary goal was to offload their ongoing management of the SharePoint servers in their data center and use Amazon’s public cloud. This would allow them not only to lower their costs but also to take advantage of the elasticity offered by the public cloud. The configuration in their data center is a two-tier SharePoint deployment – one server runs SQL while the other runs both the SharePoint Content Server and the Front-End IIS server.
With CloudSwitch’s software in place in their internal VMware environment, this customer was able to migrate their existing SharePoint deployment to the cloud securely, simply and without any changes whatsoever (IP address, MAC address, network configurations, etc.). Their end users can access and use the SharePoint sites for content management exactly as they did in the data center. SharePoint administrators are able to add servers to the farm, cluster the SQL server and burst in the cloud as needed just as they would in the data center but with all their security needs being met. Also, with the “infinite” scalability of the cloud, they no longer need to worry about the time it takes to buy and install new storage. They can allocate new resources to their cloud SharePoint deployment in minutes.
In addition to all this, the customer can also continue using their Active Directory installation in the data center to control authentication and authorization to the SharePoint portal – again, all of this without installing any agents or software on servers in the customer’s data center or any agents for the customer’s servers in the cloud.
Leveraging the Cloud
I recently attended a cloud computing panel where one of the panelists was lamenting how SharePoint was never architected with the cloud in mind because cloud providers like Amazon impose networking and storage constraints (e.g., dynamic IP address and ephemeral storage) that SharePoint does not handle well. Some of the main reasons to deploy SharePoint in a multi-tenant environment are to consolidate resources and take advantage of the scale the cloud offers – by having multiple users in a single deployment that can take advantage of storage as you grow. Many enterprises have been shying away from using SharePoint in the cloud because of concerns around security, storage management and networking implications. That applies only if you think about the cloud as an opaque system where only the cloud provider can control networking, security and configuration. With CloudSwitch, all of the control is shifted back to the enterprise and the users can run their existing processes and applications. We do all the heavy lifting for you so you can move your SharePoint deployments to the cloud and get started today!
Cloud Brokers Make the Cloud Fit for Enterprise Requirements
By Ellen Rubin
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.
Planning for Outages in the Cloud
By Dave Armlin, Director of Customer Support at CloudSwitch
The Amazon US East outage of just over a week ago was an eye-opener for many people. Here at CloudSwitch it validated what we know about best practices for using the cloud. Not surprisingly, these reflect traditional IT processes and systems that enterprises know are needed to protect data and ensure that applications remain available to users.
From an enterprise support perspective, I’m very happy about the variety of options we have to protect and backup data, scale and shrink application capacity, and bring applications on and off-line. It’s also easier than ever to make sure that you don’t have all of your “eggs in one basket” due to public clouds and products like CloudSwitch.
CloudSwitch was designed to bridge the worlds of the data center and public cloud, making it extremely easy and safe to move virtual machines into the cloud over an encrypted tunnel onto encrypted storage. You can also deploy multiple copies of your virtual machines to different availability zones, regions, or even clouds. Because CloudSwitch acts as a layer-2 bridge between the data center and cloud, virtual machines in the cloud are able to seamlessly access the data center and visa-versa, allowing data and applications to live in either the data center or the cloud. This provides some great opportunities to continue to use your existing IT management tools while taking advantage of cloud storage and cloud compute power in powerful new ways.
We encourage our customers to make full use of the opportunities that CloudSwitch enables:
- Deploy virtual machines to multiple availability zones, regions and/or clouds.
- Clone existing virtual machines or create hot “point in time” snapshots.
- Continue to utilize traditional backup methods.
- Employ traditional file system and/or database replication and load balancing to make your applications as available as possible.
- Automate scripted deployments and life cycle actions on virtual machines.
When reviewing DR strategies with customers, we recommend the following approach:
- Review all applications and associated virtual machines and prioritize them to determine the appropriate DR strategy.
- Review and test monitoring of each application to ensure that you can detect and be alerted to application failures as quickly as possible.
- Eliminate single points of failure for critical applications by providing multiple points of presence in the cloud.
- If you are using replication technology to keep copies of virtual machines in sync, ensure that you have appropriate alerts in place to detect synchronization failures.
- Determine if failover and failback must be automated or manual processes.
- If load balancing is required, weigh the options and limitations of the different load balancers. Amazon’s ELB for instance can balance across availability zones but not regions.
- For lower priority systems that don’t require HA, consider scheduled automated clones/snapshots or traditional backups or both.
Eating Our Own Dogfood
In our own internal operations, we’ve deployed www.cloudswitch.com to both Amazon’s US-East Region and US-West as well as Terremark’s Enterprise cloud. We utilize an open source file system synchronizer to keep these copies in sync. This application also has an automated backup process that backs up data to Amazon S3.
CloudSwitch’s web portal for download/activation and support consists of database and application servers which are deployed to multiple regions within Amazon utilizing database (master-slave) replication.
As our CTO John Considine noted in last week’s blog post, we and our customers had a range of experiences during the Amazon outage, which only reinforced the importance of planning and implementing the procedures outlined above. In some cases, we relied too heavily on snapshots for some of our internal systems, and recognized after the fact that we needed a careful DR review and prioritization of the many applications we have running in the cloud.
Any DR/HA plan should be routinely validated. We’ve taken this recent event as a good opportunity to do this internally and have been working with our customers to remind them of the options that are available to them with CloudSwitch to protect data and make systems more resilient.
In-Path WAN Optimization for your Cloud Deployments with CloudSwitch and Riverbed
By Pavan Pant
As our enterprise customers embrace the cloud, we’ve been hearing a growing demand to help them optimize enterprise network connectivity as they scale their cloud deployments. At CloudSwitch, we’ve been thinking about the issue of network optimization for quite some time now and working with partners like Riverbed to tackle network performance in the cloud.
Today we are pleased to announce our support for Riverbed’s Cloud Steelhead® to help customers optimize their hybrid cloud deployments. Many of our existing customers have already invested in Riverbed infrastructure in their data centers, and want to extend these trusted resources into the cloud. The primary drivers for WAN optimization in hybrid cloud architectures are twofold:
- Improving network performance between data centers and the cloud for better end-user experience
- Reducing bandwidth between the data center and the cloud, thereby reducing cloud costs
In a hybrid model the public cloud acts as a remote data center, making infrastructure resources available to distributed teams of users, but requiring connectivity back to corporate data center resources. Riverbed’s WAN optimization technology can reduce bandwidth requirements and accelerate a number of applications and protocols including Windows file shares, NFS servers and Oracle forms. Riverbed’s innovations in data compression, de-duplication, and other techniques enable much more efficient data movement between customer data centers and the cloud, while freeing up bandwidth for other applications. In our testing we have seen anywhere from a 5 to 100x improvement in your application’s performance, and 60-80% reduction in bandwidth costs.
Simple and Secure Deployment in the Cloud
Our joint solution allows customers to easily select Riverbed’s Cloud Steelhead from CloudSwitch’s network library and launch it unmodified in the Amazon EC2 and Terremark clouds. The user can simply select the cloud networks they would like to optimize, and the Riverbed appliances will take it from there – automatically selecting the network traffic and applications to optimize.
Once Riverbed’s Cloud Steelhead is running in the cloud on CloudSwitch’s isolation technology, customers simply enable automatic peering through Riverbed’s user interface. This ensures that network traffic is optimized as soon as servers in the data center try to communicate with servers in the cloud or vice-versa. In addition, CloudSwitch ensures that all communication and data are automatically encrypted so that your extension of infrastructure into the cloud is always protected, end to end.
CloudSwitch allows Cloud Steelhead to be deployed in-path so that all network traffic on the optimized LAN for your servers in the cloud runs through Cloud Steelhead. This allows the WAN optimizer to accelerate cloud traffic automatically without requiring any additional modifications (no agent installations, no drivers, no changes) to your servers in the cloud. This is the unique advantage CloudSwitch offers– simplicity, security, and the ability to offer WAN optimization with full configurability and control by the enterprise.
Our mission at CloudSwitch has always been to make it easy and secure for customers to launch virtual machines in the cloud. Last year, we enabled public IP access to cloud resources by adding an open-source firewall to our network appliances library. As we learn more from our customers about their requirements, we continue to build our library of partner offerings, demonstrating the strength of our platform and our ability to act as a cloud gateway. We’re excited to support Riverbed’s Cloud Steelhead and are hard at work integrating with market-leading firewalls, load balancers, storage appliances and other devices. Our software lets joint customers easily deploy these virtual appliances in the cloud with secure, in-path configurations to enable much more efficient data movement and scalability in the cloud.
To learn more about how enterprise customers are optimizing the cloud today, please join our upcoming webinar with Riverbed, “Optimizing Your WAN Connectivity for Hybrid Cloud Deployments.”
Now Everybody Wants a Cloud Gateway
Part 1 of a 2-Part Series
By Ellen Rubin
In our discussions with industry insiders, we’re hearing more and more about the need for a cloud gateway — technology that provides a bridge between an organization’s internal environment and one or more public clouds. It’s a message we’re also hearing with growing frequency from enterprise customers and potential partners alike as their cloud architectures mature. In the first post of this series, I’d like to look at what’s behind this trend, and why different stakeholders are making the cloud gateway a top priority.
First of all, it’s another clear signal that cloud computing is becoming mainstream. We’re well past the stage where every cloud deployment is a one-off reengineering project to enable an enterprise application to run in a public cloud. Organizations are no longer willing to tolerate the delays and costs in order to reap the benefits, and now they don’t have to. The gateway simplifies the integration and management of cloud resources so people can get on with using the cloud rather than struggling to make it work.
It’s also connected to the emergence of hybrid clouds that allow enterprises to use cloud resources while leveraging their internal infrastructure. There’s broad consensus that the hybrid model, with pools of internal and external resources federated together, is the best way for large and mid-size enterprises to do cloud computing. Now they’re urgently looking for efficient ways to bring the hybrid cloud to life. They want to be able to turn resources on and off for spiky apps or short-term projects, and a multitude of use cases where workloads flow where they best fit when a threshold is reached. By enabling on-demand access to public clouds with tight integration to data center services, the cloud gateway does the heavy lifting so enterprises can work across these different environments.
We’re also seeing growing momentum from technology vendors, who recognize that the cloud provides an opportunity to move beyond the internal data center, which has become highly commoditized. Much of the demand is coming from network technology companies that provide things like load balancing, firewalling, WAN optimization, and storage optimization — all those capabilities that are normally part of a company’s internal infrastructure. Dozens of established and emerging vendors in this space are looking for ways to move beyond this traditional market, and see the cloud as unclaimed territory. A cloud gateway opens up an exciting new market for these vendors while allowing them to leverage internal technologies (preferably theirs) that customers already have.
A cloud gateway has also become a top priority for providers of virtualization solutions, for many of the reasons mentioned above. The hypervisor has become a commodity as the market has matured and more vendors have introduced competing hypervisor offerings, sometimes for free. Most virtualization players now realize they can’t win with their hypervisor alone. The focus has shifted, and they’ve been trying to move up the virtualization stack by promoting their higher-level management capabilities — competing on things like self-service, charge-back, fault tolerance, resource scheduling, load balancing, etc.
For virtualization vendors, the cloud represents an opportunity, but also a direct threat to their on-premise footprints. They’re urgently exploring how to extend their management functionality into the cloud so they can preserve and capture market share. The ability to span the data center and multiple public clouds, orchestrating between internal and external worlds, is where the new virtualization battles are being fought, and where the cloud gateway is one of the leading weapons.
The cloud gateway has become essential as companies incorporate cloud computing into their business and IT strategies. It’s a message we hear over and over in our discussions with corporate CIOs as well as with executives from technology firms. The next post will examine what characteristics different stakeholders should look for in a cloud gateway in order to be successful.
Coming Up Next: What to Look For in a Cloud Gateway
CloudFormation – Cool, But Who Is It For?
By John Considine
A few weeks ago Amazon released a new feature for Amazon Web Services (AWS) called CloudFormation. This allows a user to organize the process for provisioning and operating resources in the AWS environment and is an evolution of the AWS model of “some assembly required.” We have often viewed the features and functions within AWS as a box of parts, from which users are left to build their own creations. This model is highly biased towards developers, the kind of people who like to have a box of parts and are willing to put in the effort to build new and interesting creations from them.
CloudFormation allows a user to coordinate a number of features within Amazon’s environment, such as: launch a set of AMIs (virtual machine image w/ application), configure a security group (pseudo firewall), setup an ELB (Amazon’s version of a web load balancer), and configure CloudWatch monitoring and alarms. All of this can be managed from a template that describes each of these setup steps, and is written in easy-to-use JSON.
So this new feature is pretty cool, but after working with it for a while, I’ve been wondering who the target user is. If you are a developer that is interacting with AWS through their API, then you already have a method of coordinating the resources and services in Amazon. By definition, up to this point, you had no choice. But more than that, if you are programming to the API, you want to have control over the details of your deployment, and to be able to monitor the steps and process. The CloudFormation is an alternative to your current methods, but is not necessarily better – if you are using the APIs, you still have to monitor the progress and deal with faults during the CloudFormation process.
On the other side of the spectrum, there are the “enterprise-class” users who are looking for full configuration management of their deployments – they want to control the full lifecycle of their system and software deployments including change control of all of the components within the system. The CloudFormation solution is really a provisioning engine, and even at that, it leaves off the early and late parts of provisioning – the actual configuration of the base servers, and the “customization” aspects of running in Amazon. Configuration and customization include things like creating the base images, controlling the OS configuration (kernels, boot parameters, etc.), selecting device drivers for consistent integration and operation, adjusting for randomly-changing IP addresses in Amazon, configuring load balancing based on the notion of instance ID rather than IP address, etc. The actual construction of the application and the configuration of the OS is done outside of CloudFormation, with CloudFormation operating as a provisioning engine.
Given that the developers have the tools they need to coordinate the provisioning and the enterprises are looking for full configuration management, where does this leave the target market for CloudFormation? Clearly the Amazon console users that are interacting with Amazon through the AWS portal are best served by this new feature. CloudFormation gives these users a simple “portal” for provisioning and managing their cloud deployments – but it comes at the cost of programmatic access and integration with existing application lifecycle tools and processes. Console interaction drives cloud activity into its own silo, and fosters the concept of the cloud as being a separate, foreign, and independent environment.
So what does this feature mean for CloudSwitch customers? Not much really, since our customers are looking for tight integration with their existing systems and processes, and want to have end-to-end control over their virtual hardware, operating systems, and application configuration. While CloudFormation is designed to allow a user to coordinate a number of features and functions of AWS, the user still has to use the new and somewhat different components provided by AWS. For example: using AMIs for their VM images, limitations on the kernels, operating systems, and OS configurations, firewall and load balancing configurations that are non-standard, and behaviors in the deployment and operation that deviate from the expected behavior in the enterprise.
In the CloudSwitch model, if a user wants to configure a firewall, they use a full-featured firewall with full configurability, not an Amazon-specific version; if a user wants to monitor their applications, they use their existing tools and processes; and if a user wants to have full configuration management of their deployments, they can control every detail of their servers virtual hardware, operating systems, networking, and applications – and not conform to the restrictions of the cloud provider. As our customers know, CloudSwitch is about giving the enterprise full control over cloud configurations and processes, rather than coordinating the components that a cloud provider delivers.
Protecting Your Cloud Deployments with Enterprise-Class RBAC
By Pavan Pant
We recently talked about CloudSwitch’s security model while highlighting our integration with Active Directory. Our architecture addresses three areas of protection which we believe are required to make the cloud secure for enterprises – security within the data center, between the data center and the cloud, and within the cloud itself. Given that this is an area of paramount importance for enterprises I thought it would be useful to continue with the theme of security by discussing our role-based access control (RBAC) model. CloudSwitch’s RBAC capability is directly related to protecting resources in your data center from unauthorized access, while also controlling the privileges users have over cloud resources.
Years of experience in enterprise software development have taught us that retro-fitting an access control model is not a viable option – it’s like closing the barn door after the horse has bolted. Our solution was built from the ground up with an RBAC mechanism in place. We developed a granular RBAC model which allows administrators to delegate permissions across users and groups using roles and access control lists (ACLs) defined by a CloudSwitch administrator.
This gives customers the ability to group users with similar job functions into roles, and to give them authorizations to perform actions on objects in CloudSwitch. Our objects are entities such as folders, virtual machines, cloud accounts, etc. Using our RBAC capabilities allows customers to create a least-privileged access control model by only providing users with access that is absolutely essential for cloud operations. Every object and action in our system can be assigned to an ACL so that an administrator can enforce policies for cloud usage, cloud control, and local resource control. This approach allows customers to select roles in which users can operate, and the capabilities of each role are based on those users’ expected responsibilities. For example, a developer role might have permissions to create, clone, start, stop, and delete servers, whereas an operator role might only have start and stop permission.
Another important point here is that administrators can grant or revoke privileges on a CloudSwitch object independent of what the role does. As an example, you may have a set of IT administrators with privileges in CloudSwitch to start, stop, and delete servers that are running in the cloud. However, there could be a specific subset of production servers that you may not want even the IT administrators to control. With our RBAC model you can grant users permissions across the whole system with the ability to restrict access for specific servers.
These controls take on even greater significance as customers move production workloads to the cloud. With that in mind I thought it would be useful to walk through some of the RBAC use cases we have heard about from our customers, and how CloudSwitch can be configured to meet those use cases.
RBAC Use Cases
Use Case 1: Creating Sandboxes in the Cloud for Developers and QA
One of our large customers in the pharmaceutical space was running into a problem where their research scientists were increasingly faced with delays in gaining access to computing resources primarily due to a large and growing IT organization. They wanted to use the public cloud for their computing needs as an alternative to using internal IT resources.
Their primary objective was to deliver a streamlined solution to their developers which would allow them to clone read-only gold images created by administrators. The process needed to be as simple as possible with the appropriate security controls in place to prevent developers from modifying the images shared with them by administrators.
With CloudSwitch, this customer’s administrators were able to easily upload their gold image to the cloud, provision a server template in the cloud using the gold image and place it in a folder structure within CloudSwitch that only developers could access. Once that step was complete, the customer used our RBAC model to ensure that developers had permissions to clone the server template made available by the administrators and permissions to perform server lifecycle actions on the cloned server (start, stop, delete, power off, add NICs, add disks).
The end result was that developers could easily login to CloudSwitch’s user interface, clone the administrator template that was made available to them, start that cloned server in the cloud and shut it down when their work was complete. This was a much quicker and cost-efficient way to get access to compute resources in the cloud, especially when compared to the customer’s previous approach of waiting for resources from their IT department. It also ensured that the developers had just the right amount of privileges to perform their daily activities in the cloud.
Use Case 2: Network Administrator Privileges
Our customers have also frequently asked us about separating out permissions such that only specific users have the ability to modify network settings for cloud networks. Customers wanted each department to control their own network mappings without allowing other users or groups to modify the networking configuration.
To solve this problem with CloudSwitch you would simply create a role (e.g., a Network Admin role) and define an ACL where only users in that role would have the ability to configure the network and NIC configuration for servers in the cloud, or even networking configurations for CloudSwitch components. You could even go a step further by creating a “Network Administrator Subnet 1” role for servers on a specific subnet in the cloud, and a “CloudSwitch Network Admin” role for users who only have permissions to manage networking configurations for CloudSwitch components such as the CloudSwitch Appliance which resides in your data center or private cloud.
Other Common Use Cases
Other customer scenarios involve using RBAC to define and limit which import sources can be moved to the cloud, and which target clouds can be used. CloudSwitch allows customers to migrate virtual machines from VMware or Xen to the public cloud without making any changes to the virtual machine (e.g., no changes to the kernel, OS, IP address, MAC address, storage controllers, subnet information, etc.). As part of this process, you can define import sources from VMware or Xen in the user interface, and specify which roles get access to those resources. You can create multiple import sources in CloudSwitch for different groups within the organization while ensuring that the appropriate people or groups (e.g., Development, Quality Assurance) have the right amount of access to these import sources. We have also had cases where customers want to restrict which cloud regions (or cloud providers) certain groups have access to. For example, one of our customers wanted most of their users to deploy in Amazon’s US-East region since it is cheaper than US-West. However, there was a group on the west coast that really benefited from the geographic proximity of using US-West. CloudSwitch’s RBAC model allowed this customer to grant that one group access to the more expensive resources in US-West while the rest of the organization was restricted to using resources in US-East.
These are the types of granular access control capabilities that a growing number of customers have requested, especially as they move production workloads to the cloud. It has been great to see large enterprises across verticals using our RBAC capabilities to secure their cloud deployments, from the data center, to the cloud and within the cloud. CloudSwitch was designed with the hybrid cloud in mind and our core value proposition lies in the ability to securely transport your virtual infrastructure to the cloud provider of your choice without requiring any modifications. A large part of that vision hinges on giving enterprises the ability to control the type of access people have both in your data center and in the cloud. We’ve built a solution that gives customers the ability to use their existing security policies and permissions in the cloud instead of creating new ones for their cloud deployments.
CloudSwitch + Amazon's VPC = Full Encryption and Isolation in the EC2 Cloud
Today, Amazon announced a new version of their Virtual Private Cloud (VPC) offering. This move reflected the learning and requirements from enterprise customers who have tested or deployed VPC over the past year. Initially, VPC was developed to provide a secure tunnel (layer-3) from the customer’s data center to EC2, to make it easier to receive the approval of internal security groups for cloud deployments. Customers had noted that there were many aspects of VPC they felt could be enhanced, primarily around making the networking options more sophisticated and flexible. As Jeff Barr noted in his blog on the new release, a major focus was to enable public-IP access through a cloud-based firewall/load balancer to the cloud VMs. We’re glad to see this new set of capabilities, since we had definitely heard this requirement from customers as well, and responded to it last year.
We’re excited to support customers and prospects who are interested in evaluating the latest version of VPC and integrating it into their EC2 deployments. We believe that together, CloudSwitch’s award-winning software and Amazon’s VPC offering deliver enterprise-class security and integration with customers’ internal data centers and private clouds. CloudSwitch provides full encryption of all data and communications, and lets you extend your enterprise network topologies into the cloud without modifications. This means that your entire cloud deployment is secured end-to-end, and remains completely under your control, as if it were running locally behind your firewall.
It’s great to see Amazon’s ongoing commitment to innovation and to work with joint customers who want to make the cloud a truly secure extension of their internal environments.
