Cloud Computing
Dealing with the Cloud's Latent Tendencies
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInBy John Considine
One of the frequent questions we get when we engage with customers moving applications to the cloud is: what about the latency issues when using a cloud? This question arises because most IT departments have had to struggle with application performance issues and the idea of adding a big chunk of latency when integrating the cloud is very troubling. Here is how we address this:
1. Move the whole application to the cloud. We have been working hard to allow you to move all of the components of your application to the cloud. With this capability, you are not adding the latency between your data center and the cloud to the interactions between the servers in the cloud. A simple example is moving both the presentation tiers and database tiers to the cloud. The front-end servers talk directly to the database in the cloud, and they experience “data center” level latencies (i.e., nearly the same as in your DC). This often leads to a related question: if I move the whole application, where is the hybridization and integration? Simple, there are a collection of other services and data that your applications depend on – things like name servers, identity servers, domain controllers, ancillary databases, etc. Often access to these services is not latency-sensitive because it’s not part of a high transaction rate process.
2. Use a cloud that is “nearby.” Latency is a function of distances and “hops” across routers. The closer you are to a cloud, the lower the latency. This is one of the reasons we have architected for multi-cloud support, and are so focused on zero modification of your servers and applications. If you have the freedom to use a cloud that is “closer” without having to change your configurations, then you can take advantage of resources that make sense to you. We’re excited to see more players creating and expanding cloud offerings; more clouds in more locations means that we can help customers integrate cloud with their data center infrastructures, taking advantage of lower latency, higher SLA’s, and better pricing. With Amazon opening more regions, Savvis and Terremark supporting more than a dozen data centers each, specialized players like BlueLock focusing on security and compliance, and folks like Microsoft and AT&T getting into the mix, we expect that there will be “nearby” resources available for most companies in the near future.
3. Take advantage of WAN optimization. You cannot defy the laws of physics, the speed of light is a real limit, and thus the distance to the cloud you are using will determine the minimum amount of latency. Given this, however, there are things that can be done to minimize the impact of latency and bandwidth restrictions. There are a number of products out there that help with Wide Area Networking optimization and CloudSwitch can take advantage of these in two ways. The first is that we work with your existing network infrastructures so that if you have optimized links available between your data center and a cloud provider, we can take advantage of them. The second is something we are working on – integration with these products such that they can be deployed with or alongside of CloudSwitch to optimize cloud communications.
The bottom line is that latency issues are part of your decision process when you determine which applications (or parts of applications) will get moved to which cloud, and you should test the results early in your cloud evaluations. With CloudSwitch you have some good options for dealing with the inherent latency issues in cloud deployments so you can successfully integrate the cloud into your IT infrastructure.
Get off the Bus - Explore the Cloud TODAY!
By George Moberly
A year ago I attended a session at Cloud Expo in New York. The presenting company told the audience that “cloud exploration services” were now available. Enterprises could purchase these packaged services to discuss, probably at length, how to identify candidate applications for cloud usage.
I’ve been there and done that – as a former professional services manager for such a “Big 4” data center automation company, I’ve participated in many such “school bus” campaigns. Often the end result is that everything is said, and little gets done.
According to this philosophy, you can’t just go out and try the cloud for yourself – instead, professional services are needed, and plenty of them. After the expenditure of months of time and large sums of money, you might be lucky enough to get a report of some applications that would be suitable to move – to their specific cloud.
While this approach well serves the interest of the vendor, there is a better way.
The premise of the cloud is that there is almost no penalty for trying something and failing. Move some applications and try them out. You didn’t get the SLA or characteristics you were looking for? You’re only out a buck or two.
Of course the premise I’m making is that you don’t have to change anything in your services, applications, networking, or infrastructure to give this a try. I make the further premise that the cloud enablement software doesn’t require a services engagement to acquire, install, set up and configure, and manage operationally over time. This week, we made CloudSwitch available. Give it a try. You can acquire, install, configure, move and run your applications today. No services required. You point us to your virtual machines, our software will automatically show you if they fit in the cloud, and after we’ve transferred them to the cloud, they will look and feel just like they do now, running in your on premise virtualized infrastructure. No engineering. No changes. No agents. No “additions” to your servers. No funny installers.
All this said, there are physics involved. I recommend a simple process that will result in immediate positive results in selecting candidate applications to move and run in the cloud, as well as in the confidence that comes from a “real test” involving complex multi-tier applications which are tied to both premise-naming services and other network services that cannot be moved out of your data center.
For a first application, I suggest finding something that has servers with relatively small disks. Moving disks over the internet can take time. Some ideas include an internal project server running a program management application, Wiki, or SharePoint. Or perhaps a development environment for a JBOSS application, or anything else based on an open source stack. Move and run this, and run the same load testing or characterization/acceptance tests you use today, and see how they perform.
For a second application, I suggest taking the web and application tiers of the three-tier application and moving them, leaving the data tier on-premise. Leave your management agents on those servers, and leave them joined to the same domain if they are Windows servers, or using the same naming services. Don’t be concerned if the servers have NFS or CIFS mounts to on-premise NAS storage.
For a more in-depth test, go ahead and move development environments for applications such as PeopleSoft, Siebel, or SAP into the cloud and develop your applications there. Extra desktops for developers make a good initial application to move, as do development support servers such as continuous build, defect tracking, and source code repositories.
Our focus on providing a zero-friction, packaged appliance-based product makes this possible. Our automatic CloudFit process will tell you up front if your application will fit and run successfully in the cloud prior to incurring any cloud spend, and how much it will cost per hour to run.
Sign up for our Beta and move and run your first application in the cloud TODAY! School bus not included.
The Hidden Costs of Internal Clouds
By Ellen Rubin
A public cloud can provide access to computing resources that many companies would otherwise never be able to afford. The arguments for the cloud are well-known by now, but remain compelling—no up-front costs, virtually unlimited computing power on demand, and highly efficient pricing where customers pay only for resources used. There’s also less pressure on corporate IT departments that are charged with managing the infrastructure and budgeting for new equipment to keep up with demand.
But concerns about security and loss of control in public clouds have led to an alternative model—the internal cloud—that replicates the cloud environment inside the corporate firewall. Within these boundaries, enterprise users can provision computing resources as needed, using the cloud’s self-service capabilities while leveraging data center services. Internal clouds are often referred to as private clouds, but since private clouds can also be found in external environments, the “internal” designation is a more precise term for what we’re talking about here. (RightScale's blog post provides helpful definitions of the different cloud variants.)
With servers, applications and data within the enterprise walls, internal clouds can provide many of the benefits of cloud computing without the potential risks when the computing environment is provided by a third party. Unfortunately, the economics of internal clouds makes them inherently less efficient than the public cloud, especially as new technology makes the public cloud safer and more reliable. Here are some of the reasons why:
- Infrastructure costs: Deploying an internal cloud requires building out the infrastructure to support the needs of all enterprise users. In addition to acquiring the necessary hardware and software, this includes things like configuring the network, allocating storage, paying the electric bill, and providing square footage for the equipment. Plus, all of this infrastructure has to be managed and supported on an ongoing basis.
- Over-provisioning: Just as with traditional IT infrastructure, anticipating resource requirements for an internal cloud is difficult since applications run at varying usage levels. Some applications consume resources fairly steadily while others require occasional bursts of massive computing power. Companies may have no choice but to over-provision, where some equipment sits idle most of the time in order to have resources available for peak periods. (Meeting these short-term usage needs is one example where the elasticity of public clouds really pays off.)
- Building the management plane: As Jon Brodkin points out, building an internal cloud is about more than just virtualization. One of the key benefits of cloud computing is the self-service aspect, where users can access resources as needed via a self-service portal, which then execute in the cloud automatically without administrator intervention. Building this control plane is another substantial step when implementing an internal cloud.
For all of these reasons, the internal cloud carries a cost overhead compared to leveraging the resources and self-service framework already provided by public clouds. Ironically, much the same protection and control offered by internal clouds is becoming increasingly available in an external public environment. So enterprises may find that a public cloud may provide a more cost-effective home for many (or even most) of their applications.
Internal clouds can make sense for the most business-critical requirements or those that need specialized hardware or have regulatory compliance issues. Focusing internal resources on these types of applications would greatly reduce the investment required to build, sustain and grow enterprise infrastructures. While some applications may always need to run internally, many companies have dozens of others that could run more cost-effectively today in a public cloud, providing computing power on demand along with required security, agility and scalability.
At CloudSwitch, we provide technology that allows companies to take full advantage of the resources and savings that the public cloud has to offer, while integrating seamlessly with their internal environments. Applications deploy automatically, are free from lock-in, and stay tied into internal data center services. In short, the enterprise gets the protection and control formerly found only behind the firewall, and can combine the best of internal and external cloud offerings with maximum agility and value.
Why an 'Apps' Guy Moved to the Cloud
I have spent most of my career involved in the development of software applications. For the past seven years, I had the honor of leading SolidWorks, the # 1 mainstream 3D CAD company in the world. When I left in 2007 we had over 750,000 users and tens of thousands of companies using our software. They were designing products that you and I use in our everyday lives.
Through a lot of hard work of hundreds of employees and some luck we helped create a lot of value for these customers as well as our investors and business partners. In addition to good luck (which we admittedly had a lot of), we capitalized on a fundamental platform shift: Unix to Windows. This platform shift, combined with a business model shift (direct sales to indirect sales) created a significant amount of value. I sense the same opportunity with the cloud.
After taking some time off, I spent time with some local venture capital firms looking at a lot of new technologies, new products and business ideas. All of the start-ups (not just some, but all) were using the cloud for their infrastructure. Like canaries in a coal mine, this to me validated what I was observing: the cloud really is a new platform. Also, the cloud requires a business model shift in enterprise software sales since cloud services by their nature are low-cost and on-demand – unlike the traditional sales model of large, costly enterprise purchases.
I spent several months more looking at companies in and around the cloud space and became intrigued by the perspective shared by Ellen Rubin and John Considine, founders of CloudSwitch. They had a clear view of how they felt companies would want to take advantage of the cloud. This was evident in their approach: rather than try to take the clouds to the data center (which everyone appears to be doing), they wanted to start from the data center and help them extend out to the cloud.
Combine this simple, yet profound insight with a platform shift and a business model shift and you understand why an apps guy would be so excited to join the CloudSwitch team.
Pre-Register for Our Upcoming Beta Program
Today we held our first webinar about our upcoming beta program. Beginning in March, we’ll be making two products available to beta customers: our free CloudSwitch Explorer and a free trial version of our commercial CloudSwitch Enterprise. Stay tuned for the beta releases in a couple of weeks. In the meantime, you can pre-register now to join the expanded beta.
What If You Could Provision in the Cloud Using Your Existing Data Center Tools?
What if you could use your incumbent data center bare metal provisioning tools to create application instances in the cloud?
Today you may be using familiar tools in your data center to build out new application stacks successfully, such as Microsoft ADS or RIS, Kickstart or Autoyast, HP Opsware or BMC BladeLogic, or Altiris. You may have also made a significant additional investment in front-ending these provisioning tools with an in-house developed provisioning portal, or orchestrating these tools with a workflow or Runbook automation tool.
These tools and processes require a significant investment in their deployment and in the authoring and configuration knowledge that is embedded within them. But, as flexible as these tools are in reliably building configurations, they are not usable as-is with compute resources in the cloud. Consider Amazon EC2, for example. How will you get their Xen paravirt network device to PXE broadcast, or route that back to your on premise DHCP/TFTP infrastructure? Till now, the answer is that you can’t.
So, you are faced with having to use another siloed provisioning tool that is designed and built for use with your chosen cloud provider. You need to retrain staff. Reprogram configuration scripts. Maintain parallel systems that are basically doing the same thing.
It’s hard to argue that it’s worth doing all this, outside of the compelling premise that you REALLY want to be able to turn on something for 2 hours, and pay 15 or 16 cents for the use, and then turn it off. The power of that flexibility has been the motivating force behind organizations going against the grain and adopting a separate and purpose-built cloud provisioning tool to take advantage of the elasticity and flexibility of cloud-based servers.
But what if you didn’t have to make that choice? What if you could treat cloud servers EXACTLY as if they were new bare metal blade servers that had come off the loading dock, been racked and stacked, powered on, and started PXE broadcasting? Today, you can import a list of MAC addresses off your asset sheets for these newly powered-on servers into your incumbent bare metal provisioning tool of choice, and start throwing your J2EE stacks onto these servers.
CloudSwitch is committed to the proposition that you can have your cake and eat it too. You can create as many blank servers as you want, using any combination of instances sizes to customize the cores, memory, storage, network, and compute capacity that you need to provision an application stack. The blank servers can be interrogated for generated MACs. You can plug those into your bare metal provisioning systems, just like the good old days when you could go over and see the lights flash for your new server in its rack, and get ILO console access.
Turn them on, let them PXE boot, and let them provision your stack. Use them as long as you need them and throw it away. You won’t have to retire the equipment or plan a server upgrade. Your cloud provider will take care of that for you. You won’t have to change a thing. Everything you have in place will still work. Transparently.
Isn’t that just a basically better idea?
__________________________________________________________________________________
Vote for CloudSwitch! Watch our video and cast your vote on Cloud Connect LaunchPad. Help CloudSwitch advance to the finals.
Opscamp Austin: IT Ops and the Cloud
Going to a conference focused on IT on a Saturday sounds like a really geeky way to spend a weekend, but thanks to an “alternative” venue, the “un conference” format, and a group of really good people, it was a great day. I just got back from Opscamp Austin, a meeting of IT professionals, system administrators, tools vendors, cloud providers, and people who spend their time building and keeping the computing infrastructure of business running. Many thanks to those who built this un-conference especially John Willis, Mark Hinkle, Damon Edwards, and all of the sponsors and presenters – you pulled together a great event.
Opscamp was created to allow an “open exchange of ideas around next generation technologies and strategies for IT Operations.” The big topics at this meeting (as measured by both passion and interest) were Monitoring, Configuration Management, and DevOps. I was particularly interested in these topics because we added the phrase “in cloudy environments” to the sessions.
I came away from this conference with a few conclusions:
1. IT operations is currently messy, and “cloud computing” is exposing some of the problems. One problem is that when the cloud delivers on the notion of allocating resources in minutes, the pressure switches from raw provisioning to the speed of configuration; with the timescale compressed from days to minutes, there is nowhere to hide. The other big issue is the dynamic nature of cloud computing – with servers, networks, and storage showing up and disappearing from your environment, it becomes difficult to model and manage. The manual or loosely connected processes that worked because there was time while you waited for hardware to arrive no longer work in a highly dynamic environment.
2. There are very different views about what monitoring in the cloud should be – deep and consistent with current processes, or “just hide the messy parts,” to quote Amazon. Some wanted the cloud providers to give them deep access to the “normal” monitoring data – think cpu temperatures. Others think that the value in the cloud is getting rid of the support and detailed attention to the infrastructure, so who cares about that data, it is for the infrastructure provider to manage. The issue is that the current cloud offerings are quite opaque about what is happening in the infrastructure.
After talking with Bret Piatt from Rackspace it seems that the problem is not collecting the data (they have to do it anyway), but storing it, processing it, and doling it out to the customers. There is real expense here, and for those customers who don’t want it, they would have to carry the burden of the extra cost in a market that is sensitive to price. The fundamental choice here is whether we are going to carry the current detailed monitoring practices into the cloud, or give up on the low level monitoring of the remote resources. In order to carry forward the current models, the cloud providers will have to provide API’s to get at the internal data. In order to change the model, developers and tool providers will have to increase the capabilities of the applications around fault tolerance and providing useful monitoring data that can be measured from the application level.
3. We are still in the early days of cloud computing. This should not be a surprise to anyone, but since at CloudSwitch, we’ve been so fully integrated with the cloud since the beginning – with everything from our build servers, bug database, large number of QA servers, code repository and web site –it’s easy to think that everyone is already comfortable using the cloud. What became clear in the discussions is that many of the organizations are still working though server virtualization and how to take advantage of the advanced features enabled by that technology.
What was really exciting for me was to see the people who actually have to make IT work thinking through what is needed to build a dynamic data center and integrate with cloud computing. With these guys on the case, I know that cloud computing is taking real steps forward.
Security vs. Compliance in the Cloud
Security is always top of mind for CIOs and CSOs when considering a cloud deployment. An earlier post described the main security challenges companies face in moving applications to the cloud and how CloudSwitch technology simplifies the process. In this post, I’d like to dig a little deeper into cloud security and the standards used to determine compliance.
To codify data security and privacy protection, the industry turns to auditable standards, most notably SAS 70 as well as PCI, HIPAA and ISO 27002. Each one comes with controls in a variety of categories that govern operation of a cloud provider’s data center as well as the applications you want to put there. But what does compliance really mean? For example, is SAS 70 type II good enough for your requirements, or do you need PCI? How can your company evaluate the different security claims and make a sound decision?
SAS 70 (Types I and II)
SAS 70 is a well-known auditing standard that features prominently in many compliance discussions. It encompasses a variety of controls in different categories (physical security, application security, security policies and processes, etc.). SAS 70 is not a specific set of standards; instead service organizations such as cloud providers are responsible for choosing their own controls and the goals those controls intend to achieve. With SAS 70 Type I, an independent auditor evaluates the controls and issues an opinion, while the more coveted Type II is based on at least six months of active data. Accordingly, many providers will state that they are in compliance with Type I, and Type II evaluation is underway.
SAS 70 has some wiggle room, and you have to dig a little deeper to determine what the certification really involves. The savvy cloud customer will want to know not just whether a cloud is SAS 70 Type II compliant, but what controls they selected in order to get there. This is a question that people normally don’t ask, and under SAS 70 guidelines, service providers have no obligation to tell you. Thus, the level of transparency varies. Some providers may be quite willing to share their audit report describing their controls, objectives and methods. Others will explain that the information is confidential and delivering it would expose company secrets. Or some types of control information may be freely available and others off-limits.
PCI (and Its HIPAA Component)
A second major security standard in cloud computing is PCI. As the security standard for Mastercard and Visa, PCI has a known set of required controls, making it inherently more stringent than SAS 70 where controls are determined by the service provider. The inference is that PCI has stronger security than SAS 70 (and can command higher pricing). However this is not cast in stone—it depends on the SAS 70 controls that the service provider has chosen. Due to the more rigid compliance requirements PCI branding is usually harder to achieve than SAS 70. HIPAA is a subset of PCI, which means that if a cloud is PCI compliant, HIPAA compliance comes with it.
Compliance Building Blocks
Regardless of which standard is used, achieving compliance to run an application in a cloud involves building blocks, with the cloud provider’s physical infrastructure providing the foundation. Infrastructure controls include obvious things like protecting the facility from natural disasters, assuring reliable electrical power (such as backup distribution systems) in the event of outages, and backing up data in the event of a hardware failure. They also include controls governing the cloud provider’s processes and policies such as employee authorization to access the data center and how internal security reviews are performed and reported.
Sitting on top of the infrastructure controls is a separate set of application controls. Multiple levels of security are required, for example, the transport media must be secure and data must be encrypted once it leaves the data center with encryption keys under enterprise control. An application might meet SAS 70 or other standards within a company’s data center but not when it’s moved to a cloud because of exposures that may exist there or along the way. Likewise, a SAS 70 TII application in the cloud may not meet the controls if moved back to the enterprise datacenter, and could require a re-audit.
Deploying to the Cloud
There is a difference between compliance standards and what a company needs to feel secure. For data and applications that have regulatory requirements, compliance standards and audits are mandatory. For these types of applications, we’re still in the very early days for cloud computing—let’s face it, no company is going to put critical regulated applications into the cloud without the ability to conduct complete end-to-end audits. However, even for applications that do not require compliance, enterprises want to know that their data and applications are protected. Achieving security in these environments is where CloudSwitch is focused.
Cloud computing creates a division of responsibility between the cloud provider and the cloud customer. While the cloud provider needs to address infrastructure operation and protection, the customer is responsible for ensuring compliance for their application, and ultimately the overall solution. The central idea here is keep the controls separated between the cloud provider infrastructure and the customer application. If the controls mix, where for example the cloud provider has access to stored data, then things get very complicated. When this occurs, you have to worry about who in the cloud provider’s organization has access to your data, how and when they can access it, and how this access is audited and controlled. If the provider is opaque, then you can’t know. Even if the cloud provider is more transparent in their access polices, you have to evaluate those controls against your standards and potentially have to adjust your own controls in response. Further, you have to adjust to all changes in the cloud provider’s processes over time.
By keeping your systems isolated from the cloud provider’s infrastructure, you can minimize this mixing of controls. Placing protection mechanisms into your resources in the cloud can assure that data moving across the cloud provider’s networks and all data stored in their systems is encrypted. Combined with external key storage and management, your applications can be separated from the cloud provider’s infrastructure. This still requires that the cloud provider run its data center with proper physical security, power management, etc, but can greatly enhance the application level security that the enterprise needs. Finally, this separation can simplify the process of achieving compliance at the application level when running in the cloud. This isolation layer can address a number of the data protection controls by providing a uniform and repeatable process for encrypting data.
The days of cloud computing are just beginning, but with the right combination of cloud providers and additional technologies, it’s not too early to start doing real work in the cloud and to reap the benefits of this new computing paradigm. Our early customers are doing it, and so can you.
Cloud Federation and the Intercloud
Last week’s post explored federation in the cloud, allowing enterprises to move workloads seamlessly across internal and external clouds according to business and application requirements. Advances in federation are good news for companies considering a move to the cloud since deployments no longer need to be custom projects and applications no longer have to be tightly coupled to a particular cloud.
To follow up, there’s been lots of discussion recently about the concept of the “Intercloud,” a direction for cloud computing that is closely related to federation and ties in with much of our work at CloudSwitch. A term introduced by Cisco, the Intercloud refers to a mesh of clouds that are interconnected based on open standards to provide a universal environment for cloud computing. Like the name suggests, it’s similar to the Internet model, where everything is federated in a ubiquitous, multiple-provider infrastructure.
The primary difference between the Intercloud and federation is that the Intercloud is based on future standards and open interfaces, while federation uses a vendor version of the control plane. With the Intercloud vision, all clouds will have a common understanding of how applications should be deployed. Eventually workloads submitted to a cloud will include enough of a definition (resources, security, service level, geo-location, etc.) that the cloud is able to process the request and deploy the application. This will create the true utility model, where all the requirements are met by the definition and the application can execute “as is” in any cloud with the resources to support it.
What shape the Intercloud will take and what standards will emerge to make it work are part of an ongoing debate. Some industry watchers believe it will happen sooner than later. Others believe that discussion of the Intercloud is premature, wary that embracing standards too quickly will hold back innovation, and therefore the Intercloud will remain only a vision for the foreseeable future. When these debates will be resolved is anyone’s guess, but major progress in cloud integration is already underway, so there’s no need for enterprises to put their cloud plans on hold.
At CloudSwitch, we believe that the Intercloud is likely to emerge organically as the result of continuing innovations throughout the cloud ecosystem. Federation is one of the prerequisites toward that goal, providing ongoing improvements in cloud interoperability aimed at giving enterprises many new options from which to choose. The ability to federate identity, access and dataset migration is also one of the key requirements for Intercloud activity. This interoperability at the infrastructure level has to work transparently in order to launch applications into the cloud environment and manage the integration.
The benefits of the Intercloud are in many ways already a practical reality. A significant part of the Intercloud vision can be achieved with a strong federation technology that provides a gateway between different clouds and the internal data center. Users and their companies can avoid lock-in and run workloads in the environment that best matches their needs, based on cost, performance, security, compliance, geography, latency, etc. In short, some of the most important Intercloud goals can be achieved using technology already coming to market.
2010 is the Year of the Federated Cloud
In this first post of 2010, I’d like to look at one of the most important cloud issues that enterprises want to tackle: federation in the cloud — across clouds and between the cloud and the data center. Also known as hybrid clouds, the notion of federation has been around since cloud computing began, but as a long-term vision rather than a working solution. This year that gap is going to close.
What Is Cloud Federation?
Federation brings together different cloud flavors and internal resources so companies can select a computing environment on demand that makes sense for a particular workload. It opens the door to a range of useful scenarios that take advantage of cloud capabilities:
- Using multiple clouds for different applications to match business needs. For example, Amazon AWS or Rackspace could be used for applications that need large horizontal scale, and Savvis or Terremark for applications that need stronger SLAs and higher security. An internal cloud is another federation option for applications that need to live behind the corporate firewall.
- Allocating different elements of an application to different environments, whether internal or external. For example, an application could run in a cloud while accessing data stored internally as a security precaution. (We call this concept “application stretching.”)
- Moving an application to meet requirements at different stages in its lifecycle, whether between public clouds or back to the data center. For example, Amazon or Terremark's vCloud Express could be used for development, and when the application is ready for production it could move to Terremark's Enterprise Cloud or similar clouds. This is also important as applications move towards the end of their lifecycle, where they can be moved to lower-cost cloud infrastructure as their importance and duty-cycle patterns diminish.
Enterprise users don’t typically talk about federation per se; they speak in terms of application-specific and general business requirements. While some applications will always belong in their data center, they may have others (possibly hundreds) that could run more cost-effectively in the right cloud. Our customers and prospects tell us that they would love to take advantage of different clouds to get the computing performance they need, along with the desired service levels, scalability, security and price points. And since they aren’t that clear yet on their cloud requirements, and cloud services are in early stages and will continue to evolve, they want the ability to pick up their applications if necessary and move them to other clouds or back to the data center with minimal effort.
The problem is that the cloud is not a homogenous entity, but covers a broad landscape of computing environments, with no consistency between any of them or with the enterprise data center. Federation is the missing link, providing a structure that bridges these disparate environments so enterprise cloud computing can become as seamless and straightforward as it needs to be. Let’s examine some of the key issues and see what CloudSwitch is doing to make federation work.
Bridging the Differences
An application should to be able to run “as is” in any cloud with the resources to support it. But each cloud has its own server platforms, operating system versions, APIs, network settings, storage options—a whole landscape of varied characteristics. Without federation, each cloud deployment becomes a custom “one-off” exercise to meet the requirements of a particular cloud environment. That’s not acceptable internally, and companies are now demanding the ability to leverage different clouds without the underlying engineering efforts required to make it happen.
A unique capability of CloudSwitch is the ability to integrate at an infrastructure level between the data center and different clouds. We sit in the middle of all of these resources and automatically bridge the differences, regardless of variations in virtualization platforms, operating systems, APIs, storage infrastructures or other characteristics of the different clouds. Both internal and cloud resources appear as if they’re running locally, using a common interface spanning multiple clouds and the local environment.
Setting Consistent Rules
Rules and permissions about what employees can do in the cloud must be consistent with those in the data center. Role-based controls are required, for example, to enable a particular individual or group to create servers but not to delete or modify them. However, in these early days of cloud computing, the standard procedure is to allow cloud users access to the cloud credentials; essentially every user has full control and access to the cloud resources. This not only causes control issues but makes auditing and problem resolution difficult since it is unclear who is responsible for any particular action.
CloudSwitch solves this problem by holding the credentials for external clouds and serving as the gateway to cloud accounts. Rather than users accessing their accounts directly, they interact with the cloud through the gateway, which consolidates permissions for all users and multiple clouds for management by an administrator. The approach provides consistent policies governing user and management roles, whether internal or external.
Streamlining Cloud Management
Federation also means that administrators should be able to manage applications running in one or more clouds as if they were running locally, using their familiar tools and processes for application lifecycle management, monitoring, compliance management, etc. But cloud computing involves a wide assortment of isolated environments to keep track of and manage. Adding to the complexity, cloud providers often have their own management tools that users or administrators need to learn, all different from each other and from what enterprises have internally.
CloudSwitch keeps things simple for the enterprise by replicating the existing IT infrastructure and mapping it to the target cloud. The approach allows current management tools to work seamlessly in the cloud, just as if an application were running locally. Using consistent tools and policies, applications and resources can be managed with the same flexibility, security and control regardless of their location.
Bringing the Vision to Life
Federation is required for cloud computing to be successful, particularly as computing needs continue to expand. Enterprise users want to take advantage of all the capabilities available in the cloud, but without the complexity or risk. The ability to federate this heterogeneous ecosystem—to create a uniform environment spanning external and internal clouds—is going to allow IT organizations to meet user and corporate needs with an agility and economy not previously possible. CloudSwitch is part of an emerging ecosystem that’s making federated cloud a reality.
RSS Feed