Preparing your cloud environment: how to do it?

It's basically the same as building 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 concrete 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 preparation landing zone. Whoever starts building from the first floor, without a base slab and utilities, usually has 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 analyse existing processes with regard to their use in the cloud.

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

From a security perspective, we will focus on security policy modification, business continuity management and cloud process inclusion. 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 are dealing with securing the necessary know-how from suppliers.

 Architecture and its extension

The existing architecture will be expand to new cloud environments. 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.

From the architectural point of view, we focus mainly on:

• Definition of new standards from architectural blocks to the creation of entire artefacts. Here I can start from a reference architecture that every cloud provider has publicly available.
• Definition of operational policies so that administrators can't deploy anything, anywhere, and have limits set on the maximum service size (or cost limits).
• Definition of Azure Managment Group and sub-scripts. In the case of AWS these areOrganisation 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 catalogue (such as Azure ARM templates a AWS Cloud Formation).
• CICD - using the deployment management tool and code repository (Azure DevOps, AWS CodeBuild a AWS CodePipeline).

Security and cloud compliance

Security in the cloud is another big topic. Until a few years ago, I used to hear 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.

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

Use artificial intelligence and automation enables you to quickly identify threats, simplify threat investigation and help you automate remediation actions. Alternatively, you can integrate a SIEM system such as Azure Sentinelthat can combine events from all systems to detect risks.

The cloud offers security in several layersboth on the user account side and on the system side:

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

Roadmap as a roadmap of progress over time

The roadmap is important for overall planning and evaluation. It contains 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 discussed in more detail in a previous article How to get your apps in the cloud.

Cloud governance as definitions and policies

In the governence part define standards and procedures. Most of the time it is an extension or mirroring of processes and settings from the on-premise part.

We focus mainly on the following areas:

• Azure Management Groups and sub-scripts, 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 object created can be simply renamed. Before we know it, a debugged test will suddenly be promoted 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. about the owner or the environment to which it belongs. However, I would be careful with this as well. I've seen, for example, an admin account including a password written in a tag.
• Operational policies - Evaluate the current resource configuration against the policy definition.
• Responsibilities - Assign roles within the implementation, architecture, security, support, application deployment, etc. teams
• Standards - mainly technical.
• Implementation of the CICD tool - 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 continuously evaluate consumption and optimise resources, for example, in the following ways:

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

Landing zone as our base plate

Landing zone is ready desktop, where I am starting to migrate 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 process of how I will create objects, and I have defined the components I can use. I have the environment partitioned by management groups and sub-scripts. I have built a network topology, IP addressing and VPN connections. I have implemented Access a Identity management in the case of Azure (RBAC).

I've defined naming conventions. I prepared blueprints so that I could deploy individual components modified to the organization's standard, and I 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 each 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 for your start with preparing the cloud environment, a discipline that every organisation 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 roadmap until 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 with adoption. At the same time, there is a described reference architecture and a huge number of templates and definitions, for example on Github.

In the next article of our series, our colleague Jakub Procházka will focus on the topic Costs in the cloud. Further chapters can be found in our Cloud Encyclopedia - a quick guide to the cloud.