A version of this article was published in The New Stack on June 9, 2017.
In the first part of this series, we looked at the issue of cloud management silos created by multiple cloud environments and management platforms designed to serve different needs in the software delivery process, proposing a next-generation CMP as the means to deliver a common management toolset to serve the needs of developers in the business units and central IT.
In this post, we’ll examine what is needed to deliver a next-generation CMP.
Watch Cloudify 4 webinar – cloud management evolved. Join Now
Creating a Next-Generation CMP
The next-generation cloud management platform that we discussed in part 1 must serve both the business unit and central IT. To understand what that means specifically we need to map the needs of each one of them.
Mapping the Business Unit and IT Needs
First, it’s useful to map business unit needs into two distinct user profiles. The first is the end-user that wants a simple click through experience to get the needed service without worrying about how to manage it. The power-user, by contrast, is the application owner and is responsible for ensuring the performance and configuration of the application. This power-user needs greater control of the infrastructure.
The Central IT (operations) is essentially the cloud service provider in the organization, responsible for managing the common environment and ensuring that the business unit can operate and deliver its applications. It is also responsible for providing a common set of services that are not tied to a specific application such as database services, analytics services, automation and monitoring. Operations is also responsible for addressing cross cutting concerns such as security, regulation and cost.
Key tenets of a next-generation CMP
Mapping the business unit and centralized IT needs allows us to identify the key tenets that the next-generation CMP need to support:
- Empower the business unit—The business unit has the responsibility not just to deliver the application but also the specification on how to run and manage it on the target environment. The specification often comes in the form of a YAML template (TOSCA is good example for a standard definition of that spec) and can be considered as part of the application source code and packaging. This allows the business unit to have higher degree of flexibility in the choice of cloud, infrastructure resources and even application frameworks and thus create better collaboration and shared responsibility between the business unit and central IT. The fact that the specification on how to run and manage the application is now delivered as code allows to expand the contribution and collaboration practices that were traditionally used between the development teams also as a means to manage collaboration with central IT operations.
- Cloud Native—Cloud native applications are built as a set of microservices and not as a monolithic application. This requires that each application service would be able to have a means to discover and interact with services in a generic way and not be managed in a silo. The new CMP should have native containers support which is the common package and delivery mean for microservices.
- Integration approach at the core—Traditional cloud management had to develop new monitoring, billing, logging systems. We now have many open source products that do a pretty good job covering a specific function of the application management stack such as monitoring, logging, configuration management, and container management. This shifts the management challenge from implementing each of those functions to integrating the best of breed solutions through a plug and play experience. The second challenge is how to provide a holistic experience across those best of breed management stacks through a single pane of glass as if they were part of a single platform.
- Allow simple and fast adoption of new frameworks and applications—The new CMP must remove the complexity of managing applications through managed services, for example database as a service, reporting as a service, and application server as a service.
- Everything self service—Common tooling must be provided through a self-service mode allowing central IT to deliver needed services quickly.
- Application driven KPI and built-in activity monitoring—Monitoring focus should shift from infrastructure resources such as CPU and memory to application-driven monitoring and activity monitoring such as number of applications deployed, number of instances per cloud,the size of each deployment, and the state of each deployment.
- Closed loop—Monitoring system data was traditionally targeted for central IT. In the new CMP, it should be easily accessible to the application users in the business unit through an API. This will allow application owners to handle self remediation by automation for things like failover and auto-scaling.
- Actionable Insights—Rather than providing raw monitoring data which is rarely useful, the monitoring system of the new CMP needs to provide meaningful insights and recommendations. These can include cost-related and utilization insights and can become actionable in the case of failover, scaling, or shutting down unused resources.
- Putting Network and application management together—Network configuration such as firewall rules, VPN connectivity, load-balancer have been absent from traditional CMPs. In a hybrid cloud environment, network management becomes key, and it needs to be tightly integrated within the next-generation CMP. Network virtualization allows more than configuration management of the network; it permits full automation of network element instantiation as part of the application life cycle. This opens the door for application-driven network management in which the network follows the application, configured and controlled not just by the network operator but by the application owner.
Model driven, orchestration-first approach to cloud management
The key enabler for achieving the above requirements is taking a model-driven, orchestration-first approach to cloud management rather than an infrastructure-first approach as with traditional cloud management. The orchestration-first approach drives a holistic integration of the resources that serves the application through its lifecycle. Orchestration-first focuses on automation and provides a generic model for automating application lifecycle by providing a generic framework for turning applications into self-managed services.
Developers can define the application description and the specific target stack including the way it should be managed through model driven templates, and the orchestrator is responsible for mapping those templates into an automated execution plan that interface with the underlying resources.
Central IT, as the service provider of the shared multi-cloud environment, uses the orchestrator to control which resources should be exposed to application developers and how.
Serving the business unit and Central IT
Now that we’ve identified the key tenets behind of the next-generation CMP and the central role of the orchestrator in that environment, let’s see how those tenants map into specific features and how each of those features addresses the needs personas in the business unit and central IT.
In my post What Developers Want From Their Technology (But Mostly Cloud), I talked about what a developer needs from a cloud system. Mostly they want to be able to select the stack and environment that they want. From there, they want to focus on application development for that environment without worrying too much about management. The following set of features is a good example of how a next-generation CMP can address this:
- Catalog—Provide an easy way for developers to select and activate the target environment through self-managed services.
- Built-in integration and support for popular cloud environments—The idea is to deliver support without exposing a “least common denominator”. This includes container frameworks such as Docker and Kubernetes as well as services like DBaaS.
- Simple CLI experience—Allow developers to run applications from a local desktop environment for development and testing through a CLI.
Power User (a.k.a the “DevOps guru”)
Power-users are responsible for automating the development and deployment lifecycle. They are also responsible for ensuring that the application meets performance, security, availability and cost targets. To meet those responsibilities, the power user needs greater control of the environment and its resources. The following set of features provide a good example of how a next-generation CMP can address these needs:
- Model-driven blueprints—Provide the interface for automating key workflows needed to manage the application and interface with underlying resources via a blueprint that’s often based in a YAML file. To simplify the development processes it is also common to have a “composer” which is basically an IDE for blueprint development.
- Model -driven design—Provides Restful API access to the resources exposed in the CMP, starting from the infrastructure resources to the monitoring system.
- Extension through plug-Ins—Plug-Ins provide an interface to extend the CMP to support any resources or API endpoint that needs to be part of the application life cycle.
- CLI interface—A popular choice for integration with the build system.
Central IT Operations
The operation group is responsible for managing the shared infrastructure which often includes multi-cloud resources and a mix of private and public resources. It is also responsible for governance and assuring that the business unit follows standards on how to run and manage their applications. The features below should be included in a next-generation CMP to address their needs:
- Application/Service Reporting and insights—A monitoring capability to track key KPIs per application.
- Activity monitoring—A feature to allow monitoring of activity per user per application over time.
Towards better collaboration
The main difference between traditional cloud management and next-generation cloud management is that the role of the business unit is vastly larger. Developers are taking an active role in application management and the choice of cloud stacks needed to serve those applications. Collaboration between the business unit and central IT must become smoother, placing greater emphasis on how central IT empowers the business unit rather than controls it.
Central IT, as the service provider, can provide a common multi-cloud environment and a structured model for interacting with it. At the same time, it should embrace ideas and input from the business unit that can enable more rapid evolution of the shared environment and keep it up to date with the needs of the business units. The goal for all involved is to avoid turning the shared environment into the next IT bottleneck.
Final Notes: Developer Freedom. Your success
Enterprise technology spending in 2017 is set to rise 3%, with $3.5 trillion expected to be invested on technology, according to Gartner Research. Within this environment, operations will need to pivot from being seen as a cost center that risks being cut each year to one that helps build the business and is in step with its goals.
The key is to understand that Central IT serves the business and regains its central position in the organization is by supporting and empowering developers in the business units, turning them into active partners rather than passive consumers. The next-generation CMP is a means to enable this sort of interaction by offering a common platform and a set of self-managed services give developers a life at least as easy as when they were working directly with public cloud. The next-generation CMP also supports extensibility of the system by the business units.
By delivering these improvements, next-generation CMP creates a higher degree of developer freedom which is key to regaining their trust and driving success for the business.