CloudBolt Blog

Listen to the large enterprise IT vendors for long enough, and you will hear that ‘best of breed’ solutions are a thing of the past. ‘The time when customers requiring a solution to a specific IT need should go out and seek the most capable tool and implement it in their environment has come and gone”, they say. These myopic and self-centered vendors will rail on and on about how;  “yes there was a time when best of breed IT solutions were a great path forward, but that was before ‘we’ insert your favorite large monolithic software vendor here bought up all the best solutions and marketed them as a family of products already pre-integrated for our customers.”  They will go on to say that “IT is so complicated and confusing that our customers should just buy all our products (and only our products) and all their problems will be solved!”

A solution suite has a lot of drag-along. It might seem simple, at first glance, but reality sets in quickly.

These same large vendors talk behind their customer’s backs about gaining a bigger share of the customer’s wallet—as if all of the more money they extract from their customers imparts more benefit the customer will accrue. (There is certainly benefit to the vendor when they have a stranglehold on the customer’s IT budget, but certainly much the opposite for the customer.) These vendors’ strategies are clearly to ignore the reality of the marketplace and where true innovation is happening, and to use any means necessary to convince customers that IT is easy if these customers “standardize” on their particular solution suite. “Don’t consider products from any other vendors  (large or small)”, they will preach. “Your IT environment will only support your business needs by sending all of your IT budget my way and exclusively locking yourselves in to our products.”

The Reality Versus the Hot Air

The reality of today’s dynamic markets is that standardization on a single vendor suite as being proposed by the large vendors is an impossibility for the modern enterprise.

Vendors are quick to tell you that unifying environments is as easy as selecting all of their tools.  Tired of the hot air?

As companies merge and consolidate more rapidly, it is a certainty that the resulting entities will have a varied range of hardware and software solutions performing similar functions. Wholesale replacement of this technology to achieve homogeneity would be constant and costly while offering no real business benefit.

At the same time, the pace of technology change is rapid and uneven. An example is the recent innovation around network virtualization. The advent of network virtualization and Software Defined Networking (SDN) enables enterprises to examine how they might take advantage of this emerging technology to revolutionize data center architectures, not to mention ease the move to cloud-based technologies. Given that SDN technology is in its early stages, it is far from clear what implementation or vendor will emerge the leader in the space. Despite VMWare’s VMWorld 2013 announcement at about their NSX product (the bits that used to be Nicira), to date, nearly all of the larger vendors haven’t even developed a strategy much less a realistic product offering in this critical technical segment.

Independent Vendor Solutions and the Best of Breed Advantage

If standardization on a single vendor, and surrender of your IT budget is a non-starter, what does a successful approach look like, then?

The IT market today, perhaps more than ever before, presents a great range of best of breed technologies to select from. The fact is that most large vendors are working so hard to obscure this point. And they’re succeeding. The prospect of Cloud has the ability to give the choice and power back to the customer.

Cloud is much more than a way to provision and manage IT resources. The correct cloud manager enables enterprises to unify a heterogeneous environment (Hardware, Software private cloud and public cloud) to take advantage of best of breed solutions and increase the agility of the IT department to incorporate new and disruptive solutions. An independent cloud management tool can’t afford to be limited (or biased) in its support for internally deployed IT technologies (be they hardware  or software) or in its support for various private or public cloud resources.

Why does vendor independence matter?  Because an independent cloud platform is not beholden to making one IT technology or tool (or suite of tools) look or function better than any other. A truly independent and advanced cloud platform takes it cue from the market and supports those underlying tools and technologies demanded by the market and it’s customers.

In light of these requirements, examine the existing cloud management options, and you will find an independent vendor will provide significant advantage to your enterprise. Adoption of the proper independent solution makes best of breed technology easy to implement in your environment and provides a degree of agility and efficiency superior to standardizing on any single vendor.

Implement an independent cloud manager, and regain the power to chose the best of breed solution for each of your enterprise IT problems.

Want to learn more about what CloudBolt can do in your IT environment, regardless of your underlying technology choices or platform selection?  We'd love to show you.

Danelle Au wrote an exellent article for SecurityWeek that is essentially a case study for why organizations need CloudBolt C2 in their environments. She talks about how, at scale, the only way to achieve the needed environment security is with significant automation, making the key point that “automation and orchestration is no longer a ‘nice to have.’” 

Yep. It’s a must. A requirement.

In her description of a manual provisioning process, Danelle accurately points out that there are numerous variables that need to be accounted for throughout the process, and that one-off choices, combined with human error can often open up organizations to broader security issues.

In order to achieve the “trinity” (as Danelle calls it) of “virtualization, networking and security”, a tool must have domain knowledge of each of the separate toolsets that control those aspects. Tools like vCenter, RHEV, or Xen handle Virtualization Management (just to name a few). Each of those tools also has some level of their own networking administration and management, but a customer might also be looking to implement Software Defined Networking that’s totally separate from the virtualization provider. So now couple Virtualization Management with a tool such as Nicira, or perhaps Big Switch Networks, and the picture only grows more complicated.

Security, the last pillar of this trinity, is really the most difficult, but absolutely the one that benefits not just from automation, but also strict permissions on who can deploy what to where on what network. Automation might be able to grasp the “deploy a VM onto this network when I press this button” concept, but you need something quite a bit smarter when you take a deeper look at the security impacts of not just applications, but which systems they can be deployed on, in which environments.

So how do you expect admins to juggle this, with 1,000 different templates covering all the permutations of application installs in the virt manager? It’s probably not sustainable, even with a well-automated environment.

What is an admin to do? Well, for starters, admins use Data Center automation/Configuration Management tools like Puppet, Chef, HP Server Automation, GroundWorks, and AnsibleWorks to name a few. But in order to fully satisfy the security requirement, those applications and tools must also be fully incorporated into the automation environment. And then governed, to make sure that the production version of application X (which potentially has access to production data) can never be deployed by a QA admin into the test environment. An effective automation tool must be able to natively integrate with the CM as well, otherwise

And Denelle’s point of view was largely from the private cloud. What happens when it’s private cloudS, not cloud? And let’s not forget about AWS and their compatriots. Adding multiple destinations and target environments can drastically increase the complexity.

I do, however, have one glaringly huge issue with one of her comments: “It may not be sexy…” I happen to think that “The ability to translate complex business and organization goals” is more than a little sexy. It is IT nirvana.

Let’s face it. Networks are a pain to implement, maintain, and debug. Additionally, they’re often viewed as fragile enough that many teams generally wish to avoid routinely poking at them by messing with configurations or frequently creating/deleting VLANs.

Implementing a flexible and scalable private cloud environment on an inflexible network will only serve to reduce the flexibility and scalability of a private cloud environment that needs to grow.  In addition, ongoing management of these environments can quickly become difficult when administrators don’t have the ability to easily restrict network access by group, or have the ability to rapidly create new stand-alone networks for a specific application, group, or requirement.

Separate the logical from the phisical network.  Network virtualization does for networks what server virtualziation did for servers. You can't talk virtualization management without also talking about network virtualization management.

Enter network virtualization!  When implemented in your environment, and made consumable by a Cloud Manager, network virtualization suddenly breaks the network stack wide open.  In fact, I’d argue that until you virtualize the network, even private cloud alone is only partly useful.  Why?  Well, for several reasons:

• Private clouds alone are limited by their ability to meet capacity demands. 
• Eventually, that private cloud will run out of data center space, or will need to otherwise expand out of it’s shell. 
• Whether your private cloud is fully on-prem, or you’re using a virtual private cloud model from someone like Amazon Web Services (AWS), the inflexibility of unifying that networking layer can be a difficult hurdle to surmount. 

Let’s expand on this AWS example.  Amazon offers a Virtual Private Cloud (VPC) that is essentially a private cloud hosted in the public cloud. Confused yet?  Don’t be. AWS uses advanced network and security parameters to effectively cordon off your cloud-based VMs from other tenants, allowing for secure communication and private networking in your hosted private cloud. They do this by manipulating the network layers in the hypervisors. AWS’ use of networking, although advanced, has its limitations, though. For instance, although VPCs can span availability zones, separate regions may require separate VPC definitions, leaving the networking integration to the user. In those cases, your local facility will have to implement it’s own routes to properly send traffic to the correct VPC. Although you can certainly work through those limitations, a hosted private cloud like that is wholly dependent on AWS. 

It doesn’t get any easier when your private cloud is completely on-prem. Be it demand growth, or a shift in requirements or priorities, networking is likely to be one of the significant bottlenecks in the growth and success of your private cloud.  

This is why a technology like network virtualization is so important. Implementing network virtualization in a private cloud environment (be it greenfield, or layered into an existing brownfield environment) allows you to approach new requirements with flexibility in mind and little concern over the networking infrastructure. Just make sure that your underlying network has the Layer 2 capacity for required traffic, and then start to build your environment above that.

In order to attain the flexibility of network virtualization on top of your private cloud, you need effective management. This goes beyond creating a handful of networks and handing them over to users.  Understanding what networks are required by which users and groups, and then ensuring that access is properly controlled is more than critical: it’s a requirement that must be met, or the network will remain a significant impedance to growth. Especially when it is time to expand the reach of your private cloud—whether that be adding capacity, layering in additional technologies, or perhaps looking to securely and safely make use of public cloud resources (congrats, you now have a hybrid cloud!)—Management of the entire stack is an imperative part of the solution. Deploy applications, resources, and networks all in one pass, no matter the environment. That’s the promise of network virtualization. CloudBolt makes it usable.

In an enterprise organization without virtualization technology, the creation and configuration of new networks requires a network engineering team to manually configure network devices. The process is often difficult and arduous as a lengthy troubleshooting process ensues between network engineers and the server team when the network does not function as expected.  The advent of server virtualization has added the virtualization administrator to this process to make the new network available within the hypervisor. The process is sufficiently cumbersome enough that IT administrators aggressively avoid the activity, and instead reuse and overload existing networks to the detriment of the end users of IT. 

Avoiding the creation of new networks impacts development and quality assurance more adversely than production as it causes pre-production environments to drift from production. That creates unexpected environmental problems when applications are promoted to production (e.g., hours after the site goes down, “ah, it doesn’t work when service X is not on the same subnet!”).

The level of difficulty of a technical procedure should not dictate the processes undertaken. Technology should act as a catalyst of change, rather than an inhibitor.  VMware network virtualization (The bits they purchased from Nicira, which was formerly NVP, or Network Virtualization Platform) moves the state of technology forward by abstracting the network from the underlying hardware, and eliminates dependency on high-end networking hardware and specialists trained in the configuration of proprietary hardware. 

This advancement provides an opportunity and a challenge: 

• The opportunity is to move the task of configuring networking closer to the groups that need the networking. 
• The challenge is to expose this functionality in a way that is simple enough that the average consumer of IT can take advantage of it. 

CloudBolt C2 solves this challenge for an array of technology, including network virtualization, and is currently the only CMP with network virtualization management capabilities.

Combined with network virtualization, CloudBolt C2 provides an exceedingly simple web interface that IT consumers can use to request new virtual networks as well as servers.  C2 guides these requests through an approval process and then takes action on them, taking care of communication with more complex back-end systems like VMware network virtualization, server virtualization, and configuration management systems. The level of integration between C2 and network virtualization is unequaled in the industry. The CloudBolt C2 Enterprise edition enables features such as adding fine-grained permission controls around the creation and deletion of virtual networks, granting end users the ability to save a composite network-server order as an “application” for rapid re-deployment of complex services, and gathering network utilization data from Nicira to incorporate into C2’s cost-tracking system.

The end result is that users can easily create entire labs and data center environments in minutes with just a few graphically-driven choices.  Not only does this accelerate and automate existing tasks facing IT organization, it also enables them to work in ways that were heretofore impractical or impossible, granting end users an unsurpassed level of self-sufficiency.