Transitioning your service or application
This section provides more details regarding the individual steps involved in transitioning an application to Graviton2. In the interest of simplicity, we assume this application is written in a bytecode-compiled language (e.g., Java or .NET Core) and deployed as one or more virtual machines in AWS. Some of the concepts described in the following may differ when the application is deployed via a different method (such as container services) or distributed to users to be run in their own cloud environments (AWS Marketplace AMIs). However, the high-level sequence of steps will not change.
Resolve code dependencies
Start with code dependencies such as software libraries and determine whether you are able to run them in a 64-bit ARM environment. This includes questions such as how current is your code base and which version of languages and runtime do you currently use. Work with your engineering team to identify code ownership (which can often be a problem for older codebases) and figure out external dependencies (with teams inside your company as well as any dependencies on third parties). For example, Java virtual machines (VMs) typically support ARM64 from JDK8 versions onward. Application code and packages that were developed and built against older versions may need to be upgraded first. Do not forget other components such as Software Development Kits (SDKs), OS agents, and control plane artifacts in this inventory. This inventory will help you identify which parts of your application are easier to transition.
Upgrade operating systems
Upgrade your operating system to a version that supports the Graviton2 processor and offer
the full performance entitlement. Your production environment may be running an outdated
version of your operating system. This means you may not have access to the latest drivers and
platform-specific fixes and optimizations. Build and test your software on the newest x86
version of your operating system before attempting a transition to 64-bit ARM. For example,
Amazon Linux AMI
Upgrade language runtimes
Perform a runtime upgrade to the most recent version of your programming language to get the best performance. For example, JDK11 and higher offers many optimizations for 64-bit ARM. Consider upgrading to the latest stable JDK release to gain access to these optimizations when running your code on Graviton2. Additionally, .NET 5 has significantly improved performance by adding 64-bit ARM-specific optimizations in .NET libraries, providing you with access to the full performance entitlement on Graviton2.
While prior 64-bit ARM runtime versions for your programming language may exist, they do not always offer optimal performance. For example, consider the changes in garbage collection (GC) algorithms between Java versions and their impact on variables such as throughput. Upgrading to a higher version of your programming language may require an incremental process of refactoring and testing. Older application code may rely on interfaces and methods that are deprecated by a higher version of the programming language. If an upgrade to a higher version is not an option, then prior versions of your runtime can serve as a temporary stop gap solution for test and evaluation purposes.
Transition codebase and packages
Review your codebase and begin the transition to Graviton2. This includes your application code and any other software dependencies defined in metadata files, container manifests, or Infrastructure-as-Code templates. Start by upgrading old code dependencies to new versions. For example, you may need to upgrade Java libraries with native language extensions to their latest versions for your code to build and run on 64-bit ARM. Repeat this process until your code successfully builds and runs in your new target environment. Identify very old dependencies and decide whether you can retire them. This may require refactoring and retesting your code in case the dependency is not working as expected.
Test and benchmark your code
Test and benchmark your code on multiple architectures to verify
that your build is correct. This often involves running shadow
test fleets (of both 64-bit ARM and x86-based instance types).
Update your deployment scripts and Infrastructure-as-Code template
to account for different instance types, 64-bit ARM compatible
AMIs, and other differences between your environments. Upgrade
your build pipeline to build on 64-bit ARM and benchmark
performance metrics (throughput, latency) of your code running on
AWS Graviton2 against x86 builds. Consider stress testing your
deployments to establish how your workload performs under peak and
above peak loads. This ensures that your code is making effective
use of the Graviton2 performance advantage. For more information
about compiler flags in languages such as C/C++, see the
Getting
Started Guide
Tune and test
Tune your software, test again, and repeat the process of iterative refactoring, testing, benchmarking, and tuning until all remaining dependencies have been completed. This might involve micro benchmarking and profiling your application code. You may also want to consider special optimizations for cryptographic or machine learning workloads. For more details on how to optimized for performance and details such as optimized compiler flags, see Optimizing for Performance.
Additional considerations
Update Amazon Machine Images (AMI) or container registries
Other considerations to make after you transition your service or application to 64-bit ARM include updating build scripts, machine or container images, and container registries. Whether you follow the SaaS model or distribute your software directly to customers, you must update your CI/CD pipelines to add support for building on 64-bit ARM machines. Other issues include building Amazon Machine Images (AMI) and Docker containers for the 64-bit ARM architecture in addition to your existing x86 artifacts. If you follow the Marketplace model, update your AWS Marketplace listings and container registries so customers find the right image for their use case.
Update deployment scripts
If you follow the SaaS distribution model, you also need to think about operational concerns as you transition your application or service to support 64-bit ARM. For example, this might mean updating your deployment scripts to weight in Graviton2 instances in parallel to your Intel or AMD instances. While out of the scope of this paper, consider using deployment strategies such as Canary Deployments or Blue/Green Deployments. For more information, see the Deployment Strategies section of the Introduction to DevOps on AWS white paper. AWS recommends you start with test and staging accounts before moving to production accounts, and to keep the changes limited to a small percentage of customers at a time.
