Cloud Architecture and Migration Strategies: how to choose the right one?

It’s 2020 and I already consider it a beaten subject that we need to use cloud computing. Not because it is a “hype” of technology, but because of the services offered and the ability to respond on demand. A clear example of this is the amount of POCs (proofs of concept) that we can do before implementing a new technological offer in large-scale production, paying on demand.

In the technological context, we know that the cloud environment is what provides the best resource capacity and scalability. But how do we defend implementation in the financial context?

And when we have teams that already use cloud resources, for example, the marketing team uses Adsense (and consequently, GCP), the intelligence team uses PowerBI (and, consequently, Azure) and the technology team uses S3 for backups (so uses AWS). And we still have the local environment, usually with the company’s ERP and several other systems that have been installed for years and that we know will be a headache to migrate. Apart from the fact that, in many cases, a high amount was invested in the purchase of new servers a short time ago, so how can the organization’s CFO justify a migration to the cloud? These are the questions I intend to help clarify in this article. I hope it is of good use to you.

Migration Strategies for a Cloud Environment

When we are thinking about migrating to a cloud environment, I like to think of three working models: lift and shift; on demand; and from-to. Below is a description of each of these models.

Lift and Shift

+++What it is: this migration model tends to be the simplest to use, where nothing more is that we take the settings of our technology park and migrate to the cloud provider with the same configuration, after all, the cloud is also a datacenter in another place.

+++How it works: when the support license for hardware and applications is expiring, this is one of the few moments that I recommend using this method, as it is usually the one that brings the least value to the organization and is the method that will make you pay more within the cloud provider. Let’s go to practical cases of operation of this method. Our support contract for our servers will expire in 4 months and to renew, the amount is beyond the annual budget that IT has. The organization’s CFO did not allow an addendum for economic reasons, so, looking for an alternative, it was seen that a cloud provider provides hardware maintenance and guarantees all the necessary SLAs for the organization. Therefore, as there is little time for the migration, the provider with the most attractive price is chosen and there are support issues and technological evolutions. To migrate, “only” the servers that are needed in the cloud are raised, images of the current machines are taken and instantiated in the cloud provider, tests are carried out and the adjustments that are necessary are documented. After this process, the infrastructure migration date(s) is scheduled.

+++Main Advantages: the greatest advantage is the agility of the process, and in critical moments, this migration makes a lot of sense. There is also the advantage of starting to use the cloud, where a technological evolution plan can be drawn up for the use of the provider’s services and cost optimization.

+++Main Disadvantages: we will start paying a higher amount in this approach, since we will not use the services of the provider. An example of this could be the company’s Data Warehouse, where it is more expensive to have servers than to use the provider’s DW, be it Redshift from AWS, BigQuery from GCP or Sinapses Analytics from Azure.

On Demand Migration

+++What it is: the area team needs to build a new solution or perform an improvement, be it product or internal, this task is already developed using the resources of the cloud provider.

+++How it works: it is normally a strategy widely used in product development teams, where development is carried out on demand for the product, using the services that the cloud provider delivers. Let’s take a practical case to exemplify: you are from the infrastructure team and the development team needs a new server for testing, in our local infrastructure we already have a limited environment and there are few resources available for a new VM, so we raised the server on the cloud provider. We created the schedule so that it stays on only when the team is working, paying a much lower cost, since we are responding on demand. Once the tests are finished, the development team wants to put the application online, we can place this application directly on the cloud provider and to access it smoothly, we can place a route solution or API gateway to point to the new application.

+++Main Advantages: in the most common cases, there is great financial savings. The migration process to the cloud is less costly and less stressful for the teams and, consequently, for the company. It is the simplest strategy to test a migration and carries the least risk to the business.

+++Main Disadvantages: it is very common to be the slowest process for the migration, as it will depend on the roadmap of the products and the teams. There is a dataout fee that we have to start taking care of in billing. If it is not well managed and documented, it is very easy for environments to become a “shell of patchwork and pulls”, increasing technological complexity.

Migration from-to

+++What it is: using the services of the cloud provider regarding the application’s needs, not having to upload instances to servers and perform all installation and configuration of the application.

+++How it works: this type of implementation is more common when we work in environments and teams that don’t have much time to dedicate to monitoring and operation, but are focused on product development. This migration format is for migrating, for example, the Kubernetes server to the cloud provider’s serverless option: EKS on AWS, GKE on GCP or AKS on Azure. In this model, the team will work on the migration of a solution to a platform where it already has all the configuration interfaces and is responsible for the maintenance, monitoring and operation of the solution.

+++Main Advantages: mainly, less responsibilities and ease of scaling a solution.

+++Main Disadvantages: mainly, lock in with the cloud and learning curve for implementing a new technology.

So far, I have presented the three main migration models for a cloud provider, but which one is the right one to adopt? Typically, the answer is a mix between these models, depending on the context in which we are working. A team responsible for a product may choose to keep the solution on a server within the cloud, doing just a “lift and shift”. Another team might think about making a gradual migration of the solution, varying by the roadmap and finally, another team, to make development more agile, might think about rewriting its product and migrating to cloud products. So, at this point, we enter the next topic we need to discuss, which is Cloud Architectures.

Cloud Architectures

As well as migration strategies for the cloud provider, I also classify cloud architecture strategies into three large groups. Below I present them and we will discuss them.

Lock in Cloud

+++What it is: environment 100% within a specific cloud provider.

+++How it works: this model is very common in startups, where there is an investor and the need to return as quickly as possible, apart from the fact that there are no large data centers linked to the organization. Thus, paying on demand, the serverless products that the provider has in its catalog are used, to speed up the development process and lower costs.

+++Main Advantages: development speed and only one cloud to manage billing and infrastructure.

+++Main Disadvantages: from a technical point of view, it is the best of both worlds, as it facilitates management by the infrastructure and also facilitates development. Limiting is not always pejorative. However, when we talk about the business view, there may be problems: imagine if to close a contract with a prospect, the data just cannot be in AWS because Amazon is a competitor of your prospect in another branch? The same goes for Azure, GCP and the other clouds. You are also “hostage” of the provider and its solutions.

Hybrid Environments

+++What it is: we have environments in local data centers and we use a cloud provider.

+++How it works: it is the most common environment we find in companies, as companies usually already have a physical infrastructure or a data center environment contracted from third parties, and need to add a cloud environment to their infrastructure, whether for the use of a product or market strategy. Infrastructure managers typically build VPN tunnels between cloud and on-premises data centers to maintain a secure and restricted environment.

+++Main Advantages: you start to add the value that a cloud has within the organization and you don’t “kill” what has already been developed so far.

+++Main Disadvantages: administering more than one environment can become a little complex, as well as the data traffic between them, making it necessary to create monitoring rules.

Multicloud Environments

+++What it is: environments that may contain more than one cloud provider and local infrastructure.

+++How it works: often the best solutions for your needs are available from more than one provider, and this also happens with the cloud. I’ve seen environments where the marketing and growth team needed Google tools (GCP) for campaigns. In another, the business and intelligence team used PowerBI and Azure components to understand the product and know what to do in market analysis. The data science team used both AWS, GCP and Azure for their analysis and hypotheses. Apart from that the company had legacy data centers in its infrastructure.

+++Main Advantages: a greater range of options, the company being able to use the supplier that best provides solutions for its needs.

+++Main Disadvantages: high complexity in both infrastructure and financial management; development complexity too, as we will be dealing with different latencies and data outs; and need for professionals across all clouds and on-premises environments.

Now that we know the architecture formats and migration models, we can be sure that there is not a best model, but the one that best fits your context.

All models have advantages and disadvantages to adopting it. I’ve heard people say that the best would be a multicloud architecture using an on-demand migration, however, there is a need for an item to be analyzed: the data out, which refers to the “download” of data from the cloud provider. If your data analysis environment is in one location and your data lake is in another, your data out will be huge. I brought this example because it’s not just the technician that matters when we’re working on architectures and migrations, the financial factor, as much as many technical people and enthusiasts don’t like it, matters and has a very strong weight in decision making. So, in the next topic, I want to present the two pillars that environment administrators need to take into account when making decisions: payback and billing.

Financial control

Payback

Payback is one of the oldest techniques in corporations to justify the investment and it is really very useful for whoever is responsible for the cloud environment, since payment is made according to demand. Thus, we think that we are always investing when uploading a new server or using a new service. In this way, when we have hybrid or multicloud environments, it is always worth carrying out this payback exercise on the new service to financially guarantee the technological choice as well.

Billing

Finally, billing control is one of the essential activities in the lives of those migrating to the cloud or implementing a new strategy. And also a base activity in your day-to-day. All cloud providers offer account billing management formats and ways to implement spending alerts and limitations. Use them within your account to manage effectively and proactively, so there are no surprises when paying the bill.

Conclusion

I recognize that the explanation of all items was superficial, however, the idea was to present the three pillars for the implementation of your environment and/or migration to the cloud. When you manage to choose the format of the environment, aligned with the strategy and your financial control, it will make surprises difficult in the execution of the plan, increasing the chance of success for the project in question. These three pillars must be very well described, so for you, a technical person, negotiating with the financial area will make your world much easier.

I hope I helped or at least provided you with guidance on this point. Feel free for comments and suggestions, I’ll be happy to discuss them. 🙂