CloudBolt Blog

Proprietary hardware and processor architectures have been outpaced and eventually replaced by commoditized Intel and AMD x86 and x86_64 hardware platforms. Along the same lines, Linux and other open-source operating systems fully commoditized the operating system, ensuring that the underlying architecture really isn’t too important anymore. The next logical step in this was to further commoditize the operating system and hardware platform together—which is what server virtualization does. Server virtualization makes the hardware the ultimate commodity. Often the management layers of the best virtualization platforms are intelligent enough to even appropriately handle differing processor specifications and memory configurations on the hypervisors.

The Intel-based x86 chip revolutionized IT.

A fully server-virtualized environment, however, is still reliant on several things:

1. The administrators are still required to know and understand where and what is being deployed virtually. 
2. When a user makes a request for a resource, it’s got to be put somewhere, and that underlying virtualization technology is something that has to be dealt with, understood, and eventually manipulated in a manner to deploy the requested resource. 
3. The idea of IaaS and PaaS disrupts this a fair amount, but there’s still a choice—a implicit understanding that your requested compute resource is dependent on a single underlying technology, be it from EC2, Google Compute Engine, VMware, RHEV, Xen, Hyper-V, or anything else.

The next step in organizational IT maturity has to be the full commoditization of that compute layer. Just as organizations can now procure commodity servers and storage from a variety of vendors, and abstract that hardware choice using virtualization, so must the actual virtualization technologies be abstracted from the end user. In the end, this makes sense. Users don’t need to know or care where their compute is coming from. They just want access to the resources and services they’ve requested when they requested them. Just as administrators have the ability to choose amongst various hardware providers without affecting users, they should be able to choose amongst differing physical locations, virtualizations technologies, and even cloud providers.

This is where CloudBolt steps in. CloudBolt C2 commoditizes the compute layer. Regardless of the virtualization or cloud technology present, CloudBolt C2 makes compute resources available to users. This is regardless of what the underlying virtualization technology is, where the resources are located, and increasingly, without concern of what that underlying hardware architecture is.

A commoditized compute layer is interesting, but when coupled with end-user self-service, an IT organization has the ability to introduce a tremendous amount of IT agility into the organization.

Give us a call and let’s chat about where your organization is along the path of providing automated self-service infrastructure, applications, and services to your users. We’ll show you how CloudBolt C2 can revolutionize how you look at compute and manage your resources, wherever they are located.

When I first started at Red Hat, I was a consultant who helped customers deploy a relatively wide set of technologies. A common delivery that we performed frequently was to install and configure the Red Hat Network Satellite Server, which did a phenomenal job of deploying and managing its namesake: Red Hat Enterprise Linux. Managing resources is fundamental to operations in a data center, and within a short time, a new breed of management tools started to materialize. These tools promised—and many delivered—one tool with a single-pane-of-glass actionable management of every server resource in a business datacenter, as long as you only tried to use it for the products those tools managed, that is.

The technologist in me was instantly skeptical of single tool products. As I saw it, the problem was more nuanced than “one tool to rule them all,” because most IT shops had more than just a single platform in play. Red Hat Network Satellite server could do things to and with RHEL systems that these other tools couldn’t touch, but it couldn’t do anything on Windows. In any case, why would you want that? You probably had Microsoft System Center to handle your Windows. In fact, most major enterprise platforms have a powerful management tool built alongside it, and also have the ability to control even the smallest configuration. How can a “we-do-everything tool” ever hope to match the power already built into these products for management and configuration?

It’s no different with cloud management platforms (CMP) - they run into the same walls, and don’t have the ability to talk to anything except their own product line. In order for a CMP to qualify as a true “one tool” management product, it has to talk to everything in the datacenter across physical and virtual platforms and cloud frameworks, and help you make use what you’ve already invested in, or it is just another tool that adds weight and costs to a datacenter. And, a “one tool” product shouldn’t require the replacement of expensive technologies or require a significant investment in time and money to install, use and maintain, either.

I would put my skepticism to rest if there was a tool that could give you situational awareness of your entire IT environment while still being able to use the deeper functionality of the native management utility in a manner that leverages rather than replaces your existing tools. This means “one tool” that can identify what is in use, talk to it, allow for full utilization of its capabilities and, perhaps even as icing on the cake, provide it to end-users. Furthermore, the approach must salvage the significant investment in acquisition, implementation, and training you’ve made in those other tools without ripping or replacing anything. Why should a company have to start over, or spend a huge amount of money to buy new stuff so they can use what they already own?

Do-it-all technologies may be very good at certain tasks, but most will fall down when it comes creating a resource management tool that works across the entirety of the resource pool and cloud frameworks, uses existing assets and doesn’t require any significant amount of time or money to implement. At CloudBolt, we’ve focused all of our efforts on a full-on solution for the problems virtualized environments face with a product that can evolve with a company as it makes changes in IT, even as it solves the challenges of right now across multiple platforms and cloud frameworks. Our development team, under the leadership of our CTO Bernard Sanders, and lead product architect Auggy Da Rocha, struck out to create a “one tool” resource management product that can truly rule them all by solving all of those problems, and making maximum use of the capabilities of existing IT as it deploys a private cloud with hybrid cloud functionality. A huge part of my job here is to make sure our customers are getting solutions that provide them with full enterprise situational awareness as well as interoperability with existing management tools. CloudBolt C2 is one tool to rule them all, and it can truly revolutionize how organizations work with, and use their IT.

An affordable tool that builds on top of what you’re already doing, C2 makes what you’ve got visible and presents it as cloud, so your IT shop gains the ability to unify management across a wide variety of technologies in a way which allows for the easy presentation of any IT resource to end users. Because those users are fully abstracted from the underlying technology, you’re suddenly able to choose and configure the best underlying technology combination possible. Not only do you gain agility in serving end users, you also gain flexibility in your choice of technology, and that turns into the ability to drive down costs on things like VM sprawl. Plus, it decreases possible attack vectors.

By leveraging the existing technologies already in your environment, CloudBolt C2 allows IT shops to realize the full value and potential of existing management and virtualization tools, and gives higher ups a much clearer, fully-transparent view into cross-environment utilization in ways that were absolutely impossible before. I could go on, but you get the idea. In short, using C2 as one tool to rule them all gives you the ability to unlock the true power of your entire IT environment in ways that will save you time, money, and ensure that you leave your end users smiling.

There’s a new-ish term that I’ve been hearing a lot of lately:  Cloudwashing.  Have a product that has nothing to do with Cloud?  Need to make it sound fresh?  Just say it enables Cloud!  I’ll take this a step further, though.  There are a lot of vendors out there that are talking about cloud, but in my opinion, a great many of them are really using it as a verb:  

• Cloud the issue
• Cloud the truth
• Cloud the judgment
• Cloud a decision

Here’s an interesting challenge—the next time you’re talking with a vendor about cloud, why not ask them for their definition of just what cloud is?  Any vendor that can’t—or won’t—answer that question is likely hiding something. 

The reality is that while there may be an actual definition for the term, each organization’s perspective does allow some flexibility on what it means to really be “in the cloud.”

Here at CloudBolt, the formula is pretty simple.  For years we’ve see vendors tout that their ability to enable private cloud in your environment.  The truth is that very few of those pricey technologies really accomplished that.  Why? Because those technologies did nothing to make internal resources more consumable.  If you have technology that your end users cannot directly request and consume at some level, with accountability, you may have great virtualization, but you don’t have a real cloud.

Our path is to make the resources visible, make the resources consumable, apply a generous helping of accountability and reporting, and start really recognizing the value offered by driving out costs from your environment.  When it comes to IT resources, it feels like vendors forget the S in IaaS.  Without the service, you just have Infrastructure.  And that's no different than how this has been done for decades.

In the recent past, I worked at a company where our developers had access to our main production AWS account.  

This approach had several benefits:

• Admin team saved considerable provisioning time
• Developers got their resources quickly
• DevOps could test things on-the-fly with very little overhead
• The company saved considerable capital expense by avoiding purchase of spare testing hardware.

But it also had some pretty significant disadvantages:

• The DevOps team didn't routinely decommission or stop provisioned AWS instances leading to VM Sprawl
• Costs were not predictable

To get around these issues, I ended up implementing policy which required certain instances be tagged to track and account for how they were being used. The problem with approaching the issue of usage like this is that it was difficult to scan through 100 plus EC2 systems to determine at-a-glance if it was still needed. Plus, the business still racked up a significant amount of spending for compute with less than clear visibility as the continuing need. 

On the plus side, AWS and other IaaS/PaaS public cloud providers provide opportunities to add new flexible capacity to your environment for everything from testing to running actual production instances of software. Similarly, presenting your internal datacenter IT as IaaS can deliver benefits to the organization but at the same time that approach is also rife with the same issues (ownership, usage and identifying resources for retirement once they are no longer needed). In Private Cloud, we cut out the middle man and allowed the developers to directly provision instances internally, but we are were still faced with the same issues of who owned what, and for what purpose any one particular VM was needed. Fundamentally, that’s a downside of any good IaaS environment. The easier you make it for users to get resources, the more vigilant you must be in tracking the origins and use of each of those VMs.  After all, your internal resources have real cost, and wasting money on unneeded hardware purchases, power, or cooling doesn’t benefit the organization.

Tracking and accountability is a core issue that we are keenly focused on here at CloudBolt. Keeping tight control over VM sprawl is a key CloudBolt C2 feature that not only helps keep usage in check, it helps makes use of everything you have in your IT war chest to its maximum capacity no matter where it sits.