How do you prepare to enter the cloud?

Kamil Mrzygłód
Calendar icon
2 czerwca 2021

The topic of migration to the cloud is one of the most popular topics not only during many presentations or conferences, but is also one of the most popular inquiries from customers interested in increasing the flexibility of their infrastructure and applications.

On the one hand, there is no surprise - in the era of a huge increase in interest in cloud topics, which is further fueled by the pandemic situation related to COVID-19, many companies have had to accelerate their plans to adopt cloud technologies. On the other hand, the cloud is still a challenge, and despite its widespread use, it still poses a non-trivial challenge, especially for all those organizations for which the technology is not a source of income (here we need only mention the recent fire at OVH's data center in Strasbourg, which destroyed one building, damaged another and put two others at risk, leaving many customers in the proverbial lurch). But leaving aside all the pros and cons when it comes to the cloud, the following question always arises in the context of migration - how should we prepare our organization for migration and what should we pay attention to in order to make as few mistakes as possible?

Understanding your business

Before we make any decision about the cloud, we need to understand what we really expect and what we want to gain by committing resources to the cloud migration process. It is important here not only to prepare an appropriate cost calculation, but also the expected rate of return on such and not other investments. Let's look at the following example:

tabela1.webp

The calculation assumes the average power consumption of a server per hour as 500 watts and 10 servers supporting all virtual machines. In addition, it was assumed that cooling the server room consumes 10% of the energy used by the physical servers. In the case of maintenance, a 24/7 model spread over three FTEs of 8h each was assumed with a gross UoP of 13,000. Unless otherwise stated, the amounts presented are net.

In the table above, we have included only expenses that do not depreciate over time - for a complete picture we would additionally need the base cost of the server room (physical infrastructure in the form of a room / building, the cost of the power connection, fire protection, burglary protection, physical security), but for the sake of simplifying the accounts this cost will be omitted at this point. What is important, however, is that we need to understand which cost when fully migrated to the cloud disappears and why. For the sake of comparison, let's now present a comparable example, but with a translation to a cloud provider:

tabela2.webp

The calculation assumes a virtual machine equipped with 8 vCPUs, 32GB RAM, which is designed to run applications without high CPU, memory and disk performance requirements.

The above example immediately illustrates the following conclusions for us:

  • The use of cloud technology without having its own infrastructure results in the elimination of monthly costs associated with connection infrastructure from the calculation.
  • The use of virtual machines in the cloud leaves us with the requirement to have a staff responsible for the maintenance of these machines.
  • The cost of virtual machines in the cloud can exceed the cost of local infrastructure, which is particularly expensive in the first year of use.

Let's note one important element here - the above calculations will not be 100% in line with reality as long as we do not supplement them with the missing elements and superimpose the actual state according to our organization:

  • The cost of maintenance of the local server room (replacement of equipment, installation of new machines, minor breakdowns).
  • An accurate reflection of the performance of local machines in selected virtual machines (depending on the model of the processor, memory or disk, the cost of theoretically the same virtual machine can increase by up to several tens of %).

However, regardless of the above assumptions, the examples presented present us with a rather important thesis - in the case of migration to the cloud, the cost argument should either be a less important element (despite the fact that often migration to the cloud allows restructuring and real savings), or the cost in this case should be redefined and treated on a par with expenses such as electricity or licenses.

Why do we talk about cost at the very beginning? It is related to understanding the actual needs of our company. The cost argument in the case of migration is rarely a meaningful argument, as it does not address the real need for migration, which is carried out wherever we are looking for one of the following:

  • Increased infrastructure flexibility.
  • The ability to easily tie costs to a specific application.
  • Accounting for one's portfolio with actual existing solutions rather than theoretical considerations.
  • Avoiding oversizing the infrastructure.
  • A realistic chance to change the ratio of R&D costs to maintenance profitably for the former.

Although many of the following points contain the word "cost," they are not talking about cost per se, which boils down to standard cost optimization of corporate expenses. They focus more on the greater granularity of recurring billing (which makes it easier to manage the budget) or linking the real cost incurred to the degree of infrastructure rollout, as we could illustrate with the chart below:

cloud-wykres-1.webp

As we can see above, the cloud lowers the initial cost to be incurred when preparing the infrastructure of a new system, but it is far from offsetting it to zero, especially if we do not have specialists in this technology on our teams.

For what other reason would we as a company want to start cloud adoption? If we now leave aside the aspect of cost and the need to maintain our own infrastructure, we are still left with issues that are closer to business-technology topics:

  • The simplicity of preparing test environments and those intended for prototypes that are short-lived (so-called ephemeral environments).
  • Simplicity of scaling applications according to real demand, which saves on oversized infrastructure and addresses the problem exactly when we need it.
  • Facilitated geo-replication and high availability of our infrastructure without the need to set up our own offsite server room.
  • Availability of advanced technologies without having to install and configure them on our own machines.

The above points, when properly interpreted, will also ultimately boil down to better disposition of expenses in our organization, while increasing its competitiveness and dynamism. Greater dynamism means easier adaptation to changing market conditions and the ability to react instantly to emerging and disappearing trends. These are exactly the values we should consider first if we want to include the cloud in our investment plan for the coming years.

Choosing a provider

Another point related to the adaptation of cloud computing is a thorough analysis of the market with suppliers and their offerings. It is important here to build in your mind the idea that the cloud does not end with the offerings of the three largest providers (Amazon, Google, Microsoft) and many smaller players are coming out more and more with their own proprietary offerings, which in many ways can prove extremely tempting. Regardless of our personal preferences or marketing materials, it is important to ask each vendor a few questions:

  • Does their offering reflect our technology stack - if we are a company focused on Java, for example, will we be able to run all our systems there without a problem?
  • Do they offer data centers in the geographic locations we are interested in - sooner or later there will be regulations that will force us to process data in the regions where it was collected. If our provider is unable to offer us the location we are interested in, it could block us when it comes to expanding into the next market.
  • What support models are offered by the vendor - if we are moving our infrastructure to managed components, we will need efficient support that is able to respond to our requests according to a well-defined SLA.
  • How stable their offerings are - the worst thing we can choose is a vendor that is just stabilizing the available products and offers no guarantees about their further development.
  • How efficient and flexible our provider's infrastructure is. Let's remember that each data center will run applications of different customers, where each of them has different expectations of availability and different characteristics of hosted applications. At the time of increased traffic in our application (and thus increased demand for computing power), we want to be sure of the stability not only of our solution, but also of the cloud infrastructure.

Since cloud technologies have a myriad of components it can be very helpful at the bid analysis stage to hire a consultant who can assist us in the inventory of our resources and its evaluation. If this is especially important if we are personally inexperienced with the subject and have no intuition as to how the various costs are actually distributed and what difficulties we will encounter depending on our choice.

Inventorying our resources

Migration to the cloud could not take place without understanding what we actually want to move from our local environment to an external data center. To do this, we will need the cooperation of not only the development teams, but also those responsible for maintaining legacy services, our network administrators or security engineers. It will be extremely important not only to understand the current state, but also to plan the so-called landing zone. A landing zone is nothing more than a starting point that serves both as a destination for initial migration operations, but also as a place to explore further possibilities. To complete the migration picture, we need to decide on a cloud model that is of particular interest to us:

  • A public model, in which all of our infrastructure is hosted within our provider's cloud infrastructure, which is publicly available and shared with other users.
  • A private model, in which we get dedicated network solutions delivered only to selected customers and the entire infrastructure is separated from the shared portion.
  • A hybrid model, in which we combine a number of different cloud models (or include a connection to an existing on-premises environment).

The choice of model is often strictly dependent on the characteristics of our company (different requirements are in the medical sector, another in e-commerce, yet another in retail), our financial capabilities (private solutions are definitely more secure, although at the same time several times more expensive) or general internal requirements and audits. Many customers opt for the method of small steps when we first migrate simple applications to the cloud with unadvanced requirements, through which we build the foundations of the future cloud infrastructure.

Here we return to the notion of a cloud landing zone, which in most cases boils down to deploying a few applications in a way that immediately validates our assumptions at the network and conceptual level. If we detect shortcomings in our vendor at this point, we still have a chance to either redesign our current solutions or change to a vendor that meets our expectations. Contrary to appearances, the level of complexity of operations to migrate even small applications to the cloud cannot be ignored. Many systems built to run on on-premises environments have not had to face issues such as constant migrations between machines, multi-tenancy, constant IP address changes, higher scalability requirements. With one of the main assumptions of cloud architecture in the back of our minds, i.e. "the cloud is a state of permanent failure," we have to reckon with the fact that simple lift & shift migrations work very rarely and rather only for applications hosted directly on virtual machines. Any deviation from this rule (such as migrations to a PaaS model or a managed Kubernetes cluster) multiplies the risk and, without taking it into account beforehand, results in an underestimation of migration costs.

Ready-made frameworks

Cloud providers are aware that cloud adoption in an organization is a costly and lengthy process that requires meticulous planning and profit and loss analysis. Fortunately, we can find ready-made frameworks on the web called CAF from Cloud Adoption Framework, which break down the migration process into several elementary components:

  • Strategy definition
  • Planning
  • Achieving readiness
  • Adaptation
  • Control
  • Management

Depending on the cloud provider you choose, CAFs may differ slightly from others, but nevertheless, at the core, they serve the same purpose - to help organizations go through the migration process by "forcing" them to write down a migration strategy and evaluate current risks like, for example, existing know-how in the company, resource inventory or planned landing zone. Some frameworks have ready-made benchmarks that allow us to evaluate specific areas and focus on places that need definite improvement. Often mentioned, it is also important to hire the right partner who has experience in cloud migrations and is able to support us not only in technical terms, but also possible legal complexities that may arise if we want to move our infrastructure and data offshore.

Summary

Migration to the cloud is an issue that every company should prepare for without haste and avoid making decisions under the influence of emotions. Unlike many technological innovations, the cloud is not a passing fad and will dictate the direction of many IT systems and products for years to come. Enormous flexibility, easy cost control, facilitated development or a base of ready-made components from which you can assemble your application are things that are hard to ignore with so much competition in current markets. On the other hand, the cloud also means risks - lack of full control over the infrastructure, dependence on the vendor, as well as the often complicated procedures involved in delivering software to a managed infrastructure are things you have to take into account when giving up traditional local infrastructure. Regardless of our choice, however, the percentage of companies that have successfully completed the migration process is growing by the day, and the pandemic mentioned at the outset has only accelerated this trend. This clearly indicates a growing confidence in the technology and shows that the entire process can be passed even under such extreme conditions.

Read also

Calendar icon

18 styczeń

How to prepare for the ISTQB® Foundation Level exam?

How toprepare for the ISTQB® Foundation Level exam? Check valuable tips before taking the test.

Calendar icon

11 styczeń

Funding from KFS for training in the year 2024

From the article, you will learn about the KFS budget in 2024, understand spending priorities, and find out how to apply for funding.

Calendar icon

7 grudzień

Dotnet Summit 2023 (online) - December 18, 2023

This autumn, on December 18, 2023, the Dotnet Summit 2023 (online) will take place, this time in the form of an online conference!