- Up next, if you're a fan of containers
but just not fluent in Kubernetes,
we're joined by serverless technology expert, Jeff Hollan,
to look at the new fully-managed
Azure Container Apps service
and we'll show you how in just a few lines of code,
you can now build and deploy
container-based apps and microservices at scale,
along with how it works under the covers.
So, Jeff, it's been too long since you've been on the show,
it's great to have you back on.
- Thanks, Jeremy, it's really good to be back.
- So you've been a long-time advocate for serverless
and also cloud-native approaches to app development,
and the new container apps service
that you and your team have been working on
really helps open the door to a lot more developers
being able to take advantage of containers and microservices
as they build their apps,
and also take advantage of serverless.
You know, that said though, for a lot of us
who may have shied away from, or not paid attention
to containers and microservices in the past,
can you level set on why we would use them?
- Yeah, so after the last few years,
there's actually been this explosion of innovation
around containers, cloud-native, and microservices.
Now there's a few things at play here, but at its core,
the goal of microservices is to
help teams build and deliver apps faster
and more scalable than traditional architectures.
So let's take an example.
Think of a large retail organization
building their retail website.
Traditionally, these applications often followed
a monolithic or sometimes called tiered architecture.
You'd have one team or a set of teams
that owned the website frontend,
maybe developing in JavaScript.
They'd be interacting with a separate team
of backend developers,
writing code that integrated with backend databases.
And finally, you might have a different team
of database administrators
who would create and manage a central set of databases.
Now, while this can work fine for some teams,
it does have its limitations and the problem often comes
when one team needs to make a change.
So let's say the business now wants to support
a new form of payment.
To make that change,
I've got to have a lot of cross team dependencies
to build the frontend pieces, the logic,
and integrate with the data, all in a coordinated fashion
as a part of one big monolithic app.
This can make it really challenging
when I'm trying to ship a new feature quickly,
and the app itself often becomes complex and unwieldy.
Now, compare that to microservices.
Here, I break up that monolith
into a series of microservices,
where each microservice has a its own backend resources.
Now this way, when the payment team
needs to make a change or add a feature,
they can do that iteratively within their microservice,
so changes can be made safely
without having to coordinate across the entire site.
So building apps this way
can really accelerate your innovation.
- And for anyone who's watching or wondering,
why don't we also explain
how containers then fit together with microservices?
- Yeah, absolutely.
We do see containers as a core piece of tech
when you're building microservices,
because they're going to provide a consistent way
to package and run that microservice code anywhere.
They are a nice virtualization of that application layer.
- And that portability by the way,
also means that if it runs on my machine,
it will run in the exact same way anywhere else,
and that said though, most people use Kubernetes today
to build out containers,
so how is then the Azure Container Apps service different?
- Yeah, Kubernetes is a
really powerful container orchestrator.
It knows how to run containers and microservices
at cloud scale,
but part of that power comes from just how much it does.
So in other words, it's not always easy.
Some developers might struggle
in learning and understanding Kubernetes
just to get their containers up and running.
So for example, here on my machine
I've got this asp.net application.
To get it in a container, I will create a Dockerfile,
which I've already used to build and publish
a Docker container.
Now, what would it take
to get that container running in Kubernetes?
The first thing I'm going to need to do
is spin up a cluster using Azure,
but then I'll need to understand the Kubernetes APIs.
I need to give Kubernetes that container with all the
configuration it needs, so that's going to result
in something like this deployment manifest.
This has all of the stuff I need to run that container.
You can see there's a lot here.
I have a concept of a Kubernetes deployment
that has the container image itself and its ports.
It talks to a Kubernetes service
with ingress and certificates.
You can see there's a lot of concepts here
that teams can run into
when looking to publish these microservices.
And even once I get this up and running,
I need to make sure that I'm keeping an eye on that cluster
so that those components continue to operate as expected.
Now, let's contrast that
with what it would take to get the same container
running using Azure Container Apps.
I can deploy that container
with just these two CLI commands.
The first creates that environment,
and the second deploys the container. That's it.
- So, then I can still run
my containers and microservices in Azure,
but rather than having to do that
directly then with Kubernetes,
I can get that up and running quickly using container apps.
So can you show us then what it takes
and what it looks like to run it?
- Yeah, sure, so let's take those same commands
that I showed before and run them.
I'm telling Azure Container Apps
where my container image is,
I'm mapping to the ports that my code is listening to,
and that's it.
You can see here that after a few seconds,
it's returned back to me this URL,
and I can now go browse to run that container and access it.
And you can see here
not only is my container now running in the cloud,
Container Apps has automatically gone and created for me
a valid certificate
so I have added security when accessing this container.
So this has created a super fast path
for me to publish and run my containers.
- So it's really clear then how much simpler that flow is,
but can you share a little bit then
more about what's happening then under the covers?
- Yeah, so when I've gone and published that container
to Azure and it's now running for me
in the serverless managed service, behind the scenes,
Azure Kubernetes is actually powering that container.
But I haven't had to configure or manage it.
To provide some of the powerful capabilities,
we've layered on powerful open source technology
to Kubernetes.
For instance, every container app can auto scale
all the way to zero and inactive,
or scale to dozens of containers when under high load.
KEDA is the open source tech that makes that happen.
And as I'm deploying more and more containers
and microservices to my container apps environment,
I can use a set of building blocks
provided from the open source Dapr project.
Dapr provides a ton of useful capabilities
for every cloud developer
around secure service-to-service invocation,
pulling in data from state bindings and more.
And finally, I can run all of this tech and environment
within my own private network in Azure.
Now, even though all this amazing open source tech is there,
all I've had to worry about is my app and my container.
- Right, and by the way, if you're new to Dapr,
check out our show with Mark Russinovich
at aka.ms/DaprMechanics.
So, I see that I can still get all the benefits
of Kubernetes then for building out my modern apps
and microservices here, but with Azure Container Apps,
all that tech then, behind the scenes in this case,
is managed for me.
- Yeah, exactly right,
and to be clear, this isn't a replacement for Kubernetes.
You can build the vast majority of your container-based apps
with Azure Container Apps
and we will manage everything for you,
but if you do need to make changes to the underlying API
or orchestration level, maybe tweak service components
like bringing in your own service mesh,
well, you're probably already
a more advanced Kubernetes user anyway,
and so the native Kubernetes service
is going to give you those controls that you need.
- And that's really a huge benefit
in terms of helping people get started faster
with their apps,
but it does bring up one other question though.
When we start thinking about and talking about
these modern apps and patterns,
does this mean that I can use that
only for new or greenfield apps?
What if I've got an older and existing app
that's a monolith that needs to move over?
Can I use it for that too?
- Yes, absolutely, in fact,
the majority of teams that we're working with
are on a migration and modernization journey.
It's not somewhere you're going to get all at once
and you don't have to.
In fact, the pattern we actually see the most success with
is taking parts of your existing applications
and just modernizing specific pieces of them.
So maybe one bit of new functionality
exists as a microservice, while the rest stays where it is.
And over time, you'll actually be surprised
just how quickly your teams will end up running
in a full microservice environment.
- That makes a lot of sense,
but can you show us a bit of what this might look like,
especially when it might have a solution that spans,
say, an existing app with pieces that need to be modernized?
- Yeah, sure thing, so let's come back here
to this Parts Unlimited retail site,
and this is our retail website today.
It's a bit of a monolith though.
All of the code is in one spot
and that's presented a specific pain point for our team.
You can see here,
we're actually running a promotion right now.
But the problem comes when our site is under load
from a promotion like this, the payment processing logic
can actually overwhelm our site and crash the server.
So we want to move the payment code to its own microservice
to make our site more scalable.
So here on Visual Studio Code
I can see the code for this site.
And today, all of that payment logic
is in this CheckoutController file.
So to modernize this, I'm going to take the code and logic
from the checkout controller
and move it to a separate microservice.
Here, that's the payments controller.
Now this now has all the logic that I need
to process payments,
including connections to the right databases.
Now, I could just deploy this new microservice
to Container Apps, but in my case
I actually want both the existing website
and this new microservice running side by side,
so I've put them both in their own containers
and deployed them to Azure Container Apps.
So you can see here in my Azure subscription,
I have the Parts Unlimited website, and now I have
just this new payments microservice container,
which I've broken off and created.
And here in application insights,
actually I have a live view of these containers running.
You can see here are some of the telemetry
and charts for the health of these containers.
I even get a view
of how many of these containers are online right now.
And down here,
I see that list of these two containers running.
And Container Apps actually gives me a few benefits here.
For one, either of these containers could scale
all the way to zero if they didn't have any traffic,
which is going to save me money on my next bill.
Or in this case, I've actually configured these
to always run with at least one instance around
and that way it's always warm and ready to go.
So on the other side of this, though,
what happens when I have a huge promotion?
So let's watch.
I've gone ahead now and just triggered a load test
to simulate this promotional event.
And you can remember that this is all serverless,
so automatically both of these containers
have got that load, but the payment service
has been able to now scale independently
and much faster than the rest of the site.
So my site's been able to stay stable even under this load.
This wasn't possible before I moved to Container Apps,
and even better here,
Container Apps automatically configured
everything I needed for this auto scale to happen.
So now my team can get back to creating
even more container apps
and running even more stuff in this environment.
- So you've been able to effectively start to modernize
your app and use container apps
to start gaining some immediate benefits in this case.
And now you could continue and to create other microservices
where it makes sense if you wanted to.
- Yeah, exactly.
Here, I've been able to leverage my existing code,
bring it to Container Apps without having to rewrite
or align to any opinionated programming model.
I was able to invest in modernization
for that specific pain point around payment processing,
which set my solution up for future growth in the cloud.
Now, we as a team have worked really hard here
to create this purpose-built service
for hosting these microservices.
You can start small,
but you're going to have all the features you need
around monitoring, security, and performance
for you as your solution grows.
- Good stuff, and so for the folks that are watching now,
what's the best way then for them to get started?
- Yeah, so please try out
the new Azure Container Apps preview.
Everything you're going to need to get started
is aka.ms/ContainerAppsDocs.
That's going to include tutorials,
we've even got a quick start for you
so you can get up and running right away.
- Thanks so much, Jeff, for joining us today
and also for the awesome introduction
to Azure Container Apps.
Of course, keep checking back to Microsoft Mechanics
for all the latest updates,
subscribe if you haven't already yet,
and thank you so much for watching.
(upbeat music)