IT exists to serve the business. The business is made up of users, with requirements, that need IT resources in a timely manner. Back when I was an admin with the Government, we used to joke with among the IT staff that our lives would be much easier without users. Funny thing is, I’ve found this to be a pretty common sentiment across IT organizations. 

The conflict between IT Organizations and the businesses they are tasked with supporting has existed since non-technical business people started using IT. The IT enterprise is a fundamentally complicated environment that takes both specific skills to craft and maintain. The language of Enterprise IT is radically different than that of the business. IT speaks about servers, resources, software licenses, infrastructure, technology, and capacity. The Business uses language like budgets, margins, time-to-market, cost accountability, end user experience, responsiveness, compliance, advantage, reporting and agility.

Because of these conflicting concerns, business often doesn’t appreciate the complexity of a seemingly simple request such as:

• “I need more resources”, or
• “What was the cost for user’s project?” Or,
• “We need X capability in our product.”

IT and business not speaking the same language results in obtuse responses:

• “How many resources, and of what type, to be used for what purpose, and where?”
• “Give us specifics about what the project was, and we’ll try to get the information.”
• “What application do you want us to use?”

This back-and forth doesn’t produce results as needed, and is part of the reason IT and business frequently struggle when communicating about requirements, and why the IT Administrators—the ones tasked with keeping the enterprise IT environment moving in the right direction—end up with a negative view of each other. 

Current Tools are Not the Answer

By necessity, organizations have adopted various tools and technologies intended to help narrow this communication gap. IT teams employ all sorts of overlapping, complicated tools in their attempts to generate answers to business’ leadership’s difficult questions. 

IT organizations’ attempts to answer these questions include single-purpose tools like chargeback managers, various IT and business intelligence tools, configurations managers, software license management tools, a CMDB and so on. The problem is that none of these tools talk with one another, and many have overlapping capabilities. For instance, to answer a question regarding how many copies of a license are in use, where should an IT administrator look?  The configuration manager might not tell you that a system has been decommissioned. The License Manager might not capture multiple copies of the same license. Neither tool does a good job of assigning ownership. 

So to answer difficult business questions, and even with complicated and feature-rich tools, IT Organizations are inevitably left with Excel spreadsheets trying to track interrupt-driven requests with an error prone and largely manual process. It’s unsustainable! 

A Robust Cloud Manager Can Help Answer the Questions

Reconciling these issues does not have to be complicated or difficult, though. Using a complete cloud manager to gather real-time information from underlying tools such as virtualization and configuration management can help eliminate the spreadsheet jockeying that has to happen, and essentially eliminates the time needed to gather the needed data. Next, because a Next Generation Cloud Manager abstracts the underlying technology, IT Organizations are able to layer in additional tools to help complete the picture for both end users and IT alike.

Even for Organizations that have relatively mature IT operations and processes, the difficulties present in collecting relevant data can be notoriously difficult, and even in the best environments, end users are rarely treated to such transparency in metrics like consumption, cost, an utilization. If you are a program manager, it would be nice to have real-time access to that information in order to chart your own team’s progress. 

Actionable Data is the Answer

Consider your personal finances. Without a tool like Quicken or Mint (or any of the other similar tools), keeping track of every little in or outflow of cash would be a nightmare. Between iTunes purchases, Netflix subscriptions, cable television, Internet, car payments, restaurants bills, groceries, cell phones, insurance and bar tabs, quickly answering questions with actionable data becomes difficult:

• How much did I spend on entertainment last month?
• What is my average spending on utilities over the past six months?
• Which vehicle is costing me the most for gas?

The biggest difference between how IT and Business communicate is what data each views as actionable. Closing that gap with a tool that allows IT to provide Business with the information they need to make effective decisions will lessen the conflict and ease tensions between the two parties in any organization. 

The Steps to Helping IT Talk to Business

Given that current tools do a poor job of providing real business answers, how does an IT organization begin to implement the right tools and processes to effectively provide the needed information? 

1) Identify the information gaps.
What business questions does IT lack any real data on? These needs can range from information about deployed licenses, location and configuration of systems, or software supporting a given application, to what groups are using which resources. The types of information gaps present will dictate capability requirements of selected technology (or technologies). 

2) Embrace automation and IT self-service.
In the past, the idea of giving users access to self-service IT struck fear into the hearts of IT Administrators. Why? Being in constant control of their environments is part of the job description and letting users actually touch systems can radically affect system quality and uptime. When self-service IT is coupled with automation, and the automation platform can ensure the appropriate policies and procedures are followed, IT Administrators can rest assured that the Self-Service IT process is fully governed, and thus, they’re still in full control and quality is protected.

3) Make sound technology decisions.
When choosing technologies to fill the information gaps, look outside of your core vendors.

Going with the same vendor suite that provided your virtualization system might seem like a good idea, but promoting vendor lock-in at this level can be very costly for an IT organization, and limits choice and capability both initially and downstream.

Choosing a Cloud Manager that will play well with your existing and varied environments is also critical. IT Administrators must have the ability to make continued use of underlying management tools if needed. Discovery of virtual and cloud resources are critical: a Cloud Manager needs to overlay its tracking and measurements on top of existing environments.

Heterogeneity will be unavoidable, but heterogeneity itself is not an issue with the right Cloud Manager.

4) Ditch the Spreadsheets.
Fact: IT Administrators hate using spreadsheets to track critical aspects of the environments they manage. They’ll be relieved to know that there’s something else to keep track of these metrics, and in real-time at that!

5) Create and Schedule Reports
Using the requirements from step 1, use the Cloud Manager to create and automate reports that pull information from the various needed technology classes. For instance, reporting on a specific project’s IT cost would consolidate information on that team’s usage from your virtualization, configuration management, license management, and public cloud tools. And, of course, make sure that the Cloud Manager does the math for you.

IT teams that work to build understanding about the types of questions Business wants answered will find more success. Select the right technology, and focus on delivering the types of actionable information the Business needs. Tweak it, refine it, and remember that it’ll change as the needs of the business shift. With the above points, however, you’ll be on the path to success.

Learn more about how CloudBolt C2 helps solve this problem.

Customers are speaking, and we’re listening. C2 v4.1 contains a host of customer-suggested enhancements that are designed to enhance the capability and usability of C2’s management of a wide variety of IT resources.

Virtual Private Clouds and Amazon Web Services

In C2 4.1, the AWS connector now has the ability to detect, manage, and deploy systems into VPCs. C2 Environments backended by the AWS connector will now discover VPCs, VPC subnets, and other VPC-specific options such as security groups. C2 will also now auto-create C2 Environments for each selected VPC/Region, which nearly eliminates additional setup and configurations required.

VMware Integration Improvements

As we showed with our latest AWS updates, we’re always on the lookout for additional features to add to existing connectors. In this release, we’ve improved our VMware integration by adding more in-depth automatic C2 Environment creation for each VMware-hosted cluster present in vCenter. C2 will also now auto-discover any resource pool or datastore options as configured in vCenter, and will automatically create and map those options to C2 fields.

Re-Importing and Updating

Once AWS and VMware environments are created, C2 can now auto-detect and re-import changes to the underlying configuration of those environments. This includes things like VMware datastores, resource pools, and AWS security groups.

The Docs

We now include the full CloudBolt C2 product documentation as part of the install. The bottom of every page contains a link to access the embedded product documentation.

Speeds and Feeds

Despite our class-leading interface—recognized as the most intuitive available in a Cloud Manager, we’re always working to improve the user experience and keep it at the top. In C2 4.1, we’ve worked to get the rust out of many parts of the interface—so it will be faster than ever—especially on the server list page for environments that have thousands of servers. We’ve also polished the interface in several areas to help with usability. 

Additional Improvements

We already talk to Puppet Configuration Management, and now we speak that language even better with a updated Puppet connector in C2 4.1. 

We’re the only Cloud manager that can use itself to test your critical provisioning workflows. Configuring the Cloud Supply Chain Validator (CSCV) capability in C2 4.1 is now fully managed in the C2 UI, rather than requiring a configuration file modification.

For Red Hat Enterprise Virtualization Manager (RHEV-M), C2 will now automatically import the RHEV-M API certificate.

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.

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 3^rd 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.

The next-generation Cloud Manager keeps innovating in numerous ways that help make IT organizations run better and more efficiently.  

Each time the product team goes to the whiteboard to talk about the C2 roadmap, we rely on our decades of combined data center experience.  We recall the hundreds of conversations we’ve had with current customers.  We want you to know that we’ve listened.  The result is a new major release of CloudBolt C2 that brings connectivity and resiliency of our customers’ Cloud Resources to unparalleled levels.   Some of the key new features in C2 4.0 are: 

Cloud Supply Chain Verification (CSCV)

We’re proud to announce the availability of the CSCV system.  Sounds intimidating, but we’re certain you’ll need it.  As the numbers of IT environments, virtualization platforms, DCA tools, and Orchestration tools increase, so does the overall complexity of running and provisioning systems into any one environment.  C2 does a great job of orchestrating and automating this entire process, but what happens when an administrator changes a password in vCenter?  Or a developer unexpectedly updates a workflow in an external orchestration tool?  Automated provisioning will break. 

The Cloud Supply Chain Validator. Ensure that all aspects of your automated environment are operational.

The purpose of CSCV is to ensure that all needed actions in any environment configured in C2 both executes, and returns the expected result.  CSCV will automatically run through any number of tests, and immediately notify the CloudBolt Administrators in the event of a failure. 

We don’t just allow for CSCV to test provisioning, though.  CSCV can test the end-to-end process of de-commissioning, power on/off, and installing/removing applications.

In short, C2 will tell you when something breaks in the end-to-end provisioning process for any environment C2 is configured to manage.  It does this across virtualization and public/private cloud platforms as well as Data Center Automation tools, Configuration Management tools, and any external Orchestrators (more on that momentarily), and, of course, any orchestration hooks that you have configured in your environment. 

Read more about the CSCV in a blog post here.

Multi-Portal Support

Are you a managed service provider that’s using C2 as a portal for your end users?  With v4.0, we’ve added multi-portal support.  C2 can now be configured to accept connections from multiple URLs.  Your customers or users securely connect to CloudBolt and each URL will represent a different portal, and that can be separately configured with theme colors, and a customer logo.

Many different aspects of the C2 UI can be customized based on the URL used to access the C2 UI.

Service Catalog

While users have always been able to create multi-server orders (that can even include a software defined network or two), C2 did not have a built in service catalog.  We do now.  Administrators can pre-create services, assign group and environment permissions, and make those services available to other C2 users.  A service for CloudBolt C2 is any combination of servers, applications, networks, and environments.  In short, anything that can be ordered in C2 can be made into a service, allowing easy ordering of complicated services and application stacks.

C2 makes it easy to create fully-contained services, and make them availble to your users.

Abstraction Layer 2.0

A key aspect of C2’s architecture is that the abstraction layer allows us to rapidly develop new connectors to additional technologies.  The process of developing a connector is much easier once we have developed a connector class that contains all of the appropriate data model and orchestration components in the C2 internals.  C2 v4.0 contains two important updates to the Abstraction Layer:

• New connector class: External Orchestrators
• Open API for customer-written connectors

The new connector class supports external orchestrators (also known as runbook automation tools).  Once your External Orchestrator is connected into CloudBolt, C2 Administrators will gain the ability to call nearly any contained workflow at multiple points during the provisioning, decommissioning, power status change, and health check processes.  Users with the correct permissions will also be able to see, and execute, specific external workflows from within the server view.

C2 can import and directly execute workflows from HP Operations Orchestration and (soon) other orchestration tools as well.

Today we are shipping C2 v4.0 with a connector for HP Operations Orchestration (HPOO).  Want to connect to another external orchestrator such as VMware vCenter Orchestrator, or Microsoft System Center Orchestrator?  That capability is just a phone call away. 

CloudBolt already has unrivaled flexibility to integrate with external systems and custom systems using Orchestration hooks but sometimes a deeper integration is desired for custom developed configuration management tools or first gen cloud management tools that are being phased out over time.  C2 4.0’s Abstraction layer includes a new open API that allows customers or their services partners to write their own CloudBolt connectors. Ultimately these connectors can even take a path to full support from CloudBolt but regardless CloudBolt can be enhanced to connect to any tool that an environment may dictate.

Orchestration Hooks

Speaking of Orchestration Hooks, C2 v4.0 has an updated Orchestration Hook management UI.  C2 Administrators can completely manage the type and order of Orchestration Hook execution, and also now assign multiple hooks per step.  All from the UI.

The C2 Orchestration Hooks UI uses scripts and workflows to integrate nearly any technology external to C2. 

Connector Updates

We’ve added support for Red Hat Enterprise Virtualization Management (RHEV-M) to the list of currently supported Hypervisors. 

Puppet Configuration Management is now fully supported for Data Center Automation.  Environments with Puppet installations can now use C2 to automate the installation and management of applications in environments.  Users can be presented with a list of available applications, and select the desired ones to be installed.  Of course Puppet-managed applications also get the same License Management, permissioning, and rate metering that C2 provides.

Other Updates

C2 v4.0 now supports hosting the OVA on XenServer. 

We’ve also expanded the LDAP and AD integration, Administrators can now have multiple auth targets per C2 instance, and can support multiple domains in a single AD forest.  Additionally, the synchronization of user data between C2 and the authentication systems is richer, and includes more attributes.

Summary

The capabilities in C2 are both innovative, and also highly accessible.  Most administrators can install C2, and be using its intuitive interface to deploy virtual machines in under 20 minutes.  We’ve focused our efforts on innovating, but with a decided understanding that even the most innovative feature is useless if it takes three months to install and configure, and this is no different in C2 v4.0.

Want to see more?  Request a demonstration today.

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.

Is it Metering, Chargeback, or Showback?

At their core, utility metering (or just “metering”), showback and chargeback of virtualization or Cloud IT resources are the same idea. The difference is that with chargeback, a report is ingested into an invoicing system, and bills are generated for delivery to end-users. Showback cost reporting is chargeback, but without the last step of producing invoices. 

Reporting is at the Core

CloudBolt C2 collects all kinds of information about the environments it manages.  In order to get access to majority of this data, C2 comes embedded with a powerful (and open source) reporting engine—Jasper Reports—that enables administrators to generate and schedule reports on nearly anything of interest in the C2 database. Some examples are:

• “What was the QA team’s usage in dollars, broken out by software and VM resources last month?”
• “How many VMs, by group, have Oracle installed, but have not been turned on in 30 days?”
• “What groups have VMs that have access to network X?”

All of these are relevant questions, which would be very hard to answer if the information was spread across multiple disparate systems. Furthermore, any reporting system needs to actually have data at the appropriate level of granularity.

How C2 Makes it Happen

With that background set, let’s talk for a minute about how this relates to metering and billing. As I said above, granularity is key here. CloudBolt C2 globally assigns allocation costs to several core compute components:

• CPUs (physical and virtual)
• Memory
• Storage

Global Hardware Rate View

Next, C2 lists out *every* OS template that it knows about. This includes templates from every virt platform and cloud provider that C2 is managing.

Global OS Build (Template) Rate Editing

Most other platforms stop here. C2 takes it a step further. For those environments that have some flavor of Data Center Automation (DCA) tool like Puppet, Chef, HP Server Automation (the bits that used to be Opsware), we also allow administrators to globally set the per-application costs. For environments that lack a DCA tool, Administrators can assign the software costs to OS templates, so consumers will still be exposed to the impact of the software stack they have chosen.

Global Application Rate View 

Because there’s a division between the hardware and software costs, Administrators have the ability to report on operating system, application or hardware costs, or any combination of the above, as well as the total cost incurred for each instance. This separation ends up being pretty important when you’re trying to make business decisions related to technology.  Additionally, we can track (and report on) this information no matter where the resource lives, in any environment C2 manages.

The Challenge of Multi-Cloud

Global rates work for environments that average IT costs across all aspects of their enterprise.  That’s a pretty unrealistic world-view, though. As I’ve said before, we have spent time in the data center.  Out of that experience comes the understanding that different environments have different costs not just for hardware, but often for software as well.  

To account for this, CloudBolt C2 administrators have the ability to override any of the above costs on a per-environment basis.  This means that C2 understands that your Production HA VMware-powered and HP SA managed environment can cost more for hardware, applications, and OS templates than your QA environment that uses Xen and older hardware, and is managed by a free installation of Puppet. 

Hardware rate override for an environment named “Seattle Prod DC”

We allow administrators to set per-environment costs for OS Templates, and, of course, Applications.

Application rate override for the Seattle Prod DC environment

Hours, Days, Weeks, or Years?

Not all allocation-based metering environments are created equal.  Does your organization use a metric other than a month?  What about models that rely on smaller increments?  C2 has the built-in ability to globally meter usage in hours, days, weeks, months, or years.  Organizations are free to choose the mechanism that makes the most sense for their Business.  Since C2 keeps the resource status accounting internally, but uses a reporting engine to generate the billing information, the IT organization owns the business decision of how best to account for the Business’ resource usage.  A billing report can be made to include all allocated resources, or just those that were used over the requested reporting interval.  Additionally, and if desired, all reports can be pro-rated based on how long the resource is actually powered on.

C2 can account for allocation by the hour, day, week, month, or year.

Showback Cost to End Users

Showing a user the cost impact of their request is an important step in gaining increased visibility over out-of-control IT costs in an enterprise.  This becomes even more important when an IT organization has implemented a hybrid cloud, as there can be significant additional operational expense from running unneeded or underused instances.  C2’s ability to show users the cost of their ordered resources is an important self-education tool that can effectively drive desired behavior.   End users and Administrators alike can both see the split between hardware and software cost for each instance or service requested.  As users make selections in their ordering window, the total price will automatically adjust based on the users’ selection.  For instance, in the following three diagrams, a user request (and perception) will change pretty rapidly when they see the cost of the database stack they chose.

A LAMP server selection by a member of the Bonds Group in the San Jose QA Lab environment costs $20.70/month. 

A similar request, but selecting the SQL Server stack costs $174.70/month.

Another similar request, but selecting the Oracle/JAVA stack costs $557.20/month.

Once a user selects multiple systems for an order, they will have the chance to review their order before submitting for approval.  As part of the approval mechanism, approvers may be given the ability to edit existing orders before approving them, which provides a valuable mechanism to control costs.

Once an order is submitted, the approver can be given the opportunity to edit the order before it’s approved.

The Path from Showback to Chargeback

One of my previous comments (http://info.cloudboltsoftware.com/blog/bid/306535/7-Takeaways-From-the-Red-Hat-Summit) about chargeback and showback is that due to internal resistance, few organizations are actually taking the step of producing invoices or decrementing funds from a budget.  Effective reporting is the first step in achieving true chargeback in an organization.  Only when IT organizations understand the true impact of a team, project, group, or line of businesses’ IT consumption can the Business itself make effective decisions around spend and focus of precious funds.  CloudBolt C2’s single pane-of-glass management coupled with the powerful built-in reporting goes beyond rate metering and actually enables Business-Driven IT.  The reporting engine makes getting the intelligence out of how an environment is being used possible no matter what your role in the organization. 

Thankfully, C2 can handle both use cases today.  Once C2 is implemented, IT Organizations can begin the process of using showback costs to drive user behavior, stamp out VM Sprawl, and further the push for true internal IT chargeback to business units.

Take-Away

Utility metering is an important part in recognizing where funds are being spent for access to IT infrastructure and applications.  An effective tool must not just do this for one platform, but unifying any number of platforms.  A granular metering infrastructure must separate the application cost from the hardware cost, which allows IT Administrators (and/or users) to piece together different variations of hardware and software to get the end capability needed.  All of this must be reportable in any format needed or desired.  Metering may be only one aspect of “the cloud”, but it’s an important one, and one, with CloudBolt C2, is built in, and integrated at every step of the way.

Want to learn more about how Utility Metering plays a part in Business-Driven IT? Bernd Harzog, the Cloud analyst at TheVirtualizationPractice.com recently wrote a paper that analyzes the various business impacts of next-generation cloud managers.