Taking advantage of the Ampere cloud native compute platform involves much less time and effort than one might think. That’s because the majority of work to redeploy an application to an Arm-based server has already been done for you or is simply a recompile away.

In short, since Ampere’s cloud native processors utilize the Arm instruction set architecture (ISA), software that runs on Arm runs on Ampere. Over the past five years, support for Arm from the open source community has grown exponentially, with a tremendous variety of new software and services available. For example, applications like Redis, NGINX, Memcached, MySQL, and Cassandra already have validated ARM-based versions available.

Here’s what this means to developers: the majority of software a company uses is already running in the cloud or is likely to already be cloud-native-ready.

Operating System (OS): Nearly every OS available has been ported to the Arm ISA and runs on Arm-based cores. As a consequence, Ampere’s cloud native processors support the released versions of the major OSes used in the cloud.

To further guarantee reliability and performance, Ampere tests and validates public images of OS and prepackaged applications on its Ampere cloud-native processors. In this way, developers can have confidence that their applications will work seamlessly on Ampere.

Prepackaged code: Often, a substantial part of an application is built using prepackaged application components. The Arm-based public images for the majority of these apps – everything from MYSQL, PostgreSQL, Cassandra, NGINX, and Squid – have been already tested on and validated for Ampere cloud native processors. Thus, preparing this part of the application for a cloud-native compute platform is relatively simple: just use the Arm-based image already available. No complex porting or rewriting of software is necessary.

Compiled languages: In general, most of the critical issues around redeploying web servers arise from the code that requires compilation to run on Ampere. The redeployment process requires an extra step for code written in languages like Go, C, and C++, because the existing binaries have been built for an x86 environment. Since the vast majority of programming languages are available on Arm as well as x86, most redeployment issues simply involve running build scripts on an Ampere build node to generate the right binaries.

In-House/Custom: Custom applications can be broken down into four types: interpretative, high-level, binaries, and hardware-specific.

• Interpretative code: Code written in an interpretative language like Java or Python that is not compiled is trivial to redeploy on a cloud-native platform. Since the code is interpreted, there’s no need to change the code to run on a cloud native compute platform. Rather, the code runs on an interpreter compiled for Arm instead of x86. In general, redeploying the interpreter for cloud-native processors is a simple process that can be completed in minutes if an image is not already available.

• High-Level code: Preparing code written in a high-level language like C/C++ for a cloud native platform can also be relatively painless. For the most part, the application only needs to be recompiled for the Arm ISA. Typically, this is managed by simply reconfiguring the compiler for Arm rather than x86. If there are any warnings or errors during compilation, it is usually a straightforward process to resolve them or to confirm they are not an issue.

• Binaries: For many applications, the most common redeployment issue that arises is the use of binaries. Binaries are code – often libraries – that are included in an application. This can include products that are available only in binary form that are dependencies for your application. Before building the application, just check the dependencies your code has and make sure the binary files used are Arm-based instead of x86-based.

• Hardware-specific code: Code written for a specific processor, or using specific processor functionality for performance purposes, such as graphics libraries, may require limited porting. This is only the case when there isn’t an Arm-specific version already available. In any case, the porting process is often straightforward and at most a few hours to complete.