Automate the infrastructure provisioning and expose as a self-service component

Authors: Shikha, Noopur Agarwal

Today’s IT world is becoming increasingly complex, and the challenges posed by shifting to hybrid and multicloud environments seem daunting. For any enterprise, a sound strategy for handling this complexity — resource provisioning and management, visibility, security, automation, and collaboration to manage hybrid and multicloud — is key to long-term success.

Enterprises are challenged with standardizing what development teams can use in the sandbox and what the SRE teams can leverage in the production environment. Additionally, the challenge is to consolidate IT resources and be very agile. Enterprises need to standardize on a catalog of services with clear specifications that are available for the Development and Production environments. The IT resources could be Kubernetes clusters or well-specified VMs in your on-premises or public cloud environment. These resources also extend to storage and to applications. Also, there is a need for self-service with a built-in approval mechanism so that the resources can be used or scaled for various departments as needed. Once deployed, these resources must be tracked or managed for Day 2 operations or custom actions, transfers to users in the department, and infrastructure life cycle.

In summary, Enterprises look for

• Self-Service catalog of enterprise-approved services. The administrator creates a collection of services and assigns them to users for convenient access through their self-service portals.

• Service approval for the set of deployments. Where cost is involved (infrastructure), approvals are needed to provision the requested infrastructure. Not only this, configuring external approvals is also possible before going ahead with deployments. For IBM Cloud Pak for Multicloud Management , you can have external approval for the services, as described here.

• Service tracking for managing the deployed artifacts. This involves managing the different states of the deployed infrastructure post-provisioning, and executing custom or user-defined actions from the self-service portal.

Let’s consider the example of Ops users O1 and O2. They have different needs for their respective departments, D1 and D2. The IT administrator needs to compose the service for the users based on their individual needs, and the resources should be accessible by only the privileged user. User O1 wants to deploy a Red Hat OpenShift Container Platform (RHOCP) cluster with application deployments on top of that cluster, with a large configuration. User O2 just needs 10 RHOCP clusters, with a small configuration for their development. User O2 also needs an NRG (NodeJs + REACT + GraphqL) stack for some of the deployed development environments.

For users O1 and O2, the IT administrator prepares composite service S with multiple activities like Terraform to deploy the cluster configuration chosen by each user, importing that cluster into the cloud for managing the instance. The administrator also uses Helm applications later to deploy the required stack on top of the provisioned cluster.

With service S assigned to user O1 with the large configuration, O1 can deploy the large configuration clusters and manage each of those clusters as its own instance via the Service Library.

With the same service S assigned to user O2 with the small configurations, O2 can deploy multiple (10) instances of small configuration clusters and assign them to the development owners by deploying in the individual development namespace or department.

The service S is integrated with the approval flow: When any user of D1 triggers the request, it is routed to D1; and when 10 users belonging to D2 (d1, d2, d3, …, d10) trigger the request for approval, it is routed to D2.

Ops users O1 and O2 won’t be able to see what's been assigned to others. They can access or consume their own set of provisioned resources.

Cloud architects are responsible for bridging the gaps between complex business problems and solutions in the cloud .Their primary focus is to include the multicloud capabilities that can reduce the risks and deliver more automation throughout end user cloud journeys.

Additionally , an automated deployment, management and governance from a single control point, wherever your workloads run and at the same time fulfilling the customer needs , multi tenant applications/services too.

What does the cloud architect need?

Service as a code

• Cloud architects need a way to describe the services as a code that can be governed through the code repository and build pipeline.
• With IBM Cloud Pak for Multicloud Management, self-service infrastructure, resources, cloud providers, and more are all tied together using the Infrastructure as a Code (IaC) mechanism, which gets converted from a simple user understandable language and executed at runtime. Basically, the Service Definition is meant not only for provisioning and managing the infrastructure but for managing external resources (such as public cloud infrastructure, private cloud infrastructure, network appliances, and PaaS) with “providers”.
• IBM Cloud Pak for Multicloud Management services can create new resources, manage existing ones, and destroy those no longer needed that are defined as infrastructure as code. The service orchestration tool uses Terraform (IaC) as an underlying engine which maps the user inputs and the infrastructure with set of different configuration instructions to code.

Role-based Access Control

• Enable access control to the services.
• With IBM Cloud Pak for Multicloud Management, the cloud administrator can create these services as needed by the Ops user, expose those that can be accessed by the user, enable them to deploy and manage the services through their own portal, and be able to modify them to accommodate future needs.
• Administrators can enforce role-based access control (RBAC) on each member of the infrastructure team. The teams can create, collaborate, and manage their own infrastructures.

Service Orchestration

• Create a combination of services with well-defined configurations, such as a service creating an OCP cluster with a defined number and well spec’ed out the master and worker nodes, and then deploy a MongoDB database.
• With IBM Cloud Pak for Multicloud Management, the service exposed to the user can be composed with different objects like Terraform templates, Helm applications, or some rapid deployments of Redis and MQ, while providing both containerized or VM-based applications in one flow.

Day 2 operations

• Services enabled for Day 2 operation.
• With IBM Cloud Pak for Multicloud Management, managing the deployed infrastructure, later on, is possible, and teams can create and manage their infrastructure state. Some extended Day 2 operations or custom Day 2 operations can also be composed and executed on the instance deployed.

IBM Cloud Pak for Multicloud Management self-service capabilities allows users to consume services. Developers can build applications and services aligned with enterprise policies, and then quickly deploy them.

These integrated sets of services are available through the Service Library to different Operations users, which can trigger approvals and automated infrastructure in the same flow.

For all of the above, we have one solution that fits the requirements of cloud administrators, making their lives easier because they get all in one place.

Interaction between the user and the IBM Cloud Pak for Multicloud Management

That’s the beauty of having a self-service portal where you have your choice of a service offering from the IBM Cloud Pak for Multicloud Management curated set of services in one place.

The complex of applications, infrastructures, or development stacks can be provisioned in a few clicks. Each user has custom access and resources using a single-service library that would have taken hours to complete if done independently. So, for Cloud IT Administrators, IBM Cloud Pak For Multicloud Management provides everything from a catalog of services.