 Hey, everyone. My name is Pranay Bakre. I'm a principal solutions engineer at ARM. My primary job is to make sure that partners, our partners, open source, closed source, et cetera, can run their workloads and applications as seamless as possible and as highly efficient and performant as possible. I also help them build solutions in ARM ecosystem. This is the agenda for the session. We are going to talk about what is ARM. So just a quick show of hands. How many of you know what is ARM? Oh, that's great. All right. So then we'll go into ARM in the cloud on what kind of instances to we offer at the moment in the cloud. Then we'll talk about the support for CI CD tools and what kind of tools support ARM based, let's say, runners or deployments, delivery, et cetera. We'll also go into some languages, just a small subset of major languages that are out there, Java, .NET, et cetera, PHP. And if they are supported or not, and if they are, are they performant, et cetera. We'll also do or talk about case studies that we did a while ago on GitLab as runners and as an architecture itself. We'll also talk about autoscaling GitHub actions and what that looked like when we did that. Then we'll go into a bunch of demos, depending on how much time do we have. I have a multi-arch delivery pipeline that we can build a Java-based application, a containerized application, we can do all that. Then we'll do some key considerations of building these images that are based on ARM or rather multi-arch, to be honest. And then in the end, how do we start or where do we start? So just a high-level or one snapshot slide on what ARM is. So ARM is the technology behind your smartphones, your laptops, like I'm using a Mac, which is M1, which is again under the hood running ARM. We go from Raspberry Pi's in the IoT space, Raspberry Pi, Jetson Nanos, or the entire Jetson family. In the cloud, we have processor families called Graviton. That's an AWS processor that they built in-house. We also have in data centers, a processor family called Ampere Ultra. That's also based on ARM. And as a company, we don't manufacture chips by themselves, but we provide intellectual property or the design to manufacture chips to our partners and customers, like AWS, Ampere, et cetera. And the ARM architecture itself differs from XET6 or Intel, meaning that in XET6 is based on a complex instruction set or CISC, and ARM is based on reduced instruction set. I promise I won't go into much details on what the instruction sets are, but just to give some context, because you can't run an application which is running on an XET6, or let's say on your mobile phone directly on an ARM-based platform, but there are caveats to that, which we'll talk about later. So just to help set the context, the architecture is different from a traditional XET6 or AMD 365 architecture. These are just the cloud providers that are offering ARM-based instances. These include public clouds like AWS, Azure, GCP, Oracle, and then there are private clouds, community clouds and hybrid clouds. This is just a snapshot of what these clouds offer and what kind of instances can you expect. And we'll go in the next slide in details on at least these couple of clouds on what the current state is and how you can start with those. So this is the slide that captures the instances. And I'm using a general word, instances in the cloud, but every cloud calls it differently. So AWS calls it instance, Azure calls it VMs, virtual machines and GCP calls it compute engine. So again, all the same thing, basically they are virtual machines that you can use to deploy your workloads. The family of in AWS, it's very easy to identify. Whenever you see a G in an EC2 instance, just know that it's based on Graviton or at least Graviton two processes for that. So M6G is the general purpose instance, which is Graviton two-based, M7G is the general purpose instance, which is Graviton three-based. Now between these two instance family types, we see at least like 30 to 40% performance gain. And of course it depends on your application stack, but that's across the board. And these instances are cheaper at least, I think Graviton two instances are cheaper by like at least 20% rate of the bat compared to the X86 instances. Then we have the memory optimized and compute optimized instances as well. There are free tier eligibility and I'll talk about towards the end of the presentation on how you can gain those and how you can start working on these instances. In Azure, they are called DPS V5, PLS V5, it's a small, and I'll show in the cloud how you can select just a small selection where you can do on the cloud to select your ARM-based instance. And in GCP, that's called tau T2A, general purpose instances. And again, they also offer a free trial if you're looking to start into it. Okay, so these are the major, or rather a subset of major CI CD tools that support ARM-based pipelines, that support ARM-based runners. So for instance, Jenkins support an ARM-based architecture, Travis CI, and there are lots of blogs out there talking about the performance of ARM on these different kinds of pipelines. GitLab, they support runners, self-hosted runners, meaning that you can use those to deploy your applications natively on ARM without using any simulation. I know the people who are familiar with ARM must know that what is, we used to call what means a Schemu or QMU. That's basically an emulation where you run your ARM-based application on an X86 instance. But we can move away from that, we can talk about building it natively on an ARM instance. In GitLab, like I said, self-hosted runners, Git have actions, again a CI CD tool. It supports ARM-based runners, again in self-hosted, and we'll see that in the demo as well, and on the case studies that we did on how you can initiate the deployments on how you can go about it. Circle CI, Azure Pipelines, support ARM-based instances, so does AWS Code Palim. There are others as well, but for now I'm just talking about these. All right, so the question comes to us that, okay, so I have an application, like someone I was talking to yesterday, they said, hey, I have a .NET application, do you think it will run on ARM? And the answer is yes, because it's supported entirely on ARM64-based platforms. Now I'm using ARM and ARM64 interchangeably, because ARM64 is this type of architecture or the binaries, whenever you download something, if it says ARM64 or AR64, just know that it's compliant with ARM. For Java, Java is pretty cool, so with Python, you don't need to recompile those applications. So if you have, let's say, a Java-based, let's say, a Spring Boot application, you can just take that application as is and run it on an ARM-based instance, be it an EC2 instance, use Beanstalk in AWS, use in Azure, you can run it directly, you don't need to recompile anything because it's unicode, bytecode, for that matter. And again, OpenJDKN, all the support is available. CC++, yes, you'll need to recompile, because again, it's a processor architecture that's different. PHP, no need to modify anything. When I say PHP, I also mean Node.js, TypeScript, JavaScript, because we don't need to compile those applications. They run out of the box on ARM-based platforms. Go, Go is interesting. Golang has support for ARM since a long time ago, but yes, they will need to be recompiled. And in our demo, we'll see how you can build your Docker image based on Go and make it multiarch, so that it runs out of the box and you don't have to think about anything. Python, again, you don't have to, like I said, in the beginning. Python you can run directly on ARM-based instance without recompiling anything. And .NET, so .NET 5 and 7, they bring major performance improvements. I haven't included all those links, but if you just Google .NET 5 and ARM 64, you'll, the first block pops up, let's say Azure or from AWS. And you can actually go ahead and look what kind of performance enhancement they did on .NET 5, .NET 7, et cetera. And there are other languages which I haven't listed, but there is a really cool guide, and I think I have it in one of the slides. It's called AWS, it's on AWS, AWS getting started. So basically what that does is that if you are looking to start building on ARM or ARM-based instances, you can leverage that to repackage your applications or just run it as is, depending on what kind of application stack you have. And we also, apart from languages, there is also support for in containers. So Docker supports that, and we see that in the demo. We also have support for Kubernetes, Prometheus, Grafana. All of these open source tools, along with the CI-CD tools that we talked about, I didn't want to put too many logos, that's why I didn't include that here, but basically all of these support ARM-based instances. And ARM-based libraries. And with Java, there are, I think the OpenGDK version 17, or I think whichever is the latest. So all of them are supported right after the box, and you can just run your applications directly. So this brings us to the case study. So GitLab, we met with GitLab folks a while ago, and we wanted to understand their pain points, and of course, what does it take to run, let's say, GitLab on ARM-based hardware? So we use the Graviton family of processors, which is ARM-based, Graviton 2.0 family. And what GitLab has is a reference architecture. Let's say you are an organization where you don't want to use the publicly available GitLab repos, you want to host it in your own company. You have some security concerns, you have your clients that need to keep everything in-house. You can do that. So we took an example of, so GitLab has different kinds of architecture, 10K, 15K, 25K, or I think 5K, 1,000 users. That 10K means that that architecture can support up to 10,000 users. And in our tests, we actually found that the reference architecture, we just kind of cranked it up a bit. Okay, let's see if the 10K architecture, because under the hood for 10K architecture are all those instances that are based on your EC2 family. So 6G, R6G, et cetera. And it has a lot of components like Postgres SQL, all different databases, Redes, then it's load balancers. How does it behave if we crank it up more than 10,000 users? And interestingly, we found that it actually can support more than 10,000 users without breaking a sweat. And I don't know how many of you attended Liz Fong-Joon's talk yesterday, but she also kind of hinted to that because on an ARM-based platform or an ARM-based instance, you get, if you see a 1VCPU, you get a physical one-to-one mapping. Whereas for an Intel, you see, since there is no SMT with Intel, there is, so you see one-to-two ratio. So whenever you are seeing 1VCPU, you're actually getting half of that. So it was supporting and it was outperforming what we had initially predicted. And again, at the time, it gave us around 20 to 25% cost savings when we used those ARM-based instances or the Graviton-based instances. The second part of that, okay, so you have deployed your GitLab server or components to support it, but you can't do anything if you don't have a runner to build your applications. So GitLab Runner is supported on AWS Graviton 2 or ARM-based platforms. Since 12.6, I don't know what the current version is, but it's been a while. So what we did was we used, we took a Linux kernel code or source code and we built it on those runners. So we had a pipeline and the GitLab folks helped us out with this. We had a pipeline which actually built GitLab, sorry, Linux kernel source code on an X86 and on an ARM-based runner. So as you can see in the diagram, hopefully it does. Okay, yeah, so those are the M6G instance and then there's the M5N instance. And we also had Prometheus and Grafana collecting metrics from both to see how they perform and they performed really well. We saw, I mean, right now it doesn't look like much, like five minutes, 47 seconds, how much of a difference like two minutes makes. But when you scale it up, this was just to show that even at that level, the ARM-based instances or the Graviton 2 instance in this case were outperforming, which was a pretty big win for deploying or telling our partners that you can switch to Graviton without hassle that, oh, how will it affect the performance and how will it hamper my current application? So this was one. The second that we did was auto-scaling GitHub action. So I know I have a lot of components in there and now GitHub actions support auto-scaling by its own. But again, this was done a while ago. So that's why I have Lambda and everything in there. So what it does is basically whenever you, the use case was that if you have runners in your GitHub actions, you think about if they are not being utilized all the time, if you don't have builds going right out of the gate every day or every week or so, they're sitting there idle. They are accumulating costs and cost is bad. You want to save costs by doing some different measures on either use CloudWatch or do something else. This was one of the approach where a runner was deployed on the, in the repo as soon as a commit occurred. So it was a very small runner. So it didn't take long. It would take seconds to, we had the code where it actually took like a couple of seconds to deploy it and your pipeline would execute. Once that's done, it would destroy that runner and that's it, the Lambda would take care of that. What that meant was that you could save a lot of costs by doing these auto deploying or auto scaling these GitHub actions runners. What that also helped us to do was that when you build your CI CD pipeline, you need to think about a lot of different factors, performance and cost, of course, then security also, which we'll talk about later. But when you take cost into equation and you remove the need for a static runner which is sitting idle most of the time, you can use it or the solution for deploying it on the go and kind of leveraging its use for this. Okay. So I'm going to talk about multi arch. So I'll kind of switch back and forth between the presentation on how to build that multi arch pipeline. So let me first go here. So this, yeah, it shows. So in EC2, and I'm just quickly talking about how you can launch ARM based instances in the cloud. For in EC2, whenever you go and launch, I know I'm talking about console, we, I mean, these days we use Terraform, everyone uses Terraform or some form of infrastructure as code. But still, just to see that if you go to AWS console, there is a dropdown right here, which is 64 bit X86 and ARM. Now, if you select ARM, you see different types of instances here. Now, these are all, like I said, T4G, whatever ends with G is based on Graviton 2 or Graviton 3 for that matter. So if I talk about M6G, you'll see all those family of instances. When you deploy those, they, I can't compare the cost right now, but from what I know, they are like 20% cheaper. Anyway, so the point is that it's really just clicking this one dropdown and selecting it and you can deploy your ARM based instances and deploy your applications. Same thing with Azure. If you go here in Azure, again, it's selected by default for me, but ARM 64, X64. So ARM 64 is the ARM based architecture. And if I go here and see different sizes, then these are the general purpose instances that are supported in their memory optimize, compute optimize, et cetera, or VMs, not instance. Compute Engine, because again, Google, so Google calls it Compute Engine. The family is called T2A and this is the series where you directly select the family of instances. This is a pretty, it's a bit different from the other two clouds, there is no dropdown or a radio button, but and you have to purposely select it. But when you select this, it will give you the options of different kinds of compute engines or VMs that are available to deploy your ARM based applications. Again, this is all, so this one and the Azure one is based on a platform called Ampere Ultra, which is again, like we saw in the earlier part of the presentation, is based on ARM, IP. Yeah, so multi-arch, right. So I'll just quick, wow, okay. So I'll just quickly go to runners. So this is a GitHub Actions pipeline or rather my pipeline that I've forked from a repo. It's a e-commerce application and I can show that how it works. Basically, if you see, you come here and you add a self-hosted runner. Now here in the architecture, you see x86 or x64, ARM and ARM64. So whenever you select ARM64, it will give you a very simple steps and you can run your runner. So if we come back to runner, it says offline, right? So I'll just go here and I'll do run.sh. And it should automatically be listening to jobs for now. So now if I refresh here, it should be idle. So it's idle because again, I'm not running anything right now. So this is my, yeah, you can see. So this is my YAML file for the application where it's doing continuous integration or build and delivery just on a push or a pull request. I'm using, so one critical thing that we need to understand is here with GitHub Actions, you need to use the tag self-hosted and it's shown actually here, whenever you try to run a runner in any of the architecture, it says you need to use self-hosted because if you use, we are all used to or we don't even think about it sometimes. We are used to Ubuntu dash latest or some other flavors because those are the hosted runners by GitHub. And on here, since we are using a self-hosted runner, you can directly use this one to deploy your application since it's the one that we are hosting right now. Here I'm just building that application with Maven, uploading those artifacts and downloading the jar and then deploying it again using Beanstalk, AWS Beanstalk. And all these different flavors of services are also supported and goes without saying. I now also want to show you a multi-arch pipeline. This is again, another application, but I want you to focus on this particular thing. So when you see a target arch, so basically what it's doing is based on the architecture of your runner or whatever you are running at the back end, it will pull up the architecture by doing unm dash A. So if I, oops, sorry. Yeah. So if I do here, yeah. So I'm running a M1 based Mac and if you're running it, you just do like this and you'll see an ARM64 at the end, M1, M2, all of those. Anyway. And so it will automatically use that architecture as the target architecture and you can use it to build your multi-arch build. Now, one thing that you need to understand with Docker also comes a utility called BuildX, which is, oh, by the way, I'm using this Kubernetes cluster and if you see here, that Kubernetes cluster is in AWS or an EKS cluster and it's using Amazon Linux too and it's AR64, which I mentioned in the beginning. So if you go here, sorry if I'm jumping through and through. Yeah. So these are the, it's based on M6G large and an EKS cluster that supported. Yeah. So let me come back to this and right. So here we need to know some key considerations. So if you are building a multi-arch pipeline with Docker and publishing it them to ECR and then eventually deploying it on, let's say AKS, sorry, I'm using it back and forth, but all of these clouds support that. So if you're using a Docker hub, let's say for registry and you are deploying it on Azure, you can easily do that. There's a utility called Docker BuildX. Now what it does is if you have an XC26 machine, you install Docker, the BuildX utility comes with it. You add a ARM-based remote builder. So what that means is you don't have to use Kimu anymore. You can directly use a remote builder where from one of the clouds that we talked about or in the next slide I'll talk about where you can get those resources. You can use that to build your Docker image natively on ARM without having to do anything else. And it will pull all those instructions. It will pull the relevant files and it's ready to go. So it will be multi-arch from the get go. Whenever you push those images, so Docker registry, Amazon ECR and other public registries, they all support ARM-based images. In Docker registry, if you use Go and select on tags, you'll see AMD64, ARM64, X8664. So again, those are all supported and natively. So I'm sorry if I'm rushing through it. Workson ARM is our program where we offer free development platforms and resources, basically giving you the flexibility to choose which platforms you need to build your applications on. And these are some links where you can go and sign up. We also offer from the CI CD access through Workson ARM. That's the program. And if you click on it, it will get you to a GitHub page where you can request for those access. And like I said, these cloud providers also offer some free instances. You can use and try them out and see how your applications behave. And we talked about Java, PHP, you don't need to recompile, run it directly. You can all get into that. With that said, so this is a GitHub repo, which of all the blogs that I've written to date, this is in no way includes everything, but it has at least, and I'm going to keep adding to it and apologize if it's not very clearly laid out, but it just shows blogs and the presentations that I've given so far, some links. And I'm going to keep categorizing it so that whenever there is a new one that's coming up, I can keep adding to it. Okay, with that, I think that's the end. So I'll keep this one up. Yeah, so that's the end of my presentation. We do have a few minutes. So if you have any questions, please. Sure. To be honest, it depends on what kind of applications you're trying to build. I think all the major OS distributions are supported, Ubuntu, CentOS, and everything else. Are you looking for anything in particular? Yes. I don't think so that we have found any major differences. Or if I have, then I'll reach out to you. But yeah, any other question? Sure. Yeah, Ruby is supported. Yeah, again, Java-based, so yes. Sorry, that's Groovy, my bad. Ruby is supported, yeah, yes. I didn't include that, like I said, in the languages. Yes, Ruby is supported and you can develop your applications. What are the benefits? So yeah, I didn't. So if you go to the GitHub repo, basically different workloads, let's say you're using Memcached or Nginx, or what kind of applications do you use? You'll see better price performance and better performance on those individual workloads or databases, let's say, and languages. But there are lots going on under the hood with those instructions and how we build, but you'll see, again, it depends on application to application, but the price performance is usually better when it compared to AMP-based or XIT-based. What's the migration ease between going from XIT-6 to... What's the migration ease? Yeah, so that's what I said. So it depends on your application stack. If you're running it on Java and it works out of the box, you don't have to do anything. If it's a Golang-based application, like in the Docker image we saw, you'll have to recompile it, but it's pretty straightforward. You can use these instances that we offer through our either VoxoRAM program or the free resources, and you can build those directly, natively on AMP. And it depends, again, on how many components you have in your application, like databases, and so all the major database, I should have included that. So Redis, Memcached, Oracle, all these databases are supported on AMP. So again, it depends on what kind of application you have, but yeah. Not really, because it depends on how your Docker container was built. If it was built only for AMD or X86 architecture, then you'll have to recompile that and build it again. And you can go to that, Avid Graviton Getting Started Guide, AWS. They have pretty good resources to build it. Any other questions? All right. Thank you so much, everyone. Thanks for coming to our presentation. Thanks. Thank you.