This article is the second part of Ampere Computing’s “Accelerating Cloud Computing” series. You can read the first part [here] (replace with Part 1 link here).

It is much easier to migrate your app to Ampere cloud native computing platform than you think. This is because most of the work of redeploying applications to an Arm-based server is already done for you, or just recompile it.

In short, because Ampere's cloud-native processor uses Arm instruction set architecture (ISA), software running on Arm can also run on Ampere. Over the past five years, the open source community’s support for Arm has grown exponentially, with a wide variety of new software and services emerging. For example, applications such as Redis, NGINX, Memcached, MySQL, and Cassandra already offer proven ARM-based versions.

What does this mean for developers? Most of the software used by companies is already running in the cloud, or is likely ready for cloud native environments.

Operating System (OS): Almost all available operating systems have been ported to Arm ISA and run on Arm-based cores. As a result, Ampere's cloud native processor supports released versions of the major operating systems used in the cloud.

To further guarantee reliability and performance, Ampere tests and validates public image and prepackaged applications of the operating system on its Ampere cloud native processor. In this way, developers can be sure that their applications can run seamlessly on Ampere.

Prepackaged code: Usually, a large part of an application is built using prepackaged application components. Arm-based public images of most of these applications (from MYSQL, PostgreSQL, Cassandra, NGINX, and Squid to a variety of applications) have been tested and verified on Ampere cloud native processors. Therefore, this part of preparing an application for a cloud-native computing platform is relatively simple: just use the already provided Arm-based mirror. No complicated porting or software rewriting is required.

Compiled Language: Generally speaking, most of the key issues that arise when redeploying a web server stem from code that needs to be compiled to run on Ampere. For code written in languages ??such as Go, C, and C, the redeployment process requires an additional step because the existing binaries are built for the x86 environment. Since the vast majority of programming languages ??are available on Arm and x86, most redeployment issues simply need to run the build script on the Ampere build node to generate the correct binary.

Internal/Customization: Custom applications can be divided into four types: interpreted, advanced, binary and hardware-specific.

• Explanatory code: Uncompiled code written in interpreted languages ??such as Java or Python, is very easy to redeploy on cloud-native platforms. Since the code is interpreted and executed, it can run on a cloud-native computing platform without changing the code. Instead, the code runs on an interpreter compiled for Arm instead of x86. Typically, redeploying an interpreter for a cloud-native processor is a simple process that can be done in minutes if the image does not exist.
• Advanced Code: It is also relatively easy to prepare code written in high-level languages ??such as C/C for cloud native platforms. In most cases, the application just needs to be recompiled for Arm ISA. Typically, this is managed by simply configuring the compiler to Arm instead of x86. If any warnings or errors occur during the compilation process, these issues can usually be easily resolved, or confirm that they are not problems.
• Binary files: The most common redeployment problem for many applications is the use of binary files. A binary file is code (usually a library) that is included in the application. This may include products that are only available in binary form, which are dependencies for your application. Before building your application, just check the dependencies your code has and make sure the binary used is Arm-based rather than x86-based.
• Hardware-specific code: Code written for a specific processor, or code that uses a specific processor function for performance purposes (such as a graphics library), may require limited porting. This happens only if there is no specific Arm version available. Regardless, the transplant process is usually simple and can be completed in just a few hours at most.

Real World Redeployment

Let's see what it takes to re-deploy the application to Ampere cloud native processor. Consider Momento, which is dedicated to providing services that manage caches at scale so developers don't have to manage them themselves. Momento Serverless Cache is built on Pelikan, an open source caching engine originally designed for Twitter's specific cache needs. Pelikan has been completely rewritten in Rust recently. Momento wants to re-deploy Pelikan on Google-hosted Ampere-based Tau T2A virtual machine.

Red deployment is fast and seamless, without changing any code to get Pelikan and Momento Serverless Cache up and running. Additionally, the Momento team was able to implement some simple optimizations (no code tweaking required), which quickly tripled throughput. We will give you a detailed look at the performance benefits you can expect in Part 4 of this series.

Another example of redeployment is Plesk. Plesk's software enables people to manage their web infrastructure through a central control panel. Lukas Hertig, senior vice president of Plesk's Business Development and Strategic Alliance, described his own experience in the redeployment process. "I had a crazy idea at first, to have an Arm version. A few weeks later, my engineering team came back and told me, 'Oh, it works now.' Much faster than usual!"

Plesk serves the SMB field, and it is not obvious to choose cloud native. But Hertig said shortly after the redeployment, “we have exceeded 1,000 Arm instances in production.” Bottom line: Arm and the open source community have done a great job in developing and expanding the Arm cloud ecosystem. Of course, the complexity of redeploying your application to a cloud-native computing platform depends on where you get the code. However, generally speaking, the investment in redeploying most applications to cloud native processors is minimal, as 80-90% of applications only need to be recompiled.

In the third part of this series, we will further explore the cloud-native redeployment process.

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