This first half of this year featured lots of news about Arm processors (previously ARM) that culminated in three major announcements. The first was the general availability announcement from AWS of M6g Instances, powered by AWS Graviton2 processors in May. In June, Apple announced that they were migrating desktops and laptops to new Arm based Apple designed chips. In the same week, news broke that an ARM-based Japanese supercomputer is now the fastest in the world.
Clearly Arm is entering an entirely different space than it has been in. It still is incredibly power efficient, but now it has the horsepower to be your development or server CPU. Engineers and technology leaders should be considering what this means for their development and execution environments over the next 18 months. If development team members received the newest Mac laptops, how does a different architecture impact them? Will finance push to explore this opportunity to reduce the cost of instances being used? Now is the time to do an initial analysis so you aren’t caught off guard later by these questions.
Should you Migrate?
A next generation Arm-based chip designed by AWS (and Annapurna Labs, an Amazon company), utilizing 64-bit Arm Neoverse N1 cores.
With all the information in the news, the first question to be asking is if you should be migrating your workloads to Arm systems. There are several major factors that may impact your decision on migration.
Can You Migrate?
First and foremost, your architecture has to be supported by Arm systems. This section is one that will likely age poorly because AWS doesn’t stand still. If you are reading this article later than July 2020, do your own research to see what is and isn’t supported at that time.
If you only run within Lambda functions, there currently isn’t any support within Lambda for Arm architecture. If you are running your applications in Docker containers, there is good news: Deploying Docker Containers on Arm Hardware Just Got Easier. You can even create a single tag that references containers for multiple architectures by Building Multi-Arch Images for Arm and x86 with Docker Desktop. If you made it all the way to ECS with Fargate tasks though, you would have to switch back to managing instances as part of the transition to Arm.
Besides infrastructure, programming language support is a key factor in if you can migrate and what is involved. A quick google search for “LANGUAGE Arm support” will likely result in several articles like this one that talks about Python and Go in the Arm World. A lack of reference material for your language and the Arm architecture should be considered an important warning on moving forward.
The selection for an Arm processor in AWS CodeBuild
If your architecture can be easily migrated to Arm and your language supports it, the next question is, “Does your build environment?” You can likely find a blog post that specifically addresses your build system and Arm support (or lack thereof) such as the following:
- Build ARM-based applications using CodeBuild
- Jenkins CI Support for Arm Architecture
- https://ideas.circleci.com/ideas/CCI-I-900 (Feature request for direct Arm support)
Make sure when you are searching that your results focus on the Arm architecture and not Azure Resource Manager (Arm) templates. If you can migrate your applications, the next question is:
Is it worth it?
In the next section, I will talk about the effort required to migrate. If the reason you are migrating is to save money, then make sure that you are spending enough on instances to offset the migration cost. In March AnandTech showed that the Graviton2 processors are a much better value than AMD and Intel instances. The article summarizes that you can get the same performance from an ARM instance for 40% less than an Intel instance. If the goal of the migration is to save money, this 40% savings must be greater than the cost of the migration to pay any dividends the first year. When calculating the savings, make sure not to look at your entire AWS bill to estimate savings. Look at only the costs for the instances that will be converted to Arm to determine your potential savings.
When considering the timing of your migration, also make sure to factor in any reserved instances (RIs) that you are using. If you are using RIs and unable to time your migration within a very short time of the expiration of those purchases, you have to factor in the additional overhead of the instance’s prices for that time that they aren’t covered.
You may find that starting new work with a deployment target of Arm and leaving legacy services running in x86 gives you the best path forward. One warning to this approach, for some portion of your applications, they will be developed on an architecture that is different from where they are deployed. This brings us to the final questions:
Does Where You Develop Matter?
Linus Torvalds made headlines in February 2019 dismissing Arm architecture with the logic,
“If you develop on x86, then you’re going to want to deploy on x86, because you’ll be able to run what you test ‘at home’ (and by ‘at home’ I don’t mean literally in your home, but in your work environment).”
He did specifically identify the possibility of developer systems migrating to Arm and the potential it would have:
“I do agree that the ARM laptops may make this all work out on the development side. Whether from the PC side (“WARM”) or Apple cutting their laptops over.”
If you accept that logic and develop on Macs, then Apple’s move to Arm should have you aggressively planning your migration. If that logic didn’t resonate with you then (or doesn’t now that you are facing the change), then you still can consider the architecture switch and don’t have to worry about trying to replace your fleet of development systems all at once to coordinate with the change.
The Approach
Before beginning this transition, we need to come up with a solid plan. Estimating by trying to find comparable items is a good starting point to determine how much effort it is going to take. The change of architecture is probably close to or more complicated than updating an application to run on a new version of Linux. This effort is perhaps inline with shifting the distribution that is being used. This is a fair assessment since we know that we are going to have many different libraries that are using different versions.
It’s important to envision your end state at this point. Update your application diagrams with the changes so you have a full understanding of what is needed. You will also need additional build agents that are running on Arm architecture.
For existing applications, the canary style deployment is ideally suited for this type of transition. Moving a small amount of traffic to the new architecture allows for final debugging in production with very little impact on customers. If you aren’t currently using canary deployments, it may be useful to temporarily switch to that method. This change should be started in your earliest development environments and then rolled out to successive environments until finally the updated deployment method is in production.
Changing the underlying hardware architecture is significant. This type of a change shows the significant value that a well built deployment pipeline provides. With automated testing and rollback built into a deployment pipeline, it should support changing out just the few settings that are relevant to the architecture and leaving the rest of the pipeline untouched.
If you initially decide to leave existing applications on x86 resources, make sure to come back in six months and reevaluate your decision. A lot may change within that time. It is possible AWS will add support for Lambda functions on Arm or Fargate may add support for Arm. If you build new applications on Arm resources, then you may be in a much better position to estimate what it would take to transition existing applications.
Set your Direction
Now is the time to start evaluating whether Arm is right for your applications and how to go about making the change. For small organizations, the cost of converting may far exceed any savings that can be realized. For large organizations, there may be significant savings to be had.
The most important item for you now is to make a specific decision about what direction you are going to head and when you are going to get there.
Featured Image by JOHN TOWNER
|
Stelligent Amazon Pollycast
 |
