I am excited to announce the general availability of Cloud Lifecycle Management 4.6.04! In an effort to deliver valuable new capabilities in a faster and easier-to-consume fashion, we have been delivering more frequent Feature Pack releases, of which this is the fourth this year (on top of the 4.6.00 release at the beginning of 2016).
This latest Feature Pack expands our integration into Microsoft Azure to allow customers to provision HDInsight Clusters, Redis Caches, IoT Hubs or virtually any other service type via Azure Resource Manager templates. On AWS, it allows for simpler definitions of access rules via reusable Security Groups. It also extends our unique strengths in compliance of services, as well as further enhancing programmatic use of CLM by dev/test users, and is the easiest update deployment yet.
At the same time, we have also published the Application Centric Cloud integration that we demonstrated at BMC Engage earlier this month, through which CLM can truly deploy complete application environments on-demand, including the "last mile" of development teams' internal application builds. Here's an example of how this can be used.
In this example, when a new build of the JPetStore custom application is triggered in Jenkins, BRPD automatically creates a new application deployment instance (via a Jenkins plugin to BMC Release Package and Deployment, aka BRPD), complete with all of the tier-specific steps to deploy a running instance of this new version:
When a Dev/Test user wants a new JPetStore application environment, he or she can choose the particular build number to deploy, including the just-completed latest build:
CLM will deploy all of the server, storage and networking infrastructure that is needed (which may vary among different single and multi-tier offering sizes), along with all of the platform components (web server platforms, application server platforms, database server platforms, etc.), and finally the custom application elements (via BRPD) and even bootstrap data. Later, the dev/test user can also update the JPetStore application on an existing environment with a newer build:
This will help dev/test users eliminate time they currently spend deploying and configuring custom builds within these environments, reducing distractions and enabling them to focus more of their time on actually developing and testing new application releases. These environments are created in consistent fashion, which further reduces time spent debugging manually-induced variations between developer, tester and ultimately production environments.
Diving further into to other new capabilities, the base 4.6.00 release of CLM back in January included the framework for a new provider type for external template-based provisioning, which was designed to accommodate implementations for AWS CloudFormation, Azure Resource Manager, OpenStack Heat and others, but did not include any out-of-the-box provider implementations. Feature Pack 1 (4.6.01) followed a few weeks later, delivering a provider implementation for AWS CloudFormation. Feature Pack 4 (4.6.04) now delivers a provider implementation for Azure Resource Manager.
The intention for supporting external template-based provisioning is to extend beyond the kinds of resources that CLM models in its Service Blueprints (such as servers, applications, storage, relational databases and networking) to the entire spectrum of resource types that a cloud service might offer (such as analytics, non-relational databases, in-memory cache, server-less code execution and mobile services). And if a cloud service introduces a new type of resource (and it is supported via its template language), it can be immediately leveraged via CLM. Using CLM to drive provisioning of these templates expands the scope of visibility that the organization has into what resources are provisioned where, both internally and externally. It also allows for integration with necessary IT processes such as change management and automated CMDB updates.
Feature Pack 4 also simplifies the administration of external template references by automatically discovering template parameters and creating corresponding CLM Service Blueprint parameters, including enumerated parameter value choices that can be displayed as dropdown selections during service requests. This greatly simplifies the CLM Administrator's steps when incorporating an external template file. Here's what it looks like:
A CLM Service Blueprint that references an ARM template now presents a button to Discover Parameters from that template:
A portion of the referenced template is shown here, highlighting its parameters:
Upon clicking "Discover Parameters", CLM automatically creates Service Blueprint parameters from those template parameters (which can subsequently be set to be displayed to end users during Service Offering requests):
Another area of improvement in Feature Pack 4 addresses programmatic invocation of CLM, i.e. via the API or SDK. Such calls now generate the same Activity Log tracking details as requests submitted via the CLM End User Portal. This brings more parity between the UI-oriented use of CLM and the more developer-centric means of using CLM, ensuring that the same audit trail and visibility is available no matter how users interact with CLM.
In CLM 4.5, new troubleshooting details were introduced for CLM Administrators, enabling them to quickly identify errors, take corrective action and restart the provisioning request. CLM 4.6.03 introduced the ability to display this level of detail for all requests, whether failed or successful or even still in progress, for example providing insight on how placement decisions were made. Insight into the processing of tags during provisioning can greatly assist in properly setting tags to achieve your desired placement strategy. This visibility can be, based on CLM configuration, made available to CLM End Users as well, since some errors can be addressed by end users without the involvement of CLM Administrators. CLM 4.6.04 now provides AWS and Azure-specific troubleshooting & progress details as well.
Feature Pack 4 provides other improvements in its integration with AWS, including the ability to utilize any new EC2 Instance Types and Instance Families, even if introduced by AWS at a later point in time. It also allows CLM to associate new EC2 instances with pre-existing Security Groups (e.g. for standard access rules to be used on many/all servers), in addition to the Security Groups dynamically generated from Network Paths defined in CLM Service Blueprints.
Following up on the compliance visibility capability introduced in CLM 4.6.00, where newly provisioned servers are added to BladeLogic Server Automation Smart Groups for recurring compliance scanning jobs, Feature Pack 4 offers an option to ensure that the compliance job is executed immediately during the service request fulfillment. This helps ensure that service offerings are measured for compliance as soon as they are provisioned and, if matched with automated remediation in BladeLogic Server Automation, brought into compliance from the outset.
The installation of Feature Pack 4 is simple to execute, taking on the order of an hour to complete, and includes the Azure and OpenStack providers (which were previously additional installation items). It requires an existing environment running on CLM 4.6 (either the base release or any prior 4.6 Feature Pack level), and includes all updates delivered in previous Feature Packs. I strongly encourage you to download and deploy this latest update and begin taking advantage of its expanded capabilities!
-- Steve Anderson, Product Line Manager, BMC
P.S. In case you missed the earlier CLM 4.6 Feature Packs, here's a brief review of their capabilities:
- CLM 4.6.01 (Feature Pack 1):
- AWS CloudFormation external template provider
- CLM 4.6.02 (Feature Pack 2):
- ITSM Foundation Data brownfield synchronization tool
- CLM 4.6.03 (Feature Pack 3):
- Self Service
- Troubleshooting/progress data available to end users
- End users can request services for & transfer services to other users
- SDK invocation of custom operator actions
- Management API for detailed CLM and component version numbers
- Platform Support
- Service-level compliance visibility for more platforms
- Azure support for private network connections, Security Groups, new instance types
- Support for VxLANs
- Improved firewall rule management performance
- Load balancer parameterization
- Self Service