Enabling Self-Service Cloud Environment Management for 100s of Distributed Development Teams

How a multinational logistics and supply chain management company created a Self-Service Developer Platform to turn complex cloud infrastructure requirements into self-service cloud environments to meet the needs of their complex organizational hierarchy.

Many enterprises today are attempting to migrate their application environments from legacy on-premise infrastructure to public cloud platforms. A primary driver for doing this is to scale DevOps workflows and provide developers with a more efficient, self-service experience. While cloud Infrastructure and DevOps teams want to provide such a self-service experience to developers, they want to deliver it with guardrails. The environments should be deployed using tools approved by the cloud and DevOps experts and use approved best practices for configuring and securing cloud resources. Among the benefits of doing this are a simpler way of supporting the use of shared cloud resources and providing an efficient experience for development teams to self-request and self-manage their cloud environments.

By 2025, 95% of enterprises will fail to scale DevOps initiatives if shared self-service platform approaches are not adopted.

Gartner’s article: How to Scale DevOps Workflows in Multicluster Kubernetes Environments

We know all too well the hurdles that hinder the implementation of these practices.

Having a shared platform across many teams creates an opportunity for more efficient use of the cloud, especially as it relates to the use of shared resources between environments and teams. Unfortunately, the organizational structure of many enterprises makes it difficult for them to be able to experience these benefits (see Figure 1). In addition to ensuring consistency in the way development teams use cloud resources, DevOps teams need to maintain efficiency by abstracting the infrastructure complexity from the tools and processes used by development teams.

Such was the case for one Cloudify customer. However, Cloudify was able to address these technical (see Figure 2) and organizational challenges of our customer, making it possible for them to experience these benefits.

The following image (Figure 2) provides an example of how an enterprise would like to enable rapid product development through the use of both shared and dedicated cloud resources. A self-service cloud management platform should be able to support such a cloud environment structure. 

Complex organizations need to provide developers with “golden paths” to deploy certified environments that leverage tools and best practices approved by IT and DevOps experts, reducing the cognitive load on developers while preserving their freedom to get what they need to build their applications. These organizations are looking to implement platform engineering and internal developer portals (IDP) to address this need.

Our customer is in the international logistics and supply chain management market. They have more than 300k employees, servicing more than 200 countries and territories around the world. In 2021, our customer generated more than €80B in revenue. This is a big company with 1000s of developers and hundreds of complex applications running across multiple clouds and environments and using multiple tools to manage it all.

Developer Self-Service Supporting a Complex Organization and Resource Hierarchy

Our customer had some key business requirements for how they wanted to manage their cloud environments.

• They wanted an easy to use developer portal that provided their developers with a self-service experience for requesting and managing cloud environments, but they wanted the DevOps team to be able to control who could request certain resources, what resources would be offered to specific developers, and how those resources were provisioned and maintained.
  
• They had already put a lot of effort into defining the relationships between different cloud resources to meet their business demands and they wanted to maintain those relationship definitions. But the definitions were complex and dynamic. Some of the resources were shared globally across different teams, while others were dedicated for use only by specific teams. For example, in Azure, they have a complex definition of Resource Groups which are associated with specific VMs, which are then associated with specific data disks that are encrypted with team-specific encryption keys. They also wanted to make sure they maintained records for every provisioned resource in their configuration management database.
  
• They had also heavily invested in CyberArk as their credential vault and in Azure Active Directory and SAML as their Single Sign-On Service. They wanted to be able to leverage these security services to control access to the developer portal and to manage the credentials for accessing the various public and private cloud platforms.

It’s Not Always Better to Build it Yourself

Our customer attempted to build their own developer portal to meet these requirements, but they hit some key challenges.

• Support for defining shared resources, but still being able to control who could and could not access the shared resources, was difficult to implement in their portal’s security model.
  
• They found it difficult to segregate resources for development and non-production environments from resources for production environments, which put their production environments at risk of performance and availability issues.
  
• The complex hierarchy of cloud resources made it difficult to scale their solution. The nuances between cloud deployments for different teams using different cloud credentials and encryption keys meant they had to maintain multiple versions of the same baseline infrastructure as code modules. This impacted their ability to scale to meet demand.
  
• The complex organizational hierarchy of their enterprise was difficult to implement in a traditional RBAC model. The organization changed often through acquisitions and internal reorganizations. Trying to implement an access control model that matched their complex organizational hierarchy impacted the ability to easily scale the solution they built.
  
• The solution they built was able to provision cloud resources, but it had no support for Day 2 operations, such as scaling, healing, updating, or changing the configuration of provisioned cloud environments.
  
• They also needed to write code to integrate their custom portal with their CMDB and credential vault via APIs. This proved to be a big maintenance job and took up a lot of the DevOps team’s time.

Turning Infrastructure into Self Service Environments

What our customer discovered was that key features of Cloudify addressed many of the challenges introduced by their homegrown developer portal.

• Our customer needed to support many interfaces for their developers to provision and manage cloud environments. They needed to control which users could request and access specific cloud resources and they wanted to use SAML-based SSO via Azure Active Directory to do this. Cloudify supports SAML-based authentication.
  
• They had a future requirement to add cloud provisioning and management to CI/CD pipelines. Cloudify’s support for integration with CI/CD tools like Jenkins supports this future requirement.
  
• Cloudify made it easy for their DevOps team to deliver a self-service experience for developers. They were able to use Cloudify’s certified environment blueprints to provide developers with a self-service experience for requesting new deployments based on pre-approved deployment templates. Cloudify was also able to implement the RBAC model they desired to control which deployment blueprints each user was authorized to use and which cloud credentials and encryption keys were available to the different teams of developers for managing their deployments. It also provided a remote execution platform that could be integrated with the existing Infrastructure As A Service (IaaS) layer they had already created in front of their Azure and VMWare cloud platforms.
  
• Using Cloudify’s support for multi-tenancy and environments enabled the complex hierarchy required by their end customer.

Customer Hierarchical Environment Modeling

Certain resources of our customer’s cloud environments are shared across all development teams. Cloudify’s support for global resource visibility across tenants supported this model for sharing resources. But the customer also wanted to segregate the deployments of one development team from another. Cloudify’s support for multi-tenancy made this possible. Each Cloudify tenant segregates its deployments, blueprints, and even cloud credentials and encryption keys from those of other tenants.

Inside each tenant, Cloudify provides environments. Each environment can have dedicated properties, such as authorized VM types, reserved IP addresses, and encryption keys. These properties can be used for any deployment inside of the environment without needing to expose the values directly to end users. When a new deployment is created, the environment properties are automatically passed from the environment to the deployment.

Any deployment blueprint a user is authorized to use can be used to create new deployments in any environment a user has access to. When a user creates a new deployment from a deployment blueprint, the appropriate environment capabilities for the selected environment are passed as inputs to the deployment. The end user never has to be exposed to any of this complexity.

The environment capabilities are passed to a master blueprint that defines the service model for each deployment. In our customer’s scenario, the model would first create a VM with an assigned IP address, and then runtime properties of the VM and its environment, such as its IP address and the encryption keys for the selected environment, are passed as inputs to the subordinate cloud resources of the VM, such as its data disks and the definition of who gets access to the VM. This is made possible by Cloudify’s support for service composition. A single deployment can consist of multiple services, and the relationship between the services is defined by the master blueprint.

Because Cloudify maintains the state of all of the deployments we manage, we can make Day 2 operations, such as resize, configure, restart, and others, available to the deployments. These are standard Day 2 workflows that Cloudify provides out of the box.

The Impact: Increased Efficiency and Scalability

Cloudify’s support for all of these features that simplified and automated our customer’s definition and management of their complex cloud environments had a positive impact on the business. With their old homegrown developer portal, our customer was able to support the requirements for a single application stack with a limited number of version types and a small group of developers. There was no way they could meet the demands of the scale of requests they anticipated receiving. Once 100s of applications needed to be managed, with at least 3 versions of each application (Dev, Test, and Prod), and 1,000s of developers writing the code for these applications, the custom solution couldn’t keep up.

The result was multiple weeks just to deploy a VM and multiple months to deploy a full production application stack. By implementing Cloudify and taking advantage of our support to automate the management of complex cloud environments with complex resource and organizational hierarchies, our customer was able to reduce deployment time to a matter of minutes in most cases. Even their most complex production deployment takes no more than 1 hour to provision.

Support Efficiency Now, Support New Requirements in the Future

To summarize, our customer had important reasons why they selected Cloudify.

• Possibly most important was our ability to configure Cloudify to support the existing security and infrastructure models our customer had already defined and did not want to change.
  
• We could easily map complex resource dependencies across both shared and dedicated resources.
  
• We could map the relationships between the dynamic organizational structure of their development teams to the complex resource relationships we define in our master blueprints.
  
• Cloudify integrates out of the box with ServiceNow from both a technical and a business perspective. Cloudify can easily expose certified environment blueprints as requestable objects in the ServiceNow ITSM Service Catalog, and we can use existing workflow approval processes in ServiceNow and apply them to new requests from the Service Catalog.
  
• Finally, our customer learned through our support for integrating with their custom internal development platform and their custom IaaS abstraction layer that Cloudify could future proof their cloud environment. The combination of out of the box integrations, extensibility via custom integrations, and the ability to easily add new certified environments to the service catalog meant they could be confident in meeting future business demands using Cloudify.

Ultimately, our customer wanted to implement a platform engineering strategy that did not require them to change their organization hierarchy or their existing DevOps processes. They needed tools that were flexible enough to support their existing processes and automated them for efficiency and scale. Cloudify was able to deliver this flexibility, speed, and efficiency to our customer. 

Cloudify can be used as part of a platform engineering strategy to help organizations simplify the process of building and deploying cloud native applications. Some of the key ways in which Cloudify can help with platform engineering include:

• Providing a framework for building and deploying containerized applications: Cloudify enables developers to build and deploy containerized applications using a variety of tools and technologies, including Docker, Kubernetes, and OpenStack.
  
• Automating the deployment and management of applications: Cloudify provides a set of tools and frameworks that enable organizations to automate the deployment and management of their cloud native applications, including the provisioning of infrastructure, the deployment of applications, and the monitoring and management of application performance and reliability.
  
• Enabling integration with a wide range of tools and services: Cloudify provides integrations with a variety of tools and services that can be used as part of a platform engineering strategy, including monitoring tools, configuration management tools, and cloud management platforms.
  
• Supporting a wide range of deployment environments: Cloudify can be used to deploy applications to a variety of cloud environments, including public clouds, private clouds, and hybrid clouds.

Overall, Cloudify can help organizations to streamline the process of building and deploying cloud native applications, and can enable them to more effectively manage and operate their applications in a cloud environment, while supporting existing organization hierarchies and DevOps processes.

If you’d like to learn more about how Cloudify could meet your business’s complex multi-cloud environment management needs, please request a free demo of Cloudify.

You may also view a recent Cloudify webinar that reviews this use case and provides more details about how Cloudify technically addresses the mapping of complex organizational requirements to shared and dedicated technical resources for our customers.