This is my fifth #DaysOfArm article that tracks some of the experiences that I’ve had so far. And just to recap from the first post (here) on June 12 2021.
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.
Much of what I’ve been doing here is full of experiments. I may try something out. It may later be refined by a different method.
As an example with the work that I’ve been doing with the fnproject.io (here), I’ve realised that when considering where things were breaking, it wasn’t the source that was broken but the artifacts generated were tied to the hardware platform. I’ve since gone back and retested what I’ve been doing and building with the standard packages and it’s building and working fine.
Learning: Be open to refactor because the first answer may give the right answer but there may be better ways to solve it.
As part of this experimentation, I’ve serious got a few things wrong. I’ve been scratching my head about different areas and trying to triage what’s going wrong. As such, having a “good enough” software development practice has helped the process:
- Source Code Control – everything is in saved and can be shared.
- Fork then clone (in Source Code) – especially if there are third party projects that you are needing to use.
- Branches (in Source Code) – there are small variations that I’m testing so it’s important to keep things tidy.
- Document everything – I’ve been using slack to track everything that I’ve been doing – the different activities, the outcomes, the lines of code or fragments, the shell scripts and git repositories.
- Aim for that one click process – automate what you can. eg. Terraform for infrastructure, Ansible for configuration process, Jenkins (since I can run this on Arm64) for pipelines.
Learning: It is a repetitive and reinforced. Tracking the learning (even the first time) gives you more data to learn from and go back to.
Side-Note: For Jenkins on VM.Standard.A1.Flex Compure Shape, I used this terraform project to get it running (here). Jenkins needed a different image (vs the normal jenkins/jenkins:lts image). Jenkins4Eval (here) has mult-architecture support available.
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 