Accelerating the Cloud: Transitioning to Cloud Native

This article is the third part of Ampere Computing’s “Accelerating Cloud Computing” series. You can read the first and second parts here.

As we demonstrated in the second part of this series, redeploying applications to cloud-native computing platforms is often a relatively simple process. For example, Momento described its redeployment experience as “much less work than we expected. Pelikan runs immediately on T2A (Google’s Ampere-based cloud-native platform), and we optimized it with an existing tuning process. ”

Of course, the application can be complex, with many components and dependencies. The more complexity, the more problems you may have. From this perspective, Momento's experience in redeploying Pelikan Cache to Ampere cloud native processors provides many insights. The company has built a complex architecture that they want to automate everything as much as possible. The redeployment process provides them with an opportunity to achieve this.

Applications suitable for cloud native processing

The first thing to consider is to determine how your application benefits from redeployment on cloud-native computing platforms. Most cloud applications are perfect for cloud native processing. To understand which applications can benefit the most from cloud-native approaches, we carefully looked at the Ampere cloud-native processor architecture.

To achieve higher processing efficiency and lower power consumption, Ampere has adopted different approaches to design our core – we focus on the actual computing needs of cloud-native applications in terms of performance, power and functionality. And avoid the integration into traditional processor features added to non-cloud use cases. For example, scalable vector scaling is useful when an application has to handle a large amount of 3D graphics or a specific type of high-performance computing processing, but brings a trade-off in terms of power consumption and core density. For applications that require SVE, such as Android games in the cloud, cloud service providers have the option to pair Ampere processors with GPUs to accelerate 3D performance.

For cloud-native workloads, reduced power consumption and increased core density at Ampere cores mean that applications run at higher performance while consuming less power and dissipating less heat. In short, for most applications, cloud-native computing platforms may provide superior performance, higher energy efficiency, and higher compute density while reducing operational costs.

Ampere is specialized in microservice-based applications with many independent components. Such applications can benefit greatly from the availability of more cores, Ampere offers a high core density of 128 cores on a single chip and up to 256 cores in a 1U chassis with two slots.

In fact, when you scale horizontally (i.e. load balancing across many instances), you can really see the advantages of Ampere. Because Ampere scales linearly with load, each core you add will bring direct benefits. Comparing this with the x86 architecture, in which the benefits of each new kernel are rapidly reduced (see Figure 1).

Figure 1: Because Ampere scales linearly with load, each core added brings direct benefits. Comparing this with the x86 architecture, in which the benefits of each new kernel are rapidly reduced.

Proprietary Dependencies

One of the challenges facing redeployment of applications is identifying proprietary dependencies. Anywhere in the software supply chain that uses binary files or dedicated x86-based software packages need to be taken notice. Many of these dependencies can be found by searching for code that contains "x86" in the file name. The replacement process is usually easy to complete: replace the x86 package with the appropriate Arm ISA-based version, or recompile the available packages for the Ampere cloud native platform if you have access to the source code.

Some dependencies will cause performance problems, but not feature problems. Consider a machine learning framework that uses code optimized for the x86 platform. The framework can still run on cloud native platforms, but it is not as efficient as it runs on x86-based platforms. The solution is simple: Identify equivalent versions of frameworks optimized for Arm ISA, such as those included in Ampere AI. Finally, there are some ecosystem dependencies. Some commercial software your application relies on, such as Oracle Database, may not be available as an Arm ISA-based version. If this is the case, this may not be a suitable application for redeployment until such a version is available. Workarounds for such dependencies, such as replacing them with cloud-native friendly alternatives, may be possible, but this may require significant changes to your application.

Some dependencies are outside the application code, such as scripts (i.e. playbooks in Ansible, Recipes in Chef, etc.). If your script assumes a specific package name or schema, they may need to be changed when deploying to a cloud-native computer platform. Most of these changes are simple, and a detailed review of the script will reveal most of these issues. Pay attention to adjusting the naming assumptions that the development team may have made over the years.

The reality is that these problems are usually easy to deal with. You just need to thoroughly identify and process them. However, before evaluating the cost of addressing such dependencies, it is necessary to consider the concept of technical debt.

Technical Debt

In Forbes article "Technical Debt: Hard to Measurable Obstacles in Digital Transformation", technical debt is defined as "the accumulation of relatively fast repairs in the system, or heavy but wrongly directed investments, may be financial in the long run, in the long run churn. "A quick fix can keep the system running, but the technical debt accumulated will be too high to ignore. Over time, technical debt increases the cost of change in software systems, just as scale buildup in coffee machines will eventually reduce its performance.

For example, when Momento re-deployed Pelikan Cache to Ampere cloud native processors, they had installed logging and monitoring code that relied on open source code from 15 years ago. The code works, so it's never updated. However, as the tool changes over time, the code needs to be recompiled. Some work is required to maintain backward compatibility, creating dependencies on old code. All of these dependencies have accumulated over the years. At some point, when maintaining these dependencies becomes too complex and expensive, you will have to just transition to new code. Technical debt can be said to be recovered.

When redeploying your application to a cloud-native computing platform, it is important to understand your current technical debt and how it drives your decisions. Maintaining and adapting legacy code over the years can accumulate technical debt, which makes redeployment even more complicated. However, this itself is not the cost of redeployment. Even if you decide not to redeploy to another platform, one day you will have to make up for all these quick fixes and other decisions to postpone the update of your code. You just haven't done that yet.

How real is technical debt? According to a McKinsey study (see Forbes article), 30% of CIOs in the study estimated that more than 20% of their technical budget for new products were actually used to address issues related to technical debt.

Red deployment is a great opportunity to address some of the technical debt accumulated by the application over the years. Imagine taking back a portion of the “20%” of the technology debt your company uses to address. While this may increase the time of the redeployment process, handling technical debt has the benefits of simplifying the complexity of managing and maintaining code in the long run. For example, you can "reset" many dependencies by migrating your code to your current development environment instead of continuing to rely on them. This is an investment that can instantly pay off by simplifying your development cycle.

Anton Akhtyamov, Product Manager at Plesk, described his experience in redeployment. "After porting, we encountered some limitations. Plesk is a large platform that can install many add-on modules/extensions. Some are not supported by Arm, such as Dr. Web and Kaspersky Antivirus. Some extensions are also not available. However, Most of our extensions are already supported using packages rebuilt by vendors for Arm. We also have our own backend code (mainly C), but since we've tweaked it before to support x86-64, we're just Rebuild our package without any critical issues. ”

For more practical examples of redeploying applications to cloud-native platforms, see Porting Takua to OpenMandriva on Arm and Ampere Altra.

In the fourth part of this series, we will dive into the results you can expect when redeploying your applications to a cloud-native computing platform.

The above is the detailed content of Accelerating the Cloud: Transitioning to Cloud Native. For more information, please follow other related articles on the PHP Chinese website!