Preparing your cloud environment: how to do it?

 

How to proceed systematically when it is necessary to prepare the cloud environment for the migration of workloads and applications?

Lukáš Hudeček

 

It’s basically the same as when we build a house for which we have prepared a project and a budget. First, we need utilities (such as electricity and water), a secured access road to the property and a concreted foundation slab. Only then can we build the individual floors and finish with the roof. It is the same with the preparation of the cloud environment – here too we start systematically from the beginning.

 

In this article, I’ll walk you through the steps to prepare your cloud environment for application migration. These steps are also called landing zone preparation. Those who start building from the first floor, without a base slab and utilities, usually have no choice but to demolish the building and start again from the beginning.

 

 

Processes and modifications for cloud scenarios

First of all, we will modify or analyze existing processes with regard to their use in the cloud.

This step includes, for example, an assessment of the existing set of IT service management (ITSM) guidelines and processes, such as change management, incident management and problem management.

From a security perspective, we will focus on security policy modification, business continuity management and the inclusion of cloud processes. We also assess the compatibility and capabilities of existing tools to support cloud operations.

From a capacity management perspective, I then need internal people to get to the skillset needed to support cloud operations in a certain amount of time. Last but not least, we deal with securing the necessary know-how from suppliers.

 

Architecture and its extension

We will extend the existing architecture with a new cloud environment. We are deciding how to make the connections and whether we need them at all. We determine which types of workloads and applications we will run in the cloud, which environments we will move to the cloud (DEV, TEST, PROD) and how robust the cloud environment will be in relation to SLAs and Business Continuity.

In terms of architecture, we focus mainly on:

• Defining new standards from architectural blocks to the creation of entire artifacts. Here I can start from the reference architecture that every cloud provider has publicly available.
• Define operational policies so that administrators cannot deploy anything, anywhere, and have maximum service size limits (or cost limits) set.
• Definition of Azure Managment Group and sub-scripts. In the case of AWS these are Organization Units and Accounts. These basic elements are used to divide the environment according to various criteria such as DEV/TEST or shared resources, unique resources, security requirements, etc.
• Subsequent creation of blueprints – templates that describe the environment and in which all parameters are recorded (IaaC). Or it can be an extension of an internal service catalog (such as Azure ARM templates and AWS Cloud Formation).
• CICD – using a deployment management tool and code repository (Azure DevOps, AWS CodeBuild and AWS CodePipeline).

 

Security and cloud compliance

Security in the cloud is another big topic. Until a few years ago, I used to say that “the cloud is insecure” because everything is accessible from the outside internet and “I don’t have the data on me”. Fortunately, these views have long since been abandoned.

The big cloud players meet all possible standards, including ISO 27001, CIS Benchmark, etc. It is only necessary to implement them correctly. With policies and automation, I can easily deploy and configure Azure Security Center or AWS Security Hubeven in large environments.

Using AI and automation, you can quickly identify threats, simplify investigations and help you automate remediation actions. Alternatively, you can incorporate a SIEM system, such asAzure Sentinel, which can combine events from all systems to detect risks.

The cloud offers several layers of security, both on the user account side and on the system itself:

• From the user account point of view, it is ideal to use SSO, where I have one account for all running applications, and this is secured at least by MFA authentication, preferably in combination with Conditional Accessand Device management. This solution allows you to define many access conditions according to different states, for example including geolocation.
• On the application side, I can use various WAF solutions with L4/L7 Application Firewall and DDos protection. I can also encrypt data at the filesystem and database level. Logs from these components also end up in the security center or in the SIEM solution.

 

 

Roadmap as a map of progress over time

The roadmap is important for overall planning and evaluation. It includes a timeline of projects that will occur in the coming months or years. It is used for duration estimation and follow-up management in individual projects.

The implementation plan covers all the topics mentioned above and below and includes:

• Definition and coverage of all necessary architecture, security, compliance and governance standards.
• Preparing a landing zone where we have set at least the minimum requirements to start migrating applications.
• From an application perspective, we have at least analyzed basic data such as application lifecycle, KO criteria, application complexity and criticality, and the extent of integrations. This topic was covered in more detail in the previous article How to get your apps into the cloud.

 

Cloud governance as definitions and policies

In the governence section we define standards and procedures. These are usually extensions or mirroring of processes and settings from the on-premise part.

We focus mainly on the following areas:

• Azure Management Groups and subscriptions, in the case of AWS Organizations Groups.
• Naming conventions – standards are described on the Internet, and are usually formed by prefixing or suffixing the source name. Be careful here – not every created object can be simply renamed. Before we know it, a debugged test will suddenly be elevated to production, and the various mangled names will remain resources forever and lead to confusion.
• Tagging – we create additional information that can be used to enrich the resource e.g. the owner or the environment to which it belongs. However, I would be careful with that too. I’ve even experienced an admin account including a password written in a tag.
• Operational policies – Evaluate the current configuration of resources against the policy definition.
• Responsibilities – Assign roles within the implementation, architecture, security, support, application deployment, etc. teams.
• Standards – mainly technical.
• CICD tool implementation – see picture.

 

 

Cost management and financial management

As soon as we touch on finance, all the managers say, “It’s going to be money again!” Planning finances and calculating TCO in years is now a routine activity for most organisations. Cloud services include monitoring and predicting consumption based on trends. It is important to continuously evaluate consumption and optimize resources in the following ways, for example:

• By reserving power for 1 to 3 years. Here it is necessary to think carefully and calculate whether the purchased power will actually be consumed in the long term.
• Shutting down processes that run a few hours a day or once in a while; typically non-productive resources.
• Optimising the use of resources according to measurements. This is where there is usually the most room for savings. For optimization I can use specialized software like Densify.

 

 

Landing zone as our base plate

Landing zone is a ready area where I start migrating applications and workloads. What we have described in the previous sections, I am implementing in the landing zone.

I have designed the architecture, i.e. the way I will create objects, and I have defined the components I can use. My environment is divided into management groups and sub-scripts. I have built a network topology, IP addressing and VPN connection. I have implemented Access and Identity management in Azure (RBAC).

I’ve defined naming conventions. I prepared the blueprints so that I could deploy individual components customized to the organization’s standard and defined and set operational and security policies. I have set up log management and environment monitoring and set spending limits in cost management, according to individual criteria.

So we can start building our new fully virtual and automated part of the infrastructure.

 

 

You are not alone in your preparation

Take this article as inspiration to get you started with cloud preparation, a discipline every organization must complete before migrating workloads and applications. The whole topic is of course more complex and certainly does not fit into a few pages.

As mentioned, it is necessary to start by building the foundations and continue layer by layer according to the established roadmap up to the planned migration of applications.

Big cloud players like Azure, AWS and Google have defined cloud adoption frameworks to facilitate and support cloud deployment. There are financial incentives and programs that can help you adopt. At the same time, there is a described reference architecture and a huge number of templates and definitions, even on Github.

In the next article of our series, our colleague Jakub Procházka will focus on the topic Costs in the cloud. For more chapters, check out our Cloud Encyclopedia – a quick guide to the cloud.

 

This is a machine translation. Please excuse any possible errors.