How to put your system in the cloud, keeping your head out of the cloud?

The text you are reading is the first part of a series of four articles in which I briefly but specifically describe the migration of existing IT infrastructure to the cloud environment.

I give examples based on the real process of migrating our software from the on premises environment to the Kubernetes / Openshift containerized environment, performed with the use of tools such as Jenkins (for automation), Jinja (for template), ELK Stack (for monitoring).

Although I am writing here about the migration of infrastructure, i.e. systems and applications to the cloud environment, and not about the migration of data from one system to another, it is worth remembering that these issues have a lot in common.

• There are many pitfalls in both processes related to the need to fully understand both the current solution and the target solution.
• They require the development of the migration process based on assumptions that take into account the characteristic features of the current environment and the target environment.
• Paradoxically, the most important thing is that in both cases old technological solutions lose their importance in favor of new ones, which may be associated with a change in the hierarchy of power, i.e. influences, competences, dependencies in the organization.

In this article, I present the stages and characteristics of migration, which are important in my opinion, and discuss the purpose of the entire project.

The following sections provide a more detailed analysis of these steps / aspects.

Why such a topic and why am I writing about it?

We have recently successfully migrated several million payment cards to our Advantica system in one of the largest Polish bank. It happened in a way that was imperceptible to customers.

This success made me reflect that, as an organization, we have been dealing with various types of migrations for over 20 years and that this experience is worth sharing.
On the one hand, I want to show our competences in this cycle, on the other - to refer to the real project experience in migrating the infrastructure we provide to the cloud.

As a business supervisor of the project, I had the opportunity to observe what elements affect the success or failure of migration and this is what I am going to share with you today.

A world of constantly new ideas

Every few years there are new ideas for changes to optimize the software development process:

• Omni-channel was fashionable for several years,
• then there was digital transformation and digitization of processes,
• then agile,
• and now there is a cloud.

Organizations are constantly changing and we adapt to current trends.
Are they always meaningful? Are they always worth introducing, even if it comes with huge costs?

Each idea has its light and dark sides.

Here I will highlight a few aspects that should be considered in cloud migration projects to avoid failure and not waste time and money.

Lanterns that will let you swing in the clouds

I am not writing here about which cloud is the best, or which containerized application management platform is worth recommending. Instead, I indicate reference points that are important in my opinion - lanterns, which will light up the bumpy road to migration.
For the project to be successful, it must be divided into the following stages - regardless of the adopted project methodology:

1. Inventory, that is, determining what infrastructure elements we have, how they are built, what their implementation process looks like, what features are they characterized by, what functionalities they are responsible for handling.
2. In the next step, we assess the real potential of the infrastructure for migration to the cloud, and before the migration, the production and delivery of applications should be embedded in the CI / CD process. We try to predict which applications will cause the most problems and which will be relatively easy to migrate.
3. Assessment of the team's capabilities. What mental competencies and qualities does a team need to be successful in a migration project? Do we have such people? Where to get them? Will outsiders help or hinder?
4. Guided by the knowledge about the system and the forecasts developed in the previous stage, as well as about the team implementing the migration and the conditions in the organization, we can prepare the first schedule. It is about planning which items can be migrated, how and in what order. You can immediately assume that not all elements are worth migrating, as the cost of migration will exceed the benefits.
5. A good starting point is to perform PoC (Proof of Concept), that is to migrate a selected element of the system as if "on trial". The PoC will help determine the probable time of the project and predict what potential problems were not taken into account in the theoretical analysis phase.
   The decision to implement PoC will allow you to verify the team's capabilities - whether its competences are sufficient, whether the composition is optimal, whether communication in the team is not flawed. This is valuable information that we don't know how to get until we start migrating specific applications. Which brings us to the next essential element:
   If people, then the process, so:
6. project management methodology and why agile. While for years (and I have been participating in agile projects since 2013 - really!) I was skeptical about this approach, in this case I can finally see the real application of this methodology - it has found its place in such a project and it works! My skepticism was due to the fact that such projects took up much more resources and time than the PMI approach. With a clearly defined scope and method of implementation, there was no need to use an extensive project methodology. In the case of a project whose effect or scope is unknown at the beginning, the approach with the implementation and evaluation of small steps allowed for a relatively short period of time to verify the effect of work and adapt the route to current conclusions and experiences.

In my opinion, the implementation of the above activities is a condition of success. However, in order not to lose sight of the direction in which we should be going, we should also remember to answer the following questions:

1. What is the purpose of our project? So why do we carry out such a heavy and difficult undertaking?
2. How do we want to achieve this goal? So why do we choose a specific design methodology and specific technologies? Why do we adopt a given sequence of actions?
3. How will we then evaluate our actions? So how will we know that the project was successful?

Definition of the goal

Contrary to appearances, this element is not easy to define.
The goals of the company's management are different, the goals of middle managers (each of whom is responsible for a part of the entire system) are different, and the goals of people who directly maintain a given infrastructure are still different.

Business goals do not have to coincide with operational goals. But it is always about improving work efficiency and a better response to market needs that translates into profits. PR issues are also important.

Migration to the cloud itself, i.e. switching to a hardware platform outside the organization, getting rid of "scrap metal" - although treated as the main reason for migration, is not a key factor in my opinion.

Of course, it all depends on the scale of the organization. It may be more convenient and cost effective for small businesses to use external infrastructure. However, large organizations do not have such limitations, especially since the cost of maintaining infrastructure administrators is much greater than the cost of equipment. And regardless of the chosen platform, administrators will be needed.
So hardware is one dimension, the other - more important - is infrastructure and software maintenance and management.
In this respect, both the on-premises solution and the migration to the cloud have their advantages and disadvantages, and the purpose of the change is difficult to clearly define.
A more realistic goal in the case of migration is process automation, i.e. introducing solutions based on the principles of Continuous Integration (CI) and Continuous Delivery (CD) in the organization.

Streamlining the software distribution process from the developer to the production environment, where the functionality is made available to customers, is the primary goal of such a large undertaking.

From a business point of view, it is faster time to market.

From the operational point of view, this means saving resources that can be used, for example, to eliminate technological debt, improve the quality of software delivered through more tests, frequent implementation of software versions updated on an ongoing basis, thanks to which the quality of the infrastructure is higher.

The question: why do it, if the current solutions work, I leave it for a separate long discussion. You certainly already have an opinion on this matter.

In the next part of this article, I will go into more detail about the steps that I believe are necessary for a successful migration.

Stay tuned!