Cloud Zones: Into the comfort zone: How companies master the migration with cloud zones. Cloud Zones as a solution? To the rapidly growing demands on IT infrastructure in- meet, many companies have decided to migrate to the cloud. It is not uncommon for everything to happen very quickly.
Cloud Zones: This Is How It Works In The Cloud
However, there is a problem: How do companies create the right framework conditions when the applications that a company develops and operates in its own IT environments can be very different. Some are based on a very traditional technology stack, while others would benefit greatly from the possibilities of cloud services, managed Kubernetes, object storage and analysis services.
A good basis for starting the cloud journey and migrating many applications is to set up cloud zones. They provide an organizational and technical framework for the various requirement profiles defined independently of individual cloud platforms. Here teams can create, test and run applications? So it’s a great way to strike a balance between agility and control.
Listen To The Needs Of The Team
The change from on-premises to the cloud has far-reaching consequences, so it is important to collect the application teams from the start. Before defining cloud zones, it is worth asking employees about their wishes and needs for the cloud. This impacts the working atmosphere and the cooperation between the central cloud foundation team and the application teams, as the cloud zones can be developed close to their requirements in this way.
Define Cloud Zones
Do Cloud zones offer a framework for cloud applications to be developed and operated? And that regardless of the cloud platform. There is a clearly defined responsibility split between application teams and the cloud foundation in each cloud zone. This results in a uniform understanding of compliance. The following criteria are decisive for the definition of cloud zones:
- How is onboarding in the cloud designed?
- How much flexibility is needed?
- What does the underlying network model look like?
Building on this, one could, for example, distinguish between the following types of cloud zones:
Lift & Shift: As the name suggests, the Lift & Shift zone is aimed at more traditional IT workloads. Few standardized cloud services are required. Similar to the on-premise environment, these are managed centrally by the Cloud Foundation team. The onboarding process for application teams is therefore low-threshold, as flexibility is also limited. The connection to the company network is transparently provided for the applications by the Cloud Foundation team.
Cloud-Native: The strengths of the cloud unfold in the cloud-native zone. Your users have access to the entire service portfolio of the cloud provider (IaaS & PaaS). If you want to access the cloud-native zone, you have to prove cloud know-how. This ensures that users are aware of their responsibility and can live up to it. As a rule, such environments do not have a standard connection to the company network. However, this can be provided by the Cloud Foundation team as part of a managed service and controlled centrally.
Playgrounds: Playgrounds, also known as “sandboxes”, are primarily characterized because they do not contain any critical data or productive workload. Within the playground, developers can experiment with the diverse possibilities of the cloud without causing damage. The onboarding process should therefore be as simple as possible. Finally, playgrounds are also a good way to introduce cloud newbies to these technologies. It makes sense to limit the budget of such environments. This way, nasty surprises on the invoice at the end of the month can be avoided.
Implement Security Requirements Technically
One aspect that should not be overlooked under any circumstances when migrating to the cloud is security. If the requirements of the employees have been queried and then grouped in cloud zones, the question remains: How is the whole thing implemented technologically? The following three approaches can be used to implement the defined compliance requirements within the various zones:
Governance Model: A cross-cloud governance model is important to decide which cloud zone an application should be placed in. The model defines, for example, which information has to be requested during onboarding or what the account structure looks like. A uniform and automated implementation for all clouds are important for a good user experience.
Landing Zones: Landing Zones are a well-known construct to secure cloud environments. You configure the environments automatically to ensure that a basic security level is maintained. In contrast to the cloud zones, they are implemented on a cloud-specific basis, often with the providers’ native tools.
Marketplace Functionality: Especially in the lift & shift environment, often only selected services such as VMs or databases should be provided centrally managed by a cloud foundation team. To achieve a high degree of automation here, too, it makes sense to create an internal cloud marketplace through which these specific services can be ordered in their respective configuration in self-service.
Cloud Zones: Clear Responsibilities And A High Degree Of Automation
To successfully implement the cloud strategy, a clear goal must first be defined. There are two basic approaches to cloud migration: “Lift & Shift” and “Re-Architect”.
While lift & shift approaches often aim to pick up speed in the migration process and close data centers, re-architecting is used to make applications cloud-native to exploit the scalability and automation possibilities of the cloud fully. Although there are two different models, companies with different cloud zones can set the governance framework for the goals, regardless of the providers or specific applications used. This enables companies to build a truly sustainable and scalable cloud foundation. Because through clear responsibilities and a high degree of automation in governance, the teams in their respective cloud zone can focus on their core competencies.