Recent Posts
The Hidden Costs of Internal Clouds
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy 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.
