CloudBolt Software Logo

CloudBolt Blog

On Cloud Management Platforms and Interchangeable Parts

Posted by Bernard Sanders

3/11/16 7:37 AM

"A little piece of advice. You see an Agent, you do what we do. Run. You run your a** off."
Cypher, The Matrix

If you are evaluating Cloud Management Platforms (CMPs), make sure to consider whether the solution requires an agent on the VMs it manages.  This is important because your CMP should provide visibility and manageability across all servers, not just the ones it built itself.  CMPs that require an agent for full management greatly inhibit your ability to on-board previously-existing (aka “brownfield”) servers.  Consider the challenge of getting root/Administrator access to all VMs across all environments and installing software on them.  Also, test what happens when people provision VMs outside of the CMP by going straight to vCenter, AWS, etc.  Will the tool automatically discover and manage them, or will an administrator need to manually install agents first?  Also consider which OS versions the agent is supported on, how quickly new agent versions are released to support new OS versions, and what the upgrade process is for existing agents.
Agent.png

Inclusion of an agent makes a CMP more like a monitoring or configuration management system.  It blurs an important line between monitoring and operations.  Agent installation and inter-process communications also raise legitimate security concerns.  By contrast, a product designed as a manager-of-managers gets all the information it needs through the APIs of each virtualization system, public cloud, and configuration manager.   The CMP automatically discovers and manages VMs built with other tools in exactly the same way as servers it builds.  All systems are equal.

This was our design philosophy for CloudBolt.  We recognized that enterprise datacenters have a plethora of pre-existing interfaces and tools.  Rather than supplanting or requiring changes to existing operational standards, we complement and integrate with them.  Our approach enables IT architects to choose the best set of tools for each specific function.

I would go so far as to say that if a product uses agents, it is not a CMP.  A management ecosystem should be comprised of interchangeable parts and components that respect their boundaries, and integrate with each other over published, documented APIs.  Administrators should be able to swap out any particular monitoring (or backup, virtualization, or even CMP) solution for another as requirements change or better versions come along, all without affecting other functional areas.  This is central to CloudBolt's approach, and it’s one of the reasons it is consistently ranked highest amongst CMPs.

Download CloudBoltand see for yourself.

Read More

Topics: CMP, Cloud Management, Implementation, CloudBolt

The Cloud Management User Interface Last Mile

Posted by Justin Nemmers

8/19/13 8:26 AM

Cloud Manager User interfaces are difficult to create.  Not only does every vendor out there have their own ideas, but the sheer number of UI toolkits available mean that even if two vendors have similar ideas, the end result will look totally different based on the underlying technology.

UI elements diverse use

This issue only exacerbated when you start to look at the various management tools in use by the typical IT management environment.  An IT admin will often interface with half a dozen systems on a daily basis, each with its own UI, its own way of doing things, and its own workflows that must be separately understood.  It’s complicated.  And it just makes supporting a persnickety pile of users that much more difficult.

The user interface last mile is the point at which a cloud manager’s user interface effectively abstracts the various underlying technologies it manages.  The broader the supported underlying technologies are, the better the UI needs to be at presenting those capabilities in a sane, predictable manner.  Connecting with numerous different types of underlying technologies only makes the problem more difficult.

Creating a User Interface is hard work.  Creating a good User Interface requires even more significant effort, training, and understanding of how the design of the interface relates to the problem it’s trying to solve.  Form follows function, but in order to effectively create something, one must really understand the function.

Different designers, different perspective

Understanding the function alone isn’t really enough, though.  Different UI designers might perceive the functionality in different ways, creating significant difficulties for how the UI is implemented.  For starters, the designer’s level of experience with the target environment is an issue.  Terminology is another area that can cause difficulty.  Different designers may have a different understanding of what the commonly accepted terminology is- for instance, the difference between software licenses being “used” vs. “deployed” is pretty important, as they’re two different things.

Where the designer’s primary experience originates from also makes a difference in the UI that they will produce.  Without the credibility and experience in the data center, the resulting UI can be confusing. 

Vendor Bias

An infrastructure or other large software vendor might very well use the UI as a tool to bias the end user experience toward a specific technology or solution.  For instance, in a cloud manager, a large whole-suite vendor is likely to ensure that the cloud manager integrates better, and has better UI functionality for other technologies in their stack like virtualization, orchestration, and configuration management, but chose not to put the same effort into integration with 3rd party vendor products.  This approach causes two problems:

  • Reduces customer choice
  • Makes it difficult to add additional technologies as needed

This bias is an important thing to take into account when making a technology decision.  Vendor X may have a good product, but when it claims to be unbiased, it’s probably not true.

Disparate technology classes

In order for a UI to be effective, it’s got to do a good job of componentizing and standardizing display items and values in a manner so that it can more fully abstract the underlying complexity from end users, who generally don’t care that Applications in Puppet are called “Classes”, “Recipes” in Chef, and then just “Applications” in HP Server Automation.  A well-written UI will make the right decision, and present users and IT administrators with something that makes sense, irrespective of what the underlying technology might call it.  This also helps with extensibility, as IT Administrators can implement new technologies without the worry that they’ll have to fight with end users about changing the nomenclature in an environment.

Different use cases

Both IT administrators and end users are target users of cloud managers.  Each of these user types, however, has a different understanding of what’s happening.  A good UI will effectively abstract the underpinnings from users, but perhaps make those same underlying components visible to administrators. 

Different users can also have different understanding levels.  A UI cannot be so strict as to mandate each and every user sees the same thing at all times.  Nearly every UI element needs to be customizable to effectively mold itself to match the user’s understanding. 

A cloud manager UI also needs to strike a balance between the potential for deeper-level administrative tasks (such as managing VM migration between hosts, or creating a new application in a CM tool) and general usability.  As cloud managers are just layers above the existing tools, there are things that will always make more sense to use the underlying tool to do.  From an administrative point-of-view, not every possible option and capability can be exposed.  This is important because while a good cloud manager UI will never be intended to accomplish every little underlying management capability, there needs to be a strong balance between breadth of capability and ease-of-use.  If the balance is off in either direction, administrators and users alike will be frustrated with the interface. 

The difficulties of open source UIs

Many open source tools come with UIs these days, but they end up falling into the categories above.  Project teams tasked with building and maintaining these projects are often employed by different companies.  Unification doesn’t happen too frequently in these projects.  Even two products from the same company can have wildly different look and feel based on who originally developed it.

This leads to a natural conflict of “your UI or mine”.  There ends up being inherent conflict between competing UIs, often leaving customers to choose between UIs depending on what task needs to be accomplished.  This, of course, somewhat defeats the purpose, as there is no true single pane of glass management. 

The Last Mile

All of these points come together to make a case for a tool that has both a powerful and flexible UI.  A UI in this case needs to do a few things to be useful:

  • Integrate with a wide range of technologies
  • Independently integrate with each technology class
  • Provide a mechanism to centrally access common tasks
  • Intuitively offer appropriate choices to various users

These aren’t trivial tasks to accomplish.  Getting them right takes significant skills, expertise, and credibility in the data center to get the use cases correct.

In short, it’s not for the faint-of-heart, and not everyone can do it.  Have a look at CloudBolt C2 to see how the C2 User Interface is the most intuitive and powerful interface available in a cloud manager.

Read More

Topics: IT Challenges, Cloud Manager, Implementation

Build private cloud on top of virtualized network

Posted by Justin Nemmers

3/18/13 11:40 AM

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.

virtualized networking separates logical from physical
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.

Read More

Topics: Management, Software Defined Network, Network Virtualization, Implementation, AWS

Next-Generation IT and Greenfield Cloud Infrastructure

Posted by Justin Nemmers

3/12/13 3:06 PM

The problem is consistent. Consistently difficult, that is. As an IT manager, how does one implement new technology in an otherwise running and static environment?  New technology decisions are not just difficult, but the range of questions that rise from thinking about implementation plans can seem daunting. 

Whether you’re talking about switching hardware vendors, or implementing something relatively new like network virtualization, how it’s implemented in your environment will often be more critical to the project’s success than the validity of the technology itself. 

greenfield IT is great IT

Ideally, every environment would be brand new.  How many times have you asked yourself “Wouldn’t it be great if I could just scrap my current infrastructure and start over?”  Fundamentally, greenfield implementations like this are a good route to go for a number of reasons:

  • They allow you to select the best-of-breed and most effective technology to solve the problem at hand
  • You get the valuable opportunity to think about how the technology stack will scale in the future
  • They allow for rapid change while the environment is being built
  • Because there are few barriers, you have the opportunity to investigate other new and upcoming technologies, and you will have time to experiment 

A Cloud Manager provides significant value here.  Using one to unify the management of a lab environment allows the rapid integration of new technologies—technologies that your IT teams need to learn and gain experience with before implementing in the production environment.  Using a Cloud Manager eases the introduction of these technologies, and unified the management interface to make administration more predictable. These tools together help to mold processes and the IT organization into a more agile group.

In my mind, one of the core issues here is that too few IT teams are able to think outside of the box when it comes to implementing new tech. If greenfield implementations are easier than shoehorning new tech into your existing stack, why not give it a shot? Starting with a small base of gear and intelligently growing the installation over time is a great way to migrate capacity. I have an entire different blog post on how to migrate via attrition that is coming soon.  In the meantime, go ahead and identify a few pieces of hardware, install your preferred virtualization tool, download CloudBolt C2, and start piecing together your future architecture.  Once C2 is installed, you’ll be able to quickly layer in additional technologies like Data Center Automation, Network Virtualization, and even other virtualization or Public Cloud resources seamlessly.  

Happy integrating!

Read More

Topics: Virtualization, Development, Hardware, Cloud Manager, Implementation, New Technology, Challenges, Vendors