This is the second #DaysOfArm article that tracks some of the experiences that I’ve had so far. And just to recap from the first post yesterday.
It’s been just over 2 weeks since the launch of Ampere Arm deployed in Oracle Cloud Infrastructure (OCI). Check this article out to learn more (here). And it’s been about one week since I started looking into the new architecture and deployment, since I started provisioning the VM.Standard.A1.Flex Compute Shape on OCI and since I started migrating a specific application that has many different variations to it to test it all out.
This is my next learning.
So where I got it is that I’ve just provisioned my VM.Standard.A1.Flex VM. It all looks the same once I logged into the VM itself.
And it started out ok.
- Installing git so I can clone the application that I wanted to use. Done.
- Installing docker so I can build the containers that I needed to use. Done.
- Installing python3 so I can run some of the client packages that I needed to use. Done.
- Installing fnproject.io (here) so I can run up my serverless APIs. Huh?
This was my next learning.
This error became a common theme. And it took me a little while to consider what it meant. Ultimately, it was that fact the binary was built for the wrong architecture. In this case, it was x86-64 – ie Intel / AMD. This is where I started learning that I needed to refactor / migrate / find options for the software that I previously had in my stack to find ways to get them to work.
Learning: Do not assume that because the software ran previously,
that it will automatically work here.
I had to dig further into fnproject.io and found a list of different binaries (here) that it had for the command-line tool fn and saw the following – Windows (exe), Alpine Linux, Linux and Mac. Hmm. No Arm 64-bit.
I had the pleasure of running a 32-bit machine for almost 20 years (great for Minecraft and built strong though I’ve replaced the power supply three times). And whilst I had this machine, over time packages became special projects. The necessity to download source, compile and build packages was a task that I was determined to succeed to make this work. With what I’m experiencing with Arm is that the community is on the reverse side of tech adoption. Yes, there are gaps but there is a massive investment in building up the ecosystem. Whether you are an open-source developer, researcher, industry partner or an Oracle customer, there is an accelerator program to support Arm development. Check it out (here).
Learning: Do not be afraid to start from the bottom.
Someone has to.
From there I started working through the fnproject to figure out what I needed to rebuild for Arm 64-bit. To short-cut this whole process, these are the repositories that I’ve forked on github to make this work.
- fn project (here)
- cli project (here)
- fdk-python project (here)
- fdk-node project (here)
- fdk-go project (here)
- fdk-java project (here)
- dockers project (here)
Rebuilding them took some time to understand the dependencies and how it got built. Having good scripts and automation made this easier but you need to know the stacks that you are modify. In this case, already knowing about the different projects and how fn works helped me.
If you want to try this out yourself or work on your own application, sign-up (here) for the free Oracle Cloud Trial. I’d be interested to hear your experiences and learn from others as well. Leave a comment or contact me at jason.lowe@oracle.com if you want to collaborate.
There’s plenty of work to make this more achievable for everyone. And hence sharing this knowledge is the reason why I’m writing this series – #XDaysOfArm. I’ll keep documenting as long as I keep learning.
RedThunder.Blog 