Estimated Reading Time: 12 minutes
Working in the Cloud solutions, I’ve had many projects involving CMP (different products and vendors).
I have often dealt with people with preconceived ideas or biased knowledge. Let’s see what a CMP is, from an IT Architect’s point of view.
TL;DR: A CMP is a solution for a company to create a services catalog fully integrated into the organization structure of the company. Automation is key, but it’s only one of the technical parts of the solution.
“Cloud” like in Public Clouds?
Public Cloud providers are often associated with the acronym CMP.
While some providers may have certain functionalities, this is not in the spirit of a CMP, but rather “simple” Cloud infrastructure services. A Cloud provider can offer IaaS (Infrastructure as a Service), PaaS, CaaS, etc.
Still, no, a Cloud provider is not a CMP; it could be an endpoint of deployment, but not a Cloud Management Platform.
To list some CMP solution vendors, you can for example refer to the Gartner Magic Quadrant : VMware (vRealize Automation), ServiceNow, Scalr, Flexera, CloudBolt, Morpheus Data, HyperGrid (HyperCloud), Snow (Snow Commander), IBM / RedHat (CloudForms), Cisco CloudCenter (previously known as CliQ) …
Definition and types
A Cloud Management Platforms is a set of tools (in one or more solutions, it doesn’t matter) that allow cloud computing to be integrated into the company’s governance model.
A CMP is essentially a “functional” tool, reconciling business and technical needs. The interfaces are intentionally simple for users, and (almost) complete for administrators and developers. There is no question of development solutions by themselves, but of solutions where you can easily make functional workflows with just a bit of code to make the glue.
These solutions being made for integration into human processes and validations, they are rarely made for speed – the challenge is not to have the fastest action, but on the reliability and exceptions management.
There are a lot of CMP offerings on the market, with different functionality sets. We can easily distinguish three types, identifiable by their origins:
- Type 1, CMPs focused on asset management. Designed primarily as an asset management database (CMDB), enriched with functionalities over time. The strength of these CMPs are their complete model for the user, with intelligent WYSIWYG workflows. Their weaknesses are technological compatibility, lack of openness or the complexity of their model.
- Type 2, CMPs focused on provisioning: Based on Automation, usually started with a technical Cloud solution to be automated, with a consumption interface. Strength varies from deep technical functionalities to serious speed and developer-friendly interfaces. Weak points of these solutions are they’re usually tied to solutions they automate (and not others), poor modularity and governance which is too limited.
- Type 3, focused on multi-Cloud and governance, with a simplistic but abstracted model to avoid a too strong link to a solution. These type of CMP originates from multi-Cloud or hybrid Cloud vendors (technical companies), they have a good level of governance, a fairly simple and usable data model. Weaknesses are the multiplicity of tools and interfaces and the complexity of the workflows.
NB: when I wrote “workflow”, it means a functional sequence of technical actions, represented in a UI by deliberately simplistic logic bricks. It’s often limited to comparisons conditions, switch cases and error trap ; with a few code to accommodate variables between the bricks.
CMP, IaaS, IaC… What is a CMP ?
It is not a “versus”, it is complementary. IaaS is the automation of the infrastructure objects (such as vm, LB, networks, …), IaC is the way to manage this infrastructure “as code”, according to a given reference stored in a repository. For the CMP, it is to combine automation and/or management according to a reference as well as process management, integration and several integrations to many components.
The needs, roles and design are also different between CMP and IaaS / IaC.
IaaS and IaC provide a technical response to the need for automation of different components, the functional value being standardization and time to market. Often, a team of DevOps or Engineers with good scripting skills is leveraged for this automation, implying method needs, platform and multiple technical knowledge. The responsibility of this team relates to the proper technical execution, but is not connected to the offer or the processes’ integration.
A CMP contains many functionalities, on different aspects: technical automation, ticketing system, functional workflows, financial showback and brokering, operations on objects, metrology…
A CMP is a complete solution, which will include (or to be integrated with) an IaaS / IaC part, and which will require a range of skills for each of its aspects: functional (objects definition, “how-what-why”, etc), offer definition, technical aspects of IaaS / IaC, operational aspects (platform and incident management, etc), governance, “code” models and processes (worklows, approvals, decision tree, etc).
It is common for a CMP solution to be composed by several products, even some could be optional depending on the choices and maturity of the customer. It’s unrealistic to think that a full-stack CMP can bring everything together in a single, easy-to-understand interface. Each feature set has its audience of admins, operators and therefore a responsibility matrix for each group of people.
(Why) Do you need a CMP ?
First of all, do all companies need a CMP?
In theory, this is a big yes, since it enables the “glue” the IT services between infrastructure, governance, processes, offering, object modeling, security, standardization and others.
In reality, it’s not that simple. A CMP is a complete suite, not to be confused with a “simple” IaaS or a “simple” CMDB. If the goal is only to automate the infrastructure for DevOps consumption or to store hierarchical information, then CMP is not the right direction and tool. To obtain a vm from a few entries, all it takes is one-liner bash / powershell / python script. If the requirement stops there, the adoption of a CMP can only be mitigated, or even harmful.
The choice of a CMP is supported by the company’s structure, size, maturity and interactions between the different entities of the company. A CMP offers transversal capabilities, covers a set of functional needs. However, if one of the entities/BU has specific non-functional needs (performance, advanced function, etc.), the CMP alone might not be sufficient.
Let’s try to simplify with a visual:
An organization has several entities. Each has requirements related to its technical activity, dependencies coming from interactions with other entities, constraints connected to the type and activity of the company, limits connected to the company’s processes.
A CMP is transverse to these entities / BUs, and each can have its own (automation) tools, alongside the CMP – nothing wrong, this is not incompatible, since the needs are different and the solutions are not intended to provide the same service.
Example: automation and standardization of security involves tools for defining security policies and flows validation (i.e. Tufin or Algosec), SeCops vulnerability scanning, reporting tools and so on. For Ops, we’re talking about centralization and analysis of logs with coordinated alarms, automatic (re)actions, intelligent capacity planning, or even self-optimization using AI.
Infrastructure teams will use IaC to manage its low-level configurations, use interpreters (i.e. Ansible or Salt), or automate with bash, powershell, python scripts …
And this is the difference: a CMP helps to cross the borders, allows different needs from different entities to be fulfilled, whereas individual automation and tools can go deeper but in their domain only.
However, as CMPs most often come from infrastructure landscape, automation functionality is key within CMP solutions, as are multi-tenancy functionality. CMP solutions also evolve along with technological changes, including:
- Infrastructure as Code with more and more integration to repositories, intent-based, declarative APIs and integration with declarative tools such as Terraform.
- Configuration Management and support for third-party solutions such as Puppet, Salt, Ansible, Chef to integrate configuration management directly from the beginning.
- Containers, with Kubernetes and Docker are a no-brainer in 2021.
- Multi-Cloud and Native Cloud: agnostic integrations, consideration of several Cloud providers
- CMPs gains functionality of Clouds “Broker”, to deploy services and applications on different clouds according to evolving and dynamic criteria
What could prevent a successful implementation of CMP ?
If you’ve read this far, you should have caught one of the main blockers: misunderstanding of what a CMP is. It is not an infrastructure automation solution only, it is not suitable to be used by and for a single entity without integrations, and it is not a simple relay to have a graphical interface.
There have been many CMP deployments for (too much) targeted uses, whether to automate the infrastructure or just to do support ticketing. In any case, adoption can’t be 100% successful ; it’s not a failure, but the teams can have grievances against the platform: not lightning fast, too complex, lack of functionality… again- the role of a CMP is not to go deep into technical needs.
A current example is that some persists to compare, or even try to make the CMP carry all the functions of a complete IaaS such as Kubernetes. A CMP solution will not replace the scheduler or the types of Kubernetes objects, unlike Kubernetes will not offer a multi-tenant interface with approvals, agnostic placements … Just like other solutions, there is no point in comparing a (transverse) CMP with a (targeted) automation solution. Just don’t compare apples and oranges.
The second common problem is the team(s) definition and the resources used. It is a transversal solution to several entities which usually speak little or not to each other. A good way to fail is therefore to build a team with only people from a single entity, or even not making a dedicated team and relying on extra time from a few existing team members.
Another frequent issue is linked to the constitution of the team: when it’s made up of (too many) developers (coming from app development), it becomes difficult to understand the architecture, data model and workflows engine of a CMP; since this population is used to application development. They’d like to apply usual development methods, which are a very valid source of failure for a CMP. Don’t get me wrong- code methodologies are good things, but it’s not adapted for CMP and over-complexifies the solution. A CMP is much closer to “NoCode” than to “pure” application development, the needs and constraints are different.
Example: A simple function to integrate vm into CMDB, interacting via simple API “POST”/”DELETE” calls. For CMP and integration point of view, the “code” in itself is simple, few lines for ~2 working days (at most), it’s a functional rather than a technical workflow, changes less than once every 3 years and testing acts on the infrastructure.
In an app development lifecycle, this function should be part of a development factory (weeks/months to set it up), then will require code design, implementation, review, security testing, automated tests…
If the goal is to over-complexify, over-engineer and generates frustration, then get to an application development approach is a good way to that failure kind.
To list one last important blocker: the need to clearly define the service offer. The CMP solution will publish the services “developed” by the team, but the offering and dependencies must be well understood: how far the CMP’s offer goes? A user who has infrastructure assets outside CMP should consume network automation directly or via CMP? Is the CMP “a compulsory checkpoint”, is it only an “overlay” for certain cases?
These definitions must be part of the CMP offering, use cases and be supported by IT direction.
Both approaches are valid, however, the goal to implementing a CMP is to streamline processes and have a simple and standardized approach, entry point. Perhaps not all the subtleties can be offered by each entity through that, but the large majority of service consumers will get what they need.
To this end, the CMP should be the single point of consumption (green arrow), even for “non-native” services, since the company’s processes, validation and FinOps are tightly included. Of course, everything which is deep technical and/or not published as a service could be consumed directly by automation or manually (red arrow).
As I am sure you have understood, this subject is vast and involves numerous people/teams.
CMP are a functional tool rather than technical, it aggregates several views. CMP solution integration into processes, orchestration/automation and user experience are key metrics and actions to have correct adoption, but the secret keys to success are maturity and a deep and realistic (functional) understanding of the solution.
Adopting a CMP is not just about automating vm, LB, firewall or whatever infrastructure thing – it’s about multi-entity cooperation and work, process and governance inclusion, and clearly defined offer and consumption model. Automation and provisioning are just technical answers, not the “why” of those solutions.
The secret sauce begins like any other IT “product”: with the creation of a cross-functional team, using a “K.I.S.S.” methodology, gradually re-establishing needs and “develop” the services catalog. The little magic ingredients are cooperation, question the status quo and fully understand functional needs and limits.
Everything is about the people, who should be your main investment area, who may or may not guarantee the success of your IT governance, and in fine, the success of your CMP platform.