** Welcome! to Nitin's CLM Blog **
I am a senior R&D Architect working on CLM (Cloud Lifecycle Management). In the past 5 years, I have worked closely with several CLM deployments in all sorts of domains. This blog is an attempt to share some of the learnings. Hopefully, you find it useful.
To get the blog rolling, what else could be a better topic than understanding CLM at a very high level? That does mean some of the stuff I mention below may sound familiar. Nevertheless, it's good to know, in general, what CLM is capable of as that will build foundation for future posts.
CLM @40000 ft.
- Manager of Managers
- This principle is very near and dear to CLM's core design. In general, what this means is CLM is not meant to replace the last mile Element Managers (such as, hypervisor management layers). Instead, its intended to work with these layers and add value on top. For example, CLM's Blueprint capability provides a unified way of working with different underlying platforms. This also means in many cases that customer's can leverage their existing investment in infrastructure management layer and best practices with CLM.
- Heterogeneity is a reality
- Be it public cloud, private/on-premise cloud, physical servers or some form of mix-n-match, CLM provides a rich set of platform support that continues to grow.
- CLM Roles
CLM supports the following roles to meet the needs of a typical cloud
- Cloud Admin: The super user(s) in the CLM world. They can do everything in CLM from administration to end user centric activities and have visibility and control over all services being managed by CLM.
- Tenant Admin: The Tenant Admin(s) can manage one or more tenants (a tenant being a Company). They have limited administration capabilities and have visibility and control over all services of the tenants they manage.
- End User: Last but not the the least, the end user themselves. An End User can request and manage his/her own services only. In addition, over CLM releases we continue to enhance the capabilities from an End User perspective with the focus of making them more self-service enabled.
- Service Blueprints for Service Design and Deployment
- CLM's Service Blueprints let you define 2 aspects a) Service Definition (what is the composition of a given service?) b) in what possible ways can this service be deployed? Add to that Service Blueprint authoring experience is consistent across different platforms thus making it easier for Cloud Admins to work in a mixed platform environment.
- Service Blueprints also let you specify 'toppings'. Yes, you read it right. We call it Options and Option Choices. And, just like toppings in a food menu are addons typically with additional price tags, CLM Option Choices are similarly part of CLM's Service Catalog and are fully configurable by the Cloud Admin.
- Cloud Administrator in control
Several companies who invest in cloud solution have realized benefits of not just being able to stand up cloud services quickly, but to be also able to reclaim services and the underlying resources when not needed. The dynamics of a cloud make it important to have consistency, repeatability and governance that Cloud Administrators can rely upon. With that in mind, CLM offers several core capabilities
- Service Governance: Ability to place service workloads per the desired infrastructure best practices and support modifications that honor the same. CLM provides foundational elements, such as, tags and policies that can be leveraged for these.
- Entitlements: Ability to only show users what they can request and not the entire cloud Service Catalog is an important capability.
- Multi-tenancy: Ability to allocate infrastructure resources to multiple tenants per the desired cloud business model. For example, CLM supports allowing dedicated infrastructure per tenant to having shared infrastructure across tenants and a mix of these approaches as well!
- Security: Whether you are looking for layer 2 segregation or fully firewall'ed and locked down service, CLM provides a rich set of capabilities to meet from simple to very complex needs.
- Quotas: An ability to hierarchically slice your infrastructure resources that are inline with your business objectives. For example, a Cloud Admin can allocate quota 'X' to a tenant, which means the tenant cannot exceed that quota. Further, the Tenant Admin (or Cloud Admin) for that tenant could split the quota amongst that tenant's users to ensure an optimal split. It's not necessary to allocate quotas. But, if allocated, CLM honors those.
- Dashboards: Convenient dashboards for Cloud Admins to get a cockpit view of the deployment. Things like, which are the most requested Service Offerings. So they can focus on value realization and where to spend efforts.
- Multi-site: Several of our customers have more than one location being managed by CLM. This is an important capability to know that same CLM management stack can help you manage multiple datacenters that could be spread across the globe thus providing you the benefits of a centralized management.
- Full Service Lifecycle Management
As many of us who have worked closely with infrastructure and cloud management solutions know that provisioning is typically not the long pole in a cloud management solution typically. It is generally the combination of process, people and technology. And, that's just the provisioning aspect. What about post provisioning (i.e., after the service has been stood up)? It is challenges like these that make cloud solutions more daunting. For CLM, this is one of our core focus area and we continue to get better. Some of the key capabilities to note are mentioned below.
- Simple single-tier IaaS services: If you are feeling bit shy of launching simple IaaS service via cloud, do not be. The majority of customers I have worked with have all pretty much started with IaaS offerings. What's important to know is you don't have to stop there. It's a milestone in the cloud journey that's worth considering.
- Complex multi-tier robust application services: For those who are looking to deploy multi-tier applications that are fully load balanced along with firewall configuration, CLM has a rich set of capabilities to accomplish these.
- Multi-step complex server build: A typical server build is rarely just provisioning. There may be additional process checkpoints (like securing some sort of application identification code before commencing provisioning), infrastructure updates (like DNS registration), ensuring host names are consistent with the deployment standards, notifying other systems (such as, monitoring and backup systems), the list goes on and on. The good news is CLM offers several capabilities to be able to adapt to your server build process to make the transition to cloud more friendly.
- Application Parameterization: Talk to any developer or application expert and they will differentiate between "application installed" vs "application installed and configured". And, they are right. Just because I installed Apache Webserver does not mean it's properly configured and ready to use. CLM provides several capabilities in this regard. An important one being an ability to pass either Cloud Admin specified configuration/application data that can be adjusted by End User (only if a Cloud Admin has allowed them to do so). Continuing with our Apache Webserver example, the Cloud Admin may let the End User choose the web server port, but may choose to keep the Document Root directory internal to ensure its path is consistent on filesystem.
- Auto-scaling: An ability to scale up or down as the application demand varies.
- Provisioning and Post Provisioning Actions: As provisioning happens you may have additional steps to execute, such as, format the added hard disk. Likewise, for any such activity that happens after the service has been stood up.
- CLM as an Extensible Platform
While CLM has a rich set of out-of-the-box capabilities, it is true that every customer environment is different. Their usecases may be same or similar, but the means to get there is typically not. Hence, we do not try to boil the ocean in our design. We have intentionally designed CLM with extensibility in mind. So, the way to look at CLM is not just as a solution, but also as an Extensible Platform that can be enhanced to handle the customer deployment specific needs that are not out-of-the-box. For example, CLM offers a rich REST API as well as an SDK for such needs. Here are some typical extensibility usecases (not an exhaustive list, but to give you a picture)
- 3rdparty Integration Scenarios like DNS updates, monitoring and backup solution updates for CLM managed services.
- Integrating CLM with platforms that are not available out-of-the-box (example, Solaris Zones).
- Making CLM use hostnames that follow the deployment standards.
- Ensuring CLM managed services are placed using very specific and custom workload placement logic.
- Building custom portal on top of CLM.
- Building northbound integrations on top of CLM for automation and other integration purpose.
I know that I didn't get to cover every single CLM feature. But, hopefully, this gave you a fairly decent picture of what CLM is capable of. I will be glad to hear any comments and feedback.
Have a good day!
Cloud is a journey with milestones and not a destination!