Multiple Requests, Multiple Modes of Delivery
IT administrators typically juggle a lot of requests for resources from end users across the enterprise. Most of them have a backlog of IT service tickets to prioritize and address. When teams responsible for setting up resources get overwhelmed, the “wild west” can occur—a less-governed playing field for IT resources in the enterprise—where end users can self-service IT resources from almost anywhere.
A lot of us have stopped calling this characterization “shadow IT” and the scenario has become less judged. DevOps teams typically want services and applications up and running quickly, often in a continuous delivery model. However, they don’t want to wait for IT resources to be provisioned and “hardened” as some of their legacy systems needed in the past.
Enterprise IT must have a balance of more standardized processes at the core in a “mode one” delivery model and then agree to deliver other resources with some flexibility in a “mode two” approach. This strategy is considered bimodal IT, as defined by Gartner analysts here.
No worries if this sounds too academic. Consider that the “mode two” resources often fall into the “wild west” category initially, and then as they mature, they become more structured and governed by central enterprise IT administrators. In other words, no matter how you think of it, there’s always going to be multiple modes of delivery as enterprises grow and change and as startups get traction in any competitive environment.
Provisioning Hybrid Cloud and Multicloud Resources
IT leaders must enable a more efficient response to multiple requests and multiple modes of delivery. They must leverage emerging technologies and vendor resources that meet the needs of today’s enterprise.
Enterprise IT must do more with less and deliver resources faster to remain competitive. Here are some examples of what enterprises are using now:
There are multiple software-as-a-service (SaaS) solutions available from cloud providers that enterprises use to do business like managing expenses with Expensify or tracking business management processes with NetSuite. Using these discrete resources are often part of a multicloud strategy for most enterprises but there’s not much provisioning there. You just give folks access and they run with it.
On the other hand, provisioning resources to build applications and services (even like the aforementioned SaaS apps) requires hybrid cloud strategies that include a mix of resources from multiple environments. Enterprises do this by leveraging automation tools that provision resources from multiple environments.
Infrastructure delivered quickly and specifically for application developers can be done by “chefs” or “puppet masters” using tools such as Chef or Puppet. There’s also Ansible. I’m still trying to figure out the analogy. Ssh, it might just be under my nose, but I can’t quite figure it out.
All three of these major tools are used for automating the process of infrastructure provisioning. These tools can be pointed to a number of environments in the cloud or on premises to stand up a combination of resources needed for developers.
Public Cloud and Private Cloud Resources
Public cloud providers such as Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine (GCE), and IBM Softlayer are available to get infrastructure up and running and can be used by the automation tools for setting up specific environments.
Private cloud and on-premises resources from vCenter, Hyper-V, OpenStack, and others can also be used by the automation tools. Resources from public cloud, private cloud, and on-premises environments can be provisioned, or in some cases, self-provisioned with user accounts often administered by IT.
As you can imagine, all of this provisioning from all of these environments can get quite complex to manage whether you’re leading a bimodal IT delivery model or not.
IT admins must ask the following:
- How much IT provisioning should users and user groups do on their own without core IT enterprise assistance?
- What infrastructure resources need to be governed or managed to meet business-critical initiatives for budgeting or compliance?
3 Blueprint Strategies to Alleviate Hybrid Cloud Complexity and Provision Resources Faster
IT and DevOps teams who do a lot of routine scripting can typically manage some of the complexity to get resources up and running quickly but that’s often not enough as an enterprise needs to scale. Relying on these individuals might not be ideal as their tribal knowledge is not easily transferable.
Instead, the enterprise can begin standardizing on a set of extensible, centrally managed blueprints that can be pre-architected with actions and configuration settings for IT admins to configure as much of, or as little of, the details required to provision IT resources.
These blueprints can then be made available to end users to provision what they need without having to know about the multiple, complicated environments of automation for provisioning as well as accessing all the available resources in public cloud, private cloud, or on-premises resources.
For example, here’s a catalog of blueprints from CloudBolt:
Consider the following three blueprint strategies to implement self-service IT strategies:
- Create Modular Actions
- Control Configuration Settings
- Show Associated Costs
Create Modular Actions
When designing a blueprint, just like developing software code, it’s important to modularize your approach as much as possible so that what you use as an “action” like sending an approval request to an IT admin or getting the underlying password can be reused in multiple environments.
Here are some general actions to consider as examples:
Drilling down from one of these items, you can see how this organizational structure can be very helpful in provisioning resources.
Control Configuration Settings
As you determine what resources need to be totally standardized for end users, with size restrictions for any compute settings such as CPU, memory, or disk size, you can set it in the blueprint. On the other hand, you can make them available to set at “runtime” for the blueprint to use when deploying. You could even use orchestration settings that pick the best environment based on input from the end user.
Here’s an example of the settings for an AWS environment that only an IT admin sees. The admin can set the blueprint settings as “Provided” or “User chooses.”
Show Associated Costs
Being able to display costs that you set for specific resources or to retrieve the associated costs from public cloud providers for ephemeral use of specific resources helps end users determine a best fit based on their budgets. For example, here’s an example of some of the backend IT configuration to modularize the retrieval of costs associated with some of the main public cloud providers.
This level of control when defining what users get to select or that is automatically set along with associated costs helps IT admins control and govern the provisioning of multiple requests for multiple modes of delivery.