It has been more than 10 years since Cloud Computing was first introduced to the world.
With widespread cloud adoption nowadays, more and more enterprises are having Cloud Engineers, DevOps Engineers, CloudOps, or even Rockstar Developers, DevOps Ninjas, Cloud-Native Evangelists.
Gartner predicts that cloud-native platforms will serve as the foundation for more than 95% of new digital initiatives by 2025 — up from less than 40% in 2021.
With the ever-increasing number of cloud services and the skilled professionals joining the enterprises, the diversifications of components employed on the cloud tend to be increased dramatically. The more cloud-proficient the enterprise is, the more pronounced effect on the diversifications.
It is inevitable that at some point, without good governance of how to use the cloud, accumulated diversifications will force the enterprise to struggle just to maintain the existing workloads on the cloud.
If just maintaining that much diverse cloud services, with different patterns, different skillsets, in order to just simply add more applications or services on to the cloud may have huge impact to the operations. So, the next cloud migration rounds would be much much harder.
Cloud Governance is not only about control, but it can also be used to enable and accelerate enterprise cloud adoption too. Let us explore how it can be done.
Control the usage of cloud services in the enterprise
There are now hundreds or even thousands of services available on the cloud. How can any team keeping up with all of those services, let alone controlling how to use each and everyone of them?
The short answer is you don’t control it. You just have to find a way to govern it, and make it such a way as to enable the enterprise to reap the benefits of the cloud.
Cloud Governance Approach
There are so many flavors of cloud governance from reputable consulting firms. However, there is no silver bullet, and it really depends on each enterprise.
If the enterprise is already cloud-proficient, or already started working on the cloud migration, then this might be an idea of how to govern it.
The focus is on how to “enable” the cloud adoption, with embedded policies and guardrails, and with methodologies and tools to continually optimize it.
And if the enterprise already has the Cloud Center of Excellence (CCoE) team, it would be a good place to put the governance function in.
This governance aims to tackle end-to-end of cloud adoption cycle, starting from “which” applications should we consider adopting the cloud, “what” should be the cloud resources or architecture to adopt, all the way to “how” to optimize the cost that already provisioned on the cloud. The users are on the left hand side of the diagram (i.e. Teams in the enterprise). The governance function is on the right hand side of the diagram (i.e. Cloud Center of Excellence). And the flow starts from the bottom to the top:
We will look into each of them one-by-one in the next section.
Standard & Governance
Instead of letting Rockstar Developers or Cloud-Native Gurus to come up with their own cloud-service-of-choice, why not having a guideline on how to select and choose which cloud services to use in the enterprise. However, there are quite a number of factors to be considered:
However complex they are, the CCoE should try to find a way to pack these factors into some kind of Ready-To-Consume Guideline, so the other users in the enterprise (e.g. Application teams, Enterprise Architect teams, IT Security teams) can use it effectively.
The Guideline should provide systematic and standardized way to adopt the cloud, by providing:
let us walk through them:
1.Fit For Cloud: how to determine if the application (whether new or existing) should use the cloud? It can be enterprise policies or regulatory or other considerations. The key point is to spell it out clearly so that users can follow it unambiguously.
2.Migration Strategy: determine what would be the migration strategy to move existing applications/workloads to the cloud. We can also adopt from the standard 6R Migration Strategy.
3.Referenced Architecture: this will be the key of how to translate the policies into actual architecture. We do not have the include each and every single possible architecture on day-1. We can gradually build the referenced architecture as we go, or MVPs if you will. The key is to provide the proper guideline and examples for the users to choose the right architecture.
4.Cost Estimation: based on the referenced architecture, we can create a template for cost estimates. For some of the components, we might need to put in parameters as well, for examples how many Tera Bytes of storage. This will serve not only as the cost estimates for the project to make decision, but also the cost baseline when we try to manage the on-going cost and growth accordingly.
This will be the center-piece of the whole governance. It is about finding the answers to “how to gain both speed and control when provisioning cloud resources”. Let us determine these scenarios:
Scenario 1: Central Cloud Operation Team to provision cloud resources
Pros: Ensure adherence to standard policies and IT security requirements
Cons: Central team would become a major bottleneck if it could not scale effectively. Also, the risks of human-errors.
Scenario 2: Users can provision cloud resources themselves
Pros: Speed. Mitigate bottle-neck.
Cons: Challenges in proactively control the adherence to policies and IT security requirements. Also, the risks of human-errors.
It is quite clear that we will need some kind of tools, and of course, Infra-as-Code (IaC), to automate the provisioning of cloud resources. This is where CI/CD Pipeline + Infra-as-Code can be the answer.
By using CI/CD Pipeline + Infra-as-Code + Referenced Architectures, with the right templates that embedded control of policies and IT security requirements, we can quickly and safely provisioning cloud resources with all the guardrails built-in.
Infra-as-Code could be in the form of the cloud service providers tool-of-choice (e.g. AWS CloudFormation, Azure Resource Manager, GCP Deployment Manager, or go neutral like HachiCorp Terraform). Using it with the CI/CI Pipeline tool like Gitlab + Jenkins + Terraform, or even sprinkle in some SecOps tools like SAST or DAST, will complete the picture of embedding policies and guardrails into the self-service provisioning tool.
Now, the Application Teams or even Full Stack Developer Wizards can just simply push the code, and let the pipeline auto-provisioning the cloud resources for them. Central Cloud Operations team can use their time to optimize or add more Referenced Architecture to make the pipeline even more useful. Everyone is happy.
Cloud Resources Cost and Usage Optimization
One of the most powerful deciding factors of adopting cloud technology is Cost. The ability to translate CAPEX into OPEX is very attractive. Enterprise can use pay-per-use computing power, just like electricity or other utilities, without the need to invest upfront.
However, using cloud does not always mean that it will always be cheaper than on-premise.
It depends on the scenario and the state of the enterprise. If you are in a big enterprise that already invested in the data centers or hardwares, you may already leverage on those sunk cost. However, if you are in a startup companies, just rent those computing powers (that already includes the cost of world-class data centers, cutting-edge hardware and technologies, physical securities) would be much more attractive.
However, no matter which scenario your enterprise is in, you can always optimize your cost further with these methodologies:
Put the tag to all your cloud resources, so you can identify where it came from, so you can review growth-rate, anomaly is consumption, or even charge-back to users.
This is standard-practice for all cloud service providers. It mostly employs the same principle of discount based on usage-commitment.
There are many tools to support this method, for example:
How to choose which one is the best to use? Well, you don’t have to choose. You can apply them all together based on your usage patterns.
With the above ideas of governance, starting from “which” applications should we consider adopting the cloud, “what” should be the cloud resources or architecture to adopt, all the way to “how” to optimize the cost that already provisioned on the cloud. It also provides the self-service automation tool for users to use the cloud. The governance should “enable” the enterprise to adopt and reap the benefits from the cloud instead of controlling and restricting it.
However, there are also other aspects that also support the cloud enablement, for examples, the skills and community development, the delivery process and many other things. That could be the topics for future articles.
Hope the Cloud Governance ideas in this article bring some usefulness to enable and accelerate cloud adoption in your enterprise.
standard disclaimer: This article expresses my personal views, which implies I am responsible for them, not my employer or another agency. Any posts reflect my opinions and are not an endorsement.