Hey
folks. Welcome and for those of you have been waiting
for over 15 minutes.
Thank you for waiting. We hang some hard technical difficulties
so far,
but we were able to breakthrough them.
So thank you for waiting and for joining.
Let's kick start real quick so my name is Josh
Palma an I'm a PM lead on the HS team
and I'll hand it over to Craig.
Thanks George.
I'm a PM on the upstream team so I work
closely with the case team to work in the open
source community.
Back to George. Yeah, so
just quickly going through it.
You've already been asking questions for any questions that you
may have.
Please use kind of the question box.
Ask them an essentially our team of expert as well
as ourselves will either address them live via voice or
we will address amount on chat as well and with
fast so we can tackle all your questions that I
know you've been waiting in.
This session is being recorded so please do not spam
or try to kind of put inappropriate comments on the.
Question boxes and please adhere to the Microsoft Code of
conduct that we have on the next slide.
An as a final point,
probably give some time to 4 hour Smiths to introduce
themselves,
so from left to right,
Ellen.
Alright, so
I'll go first. Hi everyone,
my name is Ayobami. I'm a program manager with the
app DEP,
CSU team and happy to be here.
Work pretty closely with George
and team. Sounds
good, don't want to go next.
I'm
down high principle customer customer engineering,
ISV for fast track so I I deal with a
lot of eyes V customers as well as startups and
with you know,
containerization. A lot of open source containerization,
ISC infrastructures code as well.
So
I
good Alan here back, yes.
Principal software architect in Azure global engineering.
Working on things like Azure Space
Azure, Willy Emulator, Anna Secure,
Secure software, supply chain, Cool Rag run.
Rogram translation Arctic in the worldwide absent for tech strategy
team,
the customer Success Unit.
Very good and we have rehab as well.
I don't think we have a shot.
Right, so so that's the team,
and so let's maybe get the questions started.
Sure, so let's see. We've entered some of them already
online,
so most recently we've got a question around the Windows
Unification initiative.
I don't know if any of our panel of experts
or wherever that I'm guessing George,
you probably are aware about,
or at least I know I'm not.
Any of us have expertise in that area?
No, no, without context, maybe we can ask some some
clarification on that,
sure. OK, so other interesting questions are.
What are the major limitations when you're containerizing applications and
sort of?
What are the newest developments in containers that help us
get around those limitations?
Interesting well effectively concerns are bit of a catchall and
in some cases an.
There are natural workloads that don't really fit.
I think we had a question before in terms of
like.
UI based scenarios, for example.
That's really not usually a container native scenario,
so having you wise and console applications really in containers,
but there are many efforts still ongoing containers.
Still a very fluid and new technology to make sure
that all essentially scenarios that you can think of are
properly support.
I don't know if you want to talk about it
from an upstream perspective,
correct? A lot of the essential applications about hardware and
resources about hardware being exposed to containers is definitely something
that is still evolving.
Because there are many, many pieces for Arbor.
If you think few years back containers didn't even support
things like GPU or NUMA alignment or several networking capabilities.
So today it's really brave.
New World where most things that are usually exposed already
for years passed through hypervisors into into VM's and into
physical servers.
Today they're really exposed to containers and there's even new
developments happening.
For example on the fuels of confidential computing,
where really the technology is almost going.
Painter 1st and being developed with containers in mind.
So definitely a lot of things are bringing contains this
party.
Yep correct
yeah. Thanks George. I think the the only thing I'd
add is that it's really interesting to see how as
we get exposure of more of these underlying physical resources
into containers. We're starting to see some of the container
drivers try to solve exactly the same problems with hypervisors
with proper solving with resource sharing,
resource contention, and isolation of the processes and the permissions
for those processes.
So the line between hypervisors and containers is gradually blurring,
certainly in both Linux and Windows world.
In the Windows world, I think the interesting thing we're
seeing is the.
And this is one of the announcements that came out
this week.
Is that container D is now in preview for Windows
in Aksi an that allows for leveraging HTS version two
in Windows,
which will expose more and more of the underlying host
capabilities into containers.
And with a big focus on resource management going forward.
Hopefully that was helpful. Cool.
So. Uhm? There's a question about Azure migrate and.
I think they were just asking for the link,
but I think it might make sense to spend a
minute just kind of talking about the migration tooling and
what Azure migrate is all about.
Yeah, good question. I'm sure folks on the chat can
definitely provide a link,
so Azure my Azure migrate tools,
the tools to migrate workloads for Azure and has announced
support for migrate.
The migration of both.net as well as at job applications.
Then you have link on our documentation for both of
them and it's really to help you both take inventory
and discover existing running applications like it running JVM application.
And then effectively help you create the necessary steps containerizing
it,
creating a Docker file created Kubernetes manifests and then deploying
it into a live Kubernetes cluster.
Show the folks were able to share the length the
meantime.
Otherwise, I'll take. We can share them
as well, so maybe you can help me understand that
makes sense for kind of a simple,
straightforward application, or there some kind of constraints about what
kinds of applications make sense to use that kind of
migrate tool?
Or is it very general and can work with
anything?
Yes, right now it's only it's only supporting java.net then
the team is really expanding that into the additional array
of languages and the idea is that we want to
keep kind of getting feedback from what should we go
after next?
And what kind of applications we we should target next?
Those were two of the biggest tasks that we have.
Really, some of them or even some sometimes more legacy
applications that were even harder to containerize,
and so This is why the tool went after those
first to kind of help with that process and help
with that journey.
Fix it or we have another question around OSM,
so for those of you don't know it was is
open service mesh and it's an open source project that
tries to solve the sort of 80%
problem for service meshes. Solving the the key East West
traffic shaping and.
A mutual TLS problems that are the core of service
mesh without having all the bulk of of a complex
system.
It's still a complex system of course to do all
those things,
but there's a lot more than it tries not to
do,
and there's a question around.
It's ETA, and I assume that's ETA for GA in
the MKS.
Yeah, it's a question and I'll tag team this one
with correct so the the the ETA for for GA
with a cast is going to have as a key
milestone before that one. The actual ETA for stable of
the upstream open service mesh project.
And then after that we will fast follow with the
GA if you want to talk about the timelines were
thinking for for stable on the projects always depends on
the necessary signal, customers, community adoption and a lot more
factors than just technical factors.
Craig went a little
bit about that.
Sure absolutely. So the project is still.
It's evolving not as nearly a rapid pace as it
was,
say, six months ago. It's reaching a level where we
have good confidence that the core feature set is what?
Your matches what people really need to do an in
their clusters.
Obviously, even once it's stable,
they'll be new features, but the goal is to get
to a point where the API's aren't changing and so
your operational model won't change anymore.
Right now the trajectory looks like that stable point will
happen during this calendar year that will be in a
position to do that.
We're getting significant sufficient feedback to come to that degree
of confidence,
and then sometime after that,
obviously a chaos will then be able to J.
So there's no fixed date at this point.
It really depends on how much.
Quality feedback we get from early adopters and users,
so you know if you want it earlier evaluated earlier
and tell us how that's working for you.
So let's let's see what other interesting questions do we
have to meet here.
There's a lot. Thank you guys and keep them coming.
There's a question here about cloud bursting,
which is an interesting sort of scenario based one,
so they have an application with microservices and they want
to make sure that when they burst all the dependencies.
Our first HTTPS. And that they resolved.
Either cloud specific or on premise specific implementations,
so they're they're thinking about how to approach this kind
of birching scenario when you may have specific services available
in different environments,
and so you know it's it highlights the challenge that
application developers have when you're you have to consider what
APIs are available where you have any thoughts about that
George.
Yeah, the kind of approach to to use HTTP to
kind of resolve them to different environments.
Definitely a common one and generally generally used.
It still doesn't remove a lot of challenges that we
see when bursting from on Prem to to the cloud.
That's definitely something that is still very much on kind
of the application side and the customization side on the
user to define how they're actually going to burst.
Obviously the cloud is providing the burstable environments and then
you actually need to.
Essentially, take care of the actual bursting and scheduling a
cast and Azure have several things to help with that,
namely, for example of one of our open source projects,
like the virtual kubelet, which could actually allow you to
contribute to it and expand because it actually gives you
a virtual node on,
for example an on premises Kubernetes cluster that then allows
you to expand to essentially whatever that virtual node points
to on a cast.
For example, we have one of the offers is called
virtual node,
which essentially leverages this technology too.
Burst from just regular VMS as nodes into Azure container
instances and so it kind of becomes this infinite API
that you used to schedule pods and you can use
exactly similar approaches from on Prem as well by extending
and contributing back into virtual kubelet,
you could use same thing for took a bullet to
extend from a cast.
For example, a device at the edge so a little
bit of the opposite scenario where you could do virtual
kubelet to IoT edge,
for example, which is another one that you can have
there and you have many providers already on virtual cable
that you could use.
And you can also build your own and contribute back
some to meet your scenarios.
So we are looking as a kind of a point
of road map.
It is a scenario that we are actually looking to
have some design and some investment in the near future.
Great response, we love we love all the work and
contributions,
diverse kubelet. Thank you. Everybody who has done that.
Another really interesting question here is about state management for
applications.
So we all know that 12 factor only meets a
very small percentage of real workloads.
For most people, and so the question is around,
is there support of some libraries that are being provided
to make things easier,
at least on the Azure platform,
and it's kind of a follow up question is.
It's asked like is service fabric not recommended going forward
like what's our?
What's our stance on service fabric versus state management and
other Azure services?
Yes I can. I can start from.
I guess the the end and go back to the
beginning.
So essentially it's not service fabric is not really recommended.
Service work is there and is set to stay.
It's more that we acknowledge kind of the the desire
from from our users to actually standardize on Kubernetes and
Cloud native as well as in this kind of a
more portable platform in Kubernetes based platform.
Which is why we've you see all kinds of solutions
and a bit of a pivot.
For kind of azure's investments and even highlights and spotlights
to actually be on a KS and companies based platforms,
so that's mostly response on.
Essentially what we hear from our users in front from
the market as well,
but service fabric. If you're there,
you don't need to run away because you hear little
sessions about it or something like that.
It's definitely still a very solid platform for you to
stay.
On the other hand. Did had I would say some
pretty nice features and capabilities in terms of state.
Some of some of them were actually bringing into HKS
through several distributed applications.
For example, we can think of Dapper as a way
to actually bring a lot of that same capabilities into
a Kubernetes based environment,
as well as that the integration that has with with
the Azure storage components now.
So we take ASU can vary in a very raw
fashion.
Interact with Azure disks with Azure Files,
NFS and now with the advent of CSI drivers,
which is a new drivers for.
Pro Kubernetes you can actually go across and say hey
I need blob fuse and I need to interact directly
with Blob where I need to interact directly with an
FS or Azure files and you can really go on
and have direct integration with all of them without having
to actually create the storage or manage it etc.
And from a developer perspective from application perspective things like
Dapper really also simplify that distributed storage access.
That's a great answer. So one more really interesting question
here is and I really appreciate people staying on even
though we're scheduled past the scheduled time.
It's very helpful and keep this question coming.
The question here is that I have an application with
multiple services and I'm currently currently using Docker Compose to
group them together.
What's the best practice to deploy these to production?
An I I'll take the follow on there that this
production on Azure.
That's my color. Uh. So
there are several aspects to it.
The first, the first thing that I would ask is
if it's already in production.
Is there a need? Essentially,
what is are you still bringing it to Azure?
Have you looked into things like for example Azure Migrate
which already has as well again this this Docker support
in order to bring it?
If you if you went into essentially the documents for
like your Docker on Azure and hosting those environments,
or you're looking for something more into bringing these applications
into Kubernetes for example and wanting to bring from Docker
Compose and kind of doctor native tool set into the
more carbonated based tool set.
So depending on which challenges we're trying to solve and
where you want to go,
you could go into as very simple as just creating
a Docker Docker swarm,
E whatever cluster on Azure.
Just deploy, deploy them and keep state Docker native.
Or if you want to use and leverage Kubernetes,
you can use tools. Like compose with the key that
essentially allows you to translate some of the Docker compose
kind of manifests and elements into Kubernetes manifest in elements,
and then allow you to go from there into a
chaos criminals cluster and start to deploy there as well.
That's great answer. I just added that to the chat
help folks out.
So we're running out of experts and there aren't any
new questions yet.
At this point, maybe one last one.
Nope, this was not. It was a private response.
Sorry bout that. I think we're done with questions so
maybe we can share the resources and wrap it up.
I think this was super helpful for me.
Alright, thank you very much for bearing with us until
the end folks Ann.
Braving through the initial issues.
We appreciate everyone's time and please keep questions coming in
our public facing forms such as Microsoft QA and GitHub.
And here you see some resources for you to both
learn as well as start to adopt containers on Azure.
Thank you very much folks.