Do you need a CMDB for cloud-based systems?

Cloud computing is traveling along the hype cycle quickly, cloud technologies are maturing, and cloud adoption is accelerating on a global scale. Most IT managers now agree that cloud computing is both a new generation of system architecture and also a new form of IT service provider/user partnership.  Hybrid cloud solutions also successfully link in-house systems with the new provider-based “as a service” offerings.

One consequence has been an increased focus on systems management, especially the automation of change and configuration management processes. Hybrid clouds and multi-cloud systems are creating additional requirements for management integration.  As a starting point, cloud customers need a good record of all the resources/services being used, the service levels desired and being achieved, and what is being moved, added or changed (especially with self-service provisioning and automated scaling).  Providers must also manage and optimize their infrastructures across multiple tenants.

An accurate, well-maintained Configuration Management Database (CMDB) can help to reduce the risks of the cloud transition and support day-to-day operations and maintenance processes.   A Google search of “CMDB and cloud computing” illustrates how many different views of the role and importance of a CMDB there can be. These differences, however, are as much related to the acceptance of ITIL/ITSM as a framework for cloud management as they are to the intrinsic value of a CMDB.

A CMDB is a database of a assets/resources, which are called Configuration Items, or CI’s in ITIL-speak. The CMDB can include many different types of object including stakeholders, contracts, documentation, devices and services.  While the CMDB must contain all relevant details of the CI’s themselves, it is becoming increasingly important to also track the relationships among the CI’s.

The ITIL/ITSM CMDB should not be confused with the configuration management concepts used in the DevOps movement, which is more focused on software delivery, or systems engineering.  Examples of configuration tools for building systems include Puppet (open source software for configuring UNIX and Windows systems) and chef.  Software deployment, configuration control and orchestration are also key to service delivery automation, with Ansible and Salt being two current examples.

A CMDB for cloud computing will be even more valuable when microservice and container architectures are deployed in complex, dynamic, ever-changing cloud configurations. Documenting the relationships among CI’s is paramount when performing any type of compliance assessment, threat impact assessment, or troubleshooting efforts.

 

IT managers need a complete view of ALL their managed elements and how they interact – it doesn’t matter who owns them, where they are, whether they are virtual or physical, or how permanent they may be.

To meet these requirements, the most obvious technology is a graph database. One example of a graph-based CMDB that is well-suited for cloud computing environments is available from LightMesh Inc. of Toronto. From their website, we learn:

“LightMesh gives you the tools to easily design public and private cloud integrations, giving your entire organization visibility into what cloud services you rely on and how they are implemented. Whether it’s a single VM instance to get a new initiative to market or a full VPDC spanning multiple availability regions, LightMesh helps you quickly generate a fully documented design that can be instantly used by operations and support.

Beyond Cloud Design, LightMesh offers fully automated cloud provisioning for API driven cloud providers. With a completed design you are just one click away from a fully spun up implementation. This helps IT organizations improve their agility and customer responsiveness while maintaining control and supervision of the environments that they are responsible for.”   

LightMesh’s CMDB is available as a cloud-based service or as a private on-premises implementation.

 

Various deployment scenarios for a CMDB can be considered. For example:

  • A single CMDB with a management portal that could discover CI information from all sites and systems may be available from your cloud provider or a third party (i.e., CMDB as a Service);
  • An existing in-house CMDB could be expanded to collect and consolidate management information from the cloud provider (or multiple providers) via standard or custom APIs; or
  • In-house and cloud CMDBs could be linked together to create a single authoritative view of all resources wherever they reside. This is analogous to the concepts and goals that are being promoted with Master Data Management.

 

The “five essential characteristics” of cloud computing described in ISO/IEC 17788-2014 and by the NIST  would be supported by using a CMDB as part of the solution:

  • On-demand self-service – The CMDB can track services, service qualities and service components and be used to populate a service catalogue and support self-service provisioning.
  • Broad network access – A CMDB would include network, security and linkage information that can be used for compatibility, accessibility, security and privacy, and could also interface to identity and access control systems.
  • Resource pooling – The CMDB could document resource pool contents, capacity allocations, and assignments to tenants. Dynamic changes in user resources should be tracked both by the provider (as part of multi-tenant operations) and by each tenant for audit, accounting and performance planning.
  • Rapid elasticity. Services that are elastically provisioned and released, in some cases automatically, should be tracked using a high performance, realtime CMDB.
  • Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability. Resource usage can be monitored, controlled, and reported using a CMDB that has discovery and monitoring functions, thereby providing transparency for both the provider and the consumer of the service.

 

The CMDB was originally conceived as a simple repository of long-lasting and essentially static configuration information, which basically reflected the state of the systems of the day. Cloud computing has changed the “ballgame” with systems that are agile, dynamic, continuously evolving, and multi-provider.  The CMDB needs to be the nexus of information for a wide range of cloud-oriented configurations.

This is what I think. What do you think?

 

Original posted by Don Sheppard at IT World Canada, Oct 27th 2015: http://www.itworldcanada.com/blog/do-you-need-a-cmdb-for-cloud-based-systems

Riding the Hype Curve

Gartner released the latest iteration of their network hype cycle Monday and the Register did some rapid analysis of what it means for the market. A number of technologies near and dear to our hearts here at LightMesh are at or near the bottom: Software Defined Networking, White-Box Switches, and Network Configuration and Management Tools. In the best tradition of Eric Ries and Steve Blank disciples, we quickly got ready to pivot! 

Before we fully change our focus to Programmatic Instagram Marketing (ha!), is this really the end for these technologies? Should everyone in the space just fold up their tents and come back in 5-10 years?  Obviously not - these technologies are increasingly being implemented now but for the business value they offer rather than the "hype" around them. 

 

What's up with Cloud?

OpenStack and cloud in general provide a great example of adoption and the hype cycle in action – the past year saw a number of early OpenStack innovators exit the market via acquisition and outright closure. At the same time Amazon has announced that their cloud business is even better than anyone expected. Q2 saw AWS revenues of $1.8B with 81% year on year growth!

Clearly public cloud is mature and with consolidation and greater enterprise adoption, private cloud is not far behind. To emphasize this, TD executive Graeme Peacock discussed the bank’s ambitious project to adopt a private on-premises OpenStack cloud powered by RackSpace at May’s OpenStack conference. TD is North America’s 6th largest bank by assets so transitioning 80% of their infrastructure in 5 years is an absolutely MASSIVE undertaking.  

 

Software Defined Networking is not a fad?

Absolutely not. While SDN had been reserved for the giants of Google, Facebook and Amazon, in 2015 we are now seeing more enterprise planning and adoption projects around SDN technologies. While this is often in green-field technology build outs like hanging a VMWare NSX environment off to the side, or deploying Cisco ACI in a dev-test environment, customers are also beginning to think about transforming their legacy environments to SDN using datacenter migration and consolidation projects as the catalyst.

Most recently, AT&T's Q2 results highlighted the ongoing positive impact of their SDN project on capital spending. While not great for Ericsson and Cisco in the short term, this does begin to show that the advantages of virtualization and cloud will flow to related technologies in the network.

Theories are one thing but investors and customers want to see real results and compare the benefits against the effort required for adoption, and this is happening now.

 

So what? 

Change is hard, slow, and expensive even when there’s a proven business case and many validated examples of success coming from its adoption. For SDN, NFV, etc it’s even worse – the theoretical case is there but the tangible successes aren’t. 

With the largest enterprises now getting truly serious about adopting cloud technologies, DevOps practices and SDN, we have seen an increase in interest in better tooling, simply to deliver on the projects that they have committed to. This investment in improved tools like LightMesh not only enables tactical project success, but also installs best-practices into steady-state operations allowing them to deliver on cost efficiency and organizational agility targets that form much of the business rationale for cloud in the first place.  

This Gartner Hype Cycle, following on their negative assessment of the available cloud management tools, reinforces our perspective that the rise of point-solutions without a holistic configuration management tool is what has our customers talking to us. So Ryan Holmes and everyone else at Hootsuite doesn't have to worry about us coming to eat their lunch, we're sticking with helping the world's largest enterprises Know Their Network. 

 

If you are part of a cloud adoption or DevOps project at a very large enterprise get in touch and we'll help you deliver far ahead of schedule and under budget.