NAREN NAYAK: [MUSIC]
Hello.
I'm Naren Nayak. I'm part of
Ampere's customer and developer engineering team
and I'm responsible for ensuring you,
the developers get the most out of
Ampere's silicon products through software porting,
optimization and developer outreach.
Welcome to Microsoft Build.
Ampere is a five-year-old company that is
laser focused on designing high performance,
scalable and sustainable processors for the modern Cloud.
As a matter of fact, we designed
the world's first Cloud-native processors
that are delivering high levels of performance,
scalability, and power efficiency on
today's hyperscale Cloud and edge computing application.
I am thrilled to be here talking to you about
Azure's computer infrastructure that is powered
by the Ampere ultra ARM-based processor.
The Dpsv5, Dplsv5,
and Epsv5 virtual machines
are all powered by the Ampere Altra processor.
Over the last six months,
I've demonstrated stellar performance and
price performance on
real-world applications running in Azure.
Over the next two days,
you will hear firsthand from
our partners about their experiences in
migrating to the Azure Ampere Virtual Machines
and the value that they have derived from doing so.
Let's discuss the five steps that we
think will ease the architecture transition.
Learn, assess and plan,
build, test and optimize and deploy.
Let's start by learning a little bit about
the technology that powers these virtual machines.
As I mentioned Ampere Altra
is the world's first Cloud-native processor.
Well, what is a Cloud-native processor?
It's a processor that runs Cloud-native applications.
Applications that are born in
the Cloud and are typically designed
to take advantage of features Azure strives to provide,
like scalability, elasticity, and high-performance.
These core tenets and more were what we
had in mind when we designed the Altra processor.
Altra was designed to be sensitive to
developer ping points around programming and deployment.
Let me offer a few examples.
Our design has features like
single threaded cores for predictable performance.
Larger private caches closer to
the cores that are
beneficial for multi-tenant Cloud environments.
This provides a clean Cloud targeted design.
It also avoids architectural legacies
like the reuse of designs for different form factors,
which leads to features like simultaneous multi-threading
or SMT and opportunistic turbo frequencies,
which might be a good fit for
applications you run on your laptop,
but not so much in the Cloud.
Simply put, when you deploy on the Azure Dpsv five,
VM family, you pay for a certain number of virtual CPUs.
Each of those vCPUs is a real core,
which runs at a fixed frequency.
That makes for predictability of performance and makes
your application more resistant to noisy neighbors.
If that sounds interesting to you,
we invite you to tune in to
the various technical talks here at
Microsoft Build and at
the Ampere Developer Center at
developer.amperecomputing.com,
where you can find a collection of
technical documentation on our products and a lot more.
Once you're ready, I'm sure your first question will be,
how can I experience what
a Cloud-native processor can do for my applications?
Well, Azure has been offering
the Dpsv five VM family since last year.
It includes virtual machines which have
different core and memory capacity options,
making it much easier for you to
pick the right virtual machine for your usages.
The Ampere Altra processors are built on
the ARM instruction set called AArch64 or ARM64.
Yes, the same ARM architecture that
powers billions of devices across the world.
ARM64 has had the benefit of
years of software investments required to make it sync.
This transition from legacy architectures to
ARM64 is a once-in-a-lifetime opportunity for you.
I'd like to share a few of
the developer considerations and
some examples you might think about
as you join many of your colleagues in
using the Azure Ampere based Virtual Machines.
I use an outline that shows you
a variety of examples for developers as you learn,
assess, build, optimize, and deploy on these VMs.
As with all exciting endeavors,
it starts with assessing your options.
As you plan your transition,
a good start would be to do an inventory of
your various software stacks from operating systems,
programming languages, databases, applications,
infrastructure and DevOps tools.
This allows you to map a path out to
software versions that have been built
for and tested on ARM64.
Let's start with the operating system.
Most modern OSs, like popular Linux distros,
support Ampere Altra processes out of the box.
ARM64 is prevalent globally
today in many systems and platforms.
In Azure, you will find ARM64
builds of Red Hat Enterprise Linux 8.6,
Susa Enterprise Linux 15.5, openSuSa Leap 15.4.
Ubuntu 18.0, 20.04 and 22.04.
CentOS, Debian 11,
Alma Linux, Flat car,
as well as Windows 11 Preview.
All of the software needs the right build environment.
Most open source software stacks support ARM64
natively and have
extensive documentation and build instructions.
Popular native code compilers like
GCC and toolchains like LLVM2 as well.
Programming languages like C++, Java,
DotNet, Go and Rust support ARM64 out of the box.
Let's talk about a common question we get
from folks who are planning their migration.
What type of applications
should I use these virtual machines for?
If your applications are written in
runtime languages like Java or DotNET,
your migration will be much easier.
These applications abstract the underlying architecture
with a runtime layer and in most cases,
you truly write once run anywhere.
We have partnered closely with Microsoft
on tuning the Microsoft Build of OpenJDK,
as well as the DotNET
Framework for Ampere Altra processors.
Most open source applications for
ARM64 are either readily available as Docker containers,
all through software repositories
available as part of your favorite distro.
In memory caches like Redis databases like PostgreSQL,
big data software stacks like Spark run very
well on these Virtual Machines with
little to no source code changes.
In general, as I mentioned earlier,
this Architecture was built
for the Cloud native paradigm.
Web and front-end workloads that
can scale out will also do well.
A general rule of thumb the newer the version
and the more current your
software environment and practices are,
the easier the transition will be.
Whether its operating systems,
compilers and runtimes are open source applications.
At this point, I must point out something that's
subtle yet critical to know about your migration path.
It's better to not treat
this as an all or nothing proposition.
The Cloud native paradigm is designed to be,
among other things, multitier architecture friendly.
Software ported over to ARM64 can co-exist,
but legacy code and alternative Architectures.
Think more along the lines of a Venn diagram,
where you can consciously match the needs of
the software with the right hardware.
Consider applications that have
ARM64 support today and can port over with little effort.
Applications that have a meaningful footprint
in your overall business,
and applications that can benefit from features
Ampere ultra provides like predictability,
compelling performance, and cost savings.
Another question we hear from developers is,
how difficult would it be to build my application?
More often than not,
developers I've been pleasantly
surprised with the process.
We frequently hear it wasn't
that different from bidding on other Architectures.
However, there are numerous facets
that can affect this migration,
including the size of your application,
the programming language use,
and the level of Architecture
specific optimizations you have made your code.
Let me give you a real-world example.
PostgreSQL is
a very popular open source relational database system,
considered to be among the top
five databases in use today.
What would it take to compile
PostgreSQL from Ampere Altra Processors?
Surely it's not that easy.
Five lines, that's what it takes to build PostgreSQL.
You will find many transition and building
guides and tips such as
this on the on Ampere Developer Center.
The next step is to test
and tune your applications for your infrastructure.
For this, you can use industry standard tools like Perf,
Cysteine and eBPF to find your bottlenecks and fix them.
The profiling and introspection process in
general is similar to what you're
used to on legacy Architectures.
As far as performance expectations go,
there are a few things to be aware of.
As I mentioned earlier,
since Ampere's Altra Processors do not use SMD.
Every vCPU on the Dpsv5 VMs maps to physical core,
whereas those on legacy processors mapped
to two or more logical hardware threads.
This allows for more predictable performance,
especially as you push your VM loads higher.
Our recommendation increase the loads
on your Dpsv5 VMs to ensure you
get the maximum throughput from your applications
with latencies that comply with your business SLAs.
You might find that you can rightsize your infrastructure
to your requirements and save on CapEx cost.
Remember Ampere Altra does
not use opportunistic turbo frequencies.
Turbo is a technique that is allowed for
increased CPU frequencies and
overall load on a server is low.
Performance tuning is as
much of an art as it is a science.
You can find real-world examples and performance briefs
during tips and optimization
guides on the Ampere Developer Center.
Now that your applications are tested in
tune for your Dpsv5 VMs,
the last step is to deploy
our applications on the Azure infrastructure.
This starts with rightsizing
Virtual Machines for your applications.
Azure has six different Virtual Machine types in
regions across the globe that are
based on the Ampere Altra Processor,
ranging from one to
six vCPUs with 2-8GB of memory per vCPU,
and several storage options.
Next up is updating your infrastructure as
code tools like Terraform or using
the Azure Resource Manager templates to be
multitier Architecture and updating
your auto scaling groups.
Docker image manifests list are a great way to support
manifests for legacy Architectures as well as ARM64.
When it comes to using
orchestration systems like Kubernetes,
it's a good idea to evaluate
managed solutions like Azure Kubernetes Service or AKS.
AKS has been ported over to run well on Ampere Altra
based servers and offers a seamless migration to ARM64.
Let's do a quick recap on what we've discussed today.
You've learned about the newest addition
to the Azure compute infrastructure.
Virtual Machines powered by
Ampere Altra Cloud native processes.
We've talked about the assess,
build, test, optimized appoint model,
and about how it makes sense to
migrate in phases, starting with migrating,
impactful applications that are
straightforward to migrate,
and the value of a multitier Architecture design.
We've talked about what makes
the Azure Dpsv5 Virtual Machines different.
The predictability and scale out design features
that can yield compelling cost savings.
Along the way you've heard about the developer resources,
Microsoft and Ampere and have made available that will
help you in this once in
a lifetime Architectural transition.
You can find links and demo videos throughout
our Ampere Virtual Showcase Page at Microsoft build.
Ampere we are passionate about
enabling developers to their best work in a performance,
cost effective and sustainable manner.
As we like to say, it's good for the developer,
good for your pocket,
and good for our planet. [MUSIC]