Web

Accelerating the Cloud: The Investment to Go Cloud Native

    Nicholas Cravotta
    Share

    This article is Part 2 of Ampere Computing’s Accelerating the Cloud series. You can read Part 1 here.

    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.

    Real-World Redeployment

    Let’s take a look at what it takes to redeploy an application to the Ampere cloud-native processor. Consider Momento, dedicated to offering services that manage caches at scale so developers don’t have to. Momento Serverless Cache is built on Pelikan, an open-sourced caching engine, originally designed for Twitter’s particular caching needs. Pelikan was recently rewritten entirely in Rust. Momento wanted to redeploy Pelikan on Ampere-based Tau T2A VMs hosted by Google.

    The redeployment was fast and seamless, with zero code changes required to get Pelikan and Momento Serverless Cache up and running. In addition, the Momento team was able to implement some simple optimizations — with no code tweaks — to quickly triple throughput. We’ll go into details of what kind of performance benefits you can expect in Part 4 of this series.

    Another redeployment example is Plesk. Plesk’s software enables people to manage web infrastructure through a central control panel. Lukas Hertig, SVP Business Development and Strategic Alliances at Plesk describes his own experience of the redeployment process. “It was initially a crazy idea from me to have an Arm version. A few weeks later, my engineering team came back and said, ‘Oh, it works now.’ Much faster than usual!”

    Plesk serves the SMB space, where the option to go cloud native is not obvious. But shortly after redeploying, Hertig says, “We already crossed 1000 Arm instances in production.” The bottom line: Arm and the open-source community have done a great job developing and expanding the Arm cloud ecosystem. Of course, the complexity of redeploying your application to a cloud-native compute platform depends upon where you source your code from. In general, however, the investment to redeploy most applications to a cloud native processor is minimal, since 80-90% of applications just need to be recompiled.

    In Part 3 of this series, we’ll explore more about the cloud native redeployment process.