Implementing cloud-native processes for cloud governance
Cloud-native has become a paradigm that stands for highly scalable applications. While it often relates to the application architecture, microservices, the use of containers or declarative APIs, being cloud-native comes with organizational implications as well. But first things first: Why do companies aim to implement cloud-native applications? they want to release better software faster and they want to be able to react faster in case something goes wrong.
Cloud-native as a competitive advantage
Let’s consider a rather traditional company like a bank. Banks have been using IT systems for years. Stability and availability of these systems is essential. Moving such applications that have been stable for years, do not evolve in terms of features and have no flexibility in their scale to the cloud does not necessarily bring any benefits. They will most probably not be cheaper nor more stable, when running in the cloud.
However, traditional industries like the financial services industry face strong competition, often from startups that aim to hit a market that has been stable for many years and has not really adopted to the technological development and resulting customer requirements or expectations.
In most cases these startups are cloud-native. They build digital applications in the cloud. With a strong customer focus, they are able to process customer feedback in fast iterations and quickly move towards a product their users like to use. In contrast to their established competitors, they have the great benefit to be able to move much faster, because they are not carrying a load full of legacy applications that they have to take care of in addition to their new product developments.
When building new customer-facing applications, having capabilities in cloud-native software development is a competitive advantage. New products can be built faster, continuously improved and adopted to customer needs. Instead of having new software releases yearly or twice per year, CI/CD allows us to integrate product updates on a daily basis. For this reason, a lot of traditional companies from different sectors, experience high pressure to digitize their business models and move to the cloud, in order to hold on to their position in the market and avoid customer retention.
Why cloud-native is relevant to the organization
Cloud-native is not only about the use of cloud platforms. Software architecture and additional tooling, like CI/CD or other automation tools play an important role, when leveraging the benefits of the cloud. In addition, in an enterprise context organizational processes are another challenge on the way to cloud-native success.
One of the main reasons developers love cloud plat- forms like AWS, Azure or Google Cloud Platform is that they can access a large variety of different cloud resources and services within minutes. They just need to create an account, pull out their credit card and are ready to get going. For enterprises, cloud providers offer organization accounts that group together accounts across the organization.
In many cases, developers are not allowed to create an account belonging to the organization in self-service. They have to go through some specified account provisioning process. For this purpose, enterprises often reuse existing tools or processes that originate from older times, e.g. from ordering on-premise IT hardware like monitors or phones. The risk is that the original cloud-native experience is being affected, as barriers are posed between the developer and the cloud.
Setting up new processes for the use of cloud is important for multiple reasons:
Loss of productivity
Slow processes for cloud access impact the time-to-market for new applications. Letting developers wait for weeks or months to gain access to their required resources is a waste and enemy of productivity.
Risk of shadow IT
Not only do slow processes slow down application delivery, they bear a great risk for shadow IT as developers may find other and faster ways to get to their cloud environment. It is not uncommon to find cloud costs in travel expenses for that reason. Apart from the uncontrollable cost, those accounts are completely under the radar of company regulations.
Automated processes are scalable and bring benefits in terms of consistency, e.g. in security configurations. In contrast, manual routine-processes are error-prone and can hardly be controlled. Furthermore, they mostly don’t keep up with the rising demand of IT resources, leading to bottlenecks and even longer waiting periods.
Negative impact on employer attractiveness
In times of skill shortage, being attractive as an employer plays an important role when it comes to hiring IT talent. Organizational processes reflect the agility of the organization as a whole. If a company is not progressive in their organization, it’s likely that they are neither in their visions and the use of technology.
If you do it for one cloud, you should do it for all
We often face situations in which different clouds, such as Azure, AWS or GCP are treated as completely distinct silos. Processes (e.g. for access, tenant creation or cost management) are reinvented for each of those platforms, missing an integrated and comprehensive concept of how cloud is going to be used across the organization. This does not only require more resources for the implementation, it results in missing transparency from a holistic and strategic perspective.
– How do I proceed in my cloud transformation as a whole?
– How many applications have I migrated to the cloud?
– How does my cloud spend evolve and behave across platforms?
– How does the performance of different teams differ in terms of cloud migration?
– How do I ensure a consistent level of governance across different cloud platforms?
– How do I find a balance between individual requirements and services that should be standardized throughout the organization.
Having cloud silos, the information that is necessary to answer the above questions is missing or has to be assembled with a lot of manual effort, which again requires costly resources and much worse, is prone to error.
The spirit of cloud-native principles
In software development, the term cloud-native is related to certain design principles1:
– Designed as loosely coupled microservices
– Best-of-breed languages and frameworks
– Centered around APIs for interaction and collaboration
– Stateless and massively scalable
– Resiliency at the core of the architecture
– Packaged as lightweight containers and orchestrated
– Agile DevOps & Automation Using CI/CD
While there are variations on single items, depending on the source, the core of the principles stays the same. Scalability is one of the main aspects of cloud-native applications and often the shortage when it comes to organizational processes.
This is natural, because the use of cloud usually starts small in single departments and therefore does not initially require a comprehensive and scalable organizational strategy. Processes can be kept simple and pragmatic to incentivize the use and experimentation with new technologies and reduce administrative overhead at this stage. Therefore, early adopters often experience some kind of protection, as consistent rules still have to be defined and implemented.
At some point however, there is a need to collect the di- verging cloud initiatives across the organization, as it otherwise becomes impossible to keep control of compliance and cost. Processes have to be well documented and auditable in order to be ready to run in production.
What the organization can learn from cloud-native development
One of the cloud-native design principles is related to the use of best-of-breed languages and frameworks. Therefore, technological freedom is one reason to provide multiple cloud technologies and platforms to the DevOps teams.
Considering the market development of cloud-native tools and services, the past years have been very dynamic. And while the amount of cloud providers has been rather stable, the services they offer evolve and change continuously. Choosing a single specific technology to provide to DevOps teams bears a high risk. In order to stay flexible and be able to adapt to technological changes, processes should be independent of specific technologies. DevOps teams should experience freedom and be able to work with their preferred tools and it should be possible to integrate new upcoming technologies.
Fig. 2: When providing agility, it is important to implement some control and security mechanisms at the same time. (Photo by John Salvino on Unsplash)
Automation and APIs
Automation is one of the main drivers of cloud technologies. Therefore, the processes for using cloud shouldn’t block the access to the native cloud APIs, e.g. by providing cloud resources via an additional cloud-service portal and not allowing access to the cloud-native portals. Apart from not being automation-friendly, such setups have the dis- advantage that each service has to be integrated individually, which is very resource-intensive and leads to time lags regarding the availability of new services.
Stateless and massively scalable
In order to be horizontally scalable, applications should be stateless. meshcloud, a platform for enterprise-level cloud management and governance, has developed a cloud maturity model2 that introduces the idea of “organizations as code”. The idea behind that is following from “infrastructure as code”, where you define the target state of your infrastructure. Similarly, you can define the target state of your organization, including information like the project that exist in each cloud platform, which users should have access to them, and which policies should be applied. Using this paradigm for organizational processes has the benefit that it is very robust and scalable, and it is independent from specific technologies. Furthermore, it integrates essential documentation steps that can be helpful when it comes to audits.
A final aspect that shouldn’t be neglected is that such a bold move towards agility in the organization should on the other hand be balanced with security measures. In the past years, we have seen that most security incidents, e.g. Capital One’s loss of personal data of one million people are due to faulty configurations3, in this case a firewall misconfiguration. While it’s impossible to stay 100% secure, a good approach is to provide a basic security level when handing out cloud accounts to DevOps teams to prevent the teams from basic mistakes. This can be done by so-called landing zones4 that restrict the of the cloud account in accordance to security regulations.
Motives for using cloud-native technologies are scalability of applications as well as fast iterations in application development that allow to continuously integrate customer feedback and evolve along customer needs.
When it comes to provisioning cloud technologies across large organizations, there are different ways to de- sign and implement processes around cloud governance. In order to be successful and leverage the benefits of the cloud, these processes should have a cloud-native spirit: They should provide autonomy and allow for technological freedom of the user, while keeping the balance with security measures and controls.
– 1. https://medium.com/walmartlabs/cloud-native-ap- plication-architecture-a84ddf378f82
– 2. https://www.meshcloud.io/en/2019/02/04/the- path-to-proper-multi-cloud-management-a-maturity- model/
– 3. https://techcrunch.com/2019/07/29/capital-one-hacked-over-100-million-customers-affected/
– 4. https://www.meshcloud.io/en/compliance-and-se- curity/