>> Cloud Native is Micro-services containers and
server-less apps that run in
Multi-Cloud environments and are managed by DevOps processes.
But the relationship between these is not always clearly defined.
Today, I talked with Abel to discuss
the relationship between all of
this and to get a better understanding.
Let's go find Abel and have
a conversation about this to get a clear understanding.
[MUSIC]
>> Abel, how are you buddy?
>> What's up man,.
>> Good to see you.
>> Hey, man. I am talking to my audience about
Cloud-Native apps and I wanted to start off with DevOps.
>> Cool, that's what I do is good.
>> Sounds good.
>> All right. So what is DevOps?
>> All right. So at Microsoft DevOps for us is the union of
people process and products to
enable the continuous delivery of value to our end users.
>> All right. So why should I care about
that when it comes to Cloud-Native apps?
>> The key here is continuously delivering value.
So one of the powers of Cloud Native
is because all of your infrastructure is out in the Cloud,
you're able to iterate very very quickly.
That's what DevOps helps you do as well,
continuously deliver value to your end users.
The speed of business is so quick these days,
if we can't iterate quickly and give value quickly, guess what?
Our competitors will, and once they do, we're more obsolete.
>> Awesome.
>> So this is super super important for people to do,
and Cloud-Native really helps enable this.
>> So how is deploying and managing
all of this infrastructure when it comes
to Cloud Native since we're all in the Cloud,
how's it different from something like a mobile app that
we might be developing or maybe a Windows desktop app,
because historically we're dealing with
monolithic apps or in a sense of a maybe a Windows desktop app,
I'm just creating that all my code,
I might have in what we've done in a path was maybe source,
say for something we're dealing with just the code,
it's in our repo, and we might be doing
just a standard deployment through
maybe an MSI or just installing that.
But now we're pushing all of that up into the Cloud,
how was it different now with this process of managing
all of these GitHub repos and really push it off.
So how's that process different?
>> So first let me tell you what's the same.
This concept of continuously delivering value, that's the same.
The concept of, locally,
I want to check my code into one of
my repos and that should kick off a build,
that build should have automation,
it should compile all my stuff,
package everything up, run all of my unit test,
and if everything looks good,
then I want automation to pick
those bits up and start to pulling
them through our environments Dev,
QA, UAT, all the [inaudible].
So that right there,
that idea is still exactly the same.
But where Cloud Native becomes pretty unique is number one,
all your infrastructure is out in the Cloud.
So in some sense,
deploying to the Cloud is easier
to do than deploying onto like a mobile app or whatever.
The other aspect is,
one of the most powerful things about
Cloud Native is you're going
to write a whole bunch of Microservices,
at the end of the day it's Microservice-based architecture.
So in this fashion,
we're able to iterate super quickly
because instead of deploying this massive monolithic,
we make one tiny little change.
>> Yeah.
>> If we do things correctly,
we can just deploy that one service,
simplifies the process, speeds up the process.
So now, every developer check-in,
can go through our gates,
can go through our pipeline,
reach production at a quicker rate.
So we're able to give value even faster and better.
>> Awesome. Let's grab a coffee.
Let's look at some of those contexts.
>> Sure.
>> Great.
[MUSIC]
>> So let's sit down.
Let's talk about some of the key concepts
with DevOps and Cloud-Native apps.
>> All right. So remember, the whole idea
is we want to continuously deliver value.
So one of the things we need to have
is we need to make sure we have a CI/CD pipeline.
Pipeline that will take our code as soon as we check it in,
I want to be able to build it and then deploy it all the
way out into whatever infrastructure that I have out there.
>> Okay, great.
>> All right. So the example that we're going to look at.
This is a Cloud-Native application.
It's actually a pretty simple application
but the infrastructure is a little bit more complicated.
>> Great.
>> It's it consists of
a static website that is held in Azure storage.
It also has a backend.
The backend is written in.NET
Core and it's held in an Azure function,
and they both connect up to a Cosmos DB.
>> All right.
>> So it seems pretty simple.
>> Right.
>> So as soon as somebody checks in their code,
remember one of the concepts for Cloud Native is, if possible,
it sure would be nice for us to be able to
deploy just each individual Microservices on their own,
that's one of the powers of Microservices,
and it really can help speed things up.
But there's a problem with that.
If I am going to deploy my Microservices out independently,
my services need to be smart enough to
realize what version is each other
on so that I don't break
the entire application just by uploading one year service.
So if my code's not ready, what does that mean?
I have to deploy my entire infrastructure all at once.
So clearly, I don't want to do this forever.
But since I'm just starting this application,
none of my services can can talk to each other in that fashion.
So right now, I want to deploy
my entire infrastructure all at once.
>> Okay, so let's see what that looks like.
>> All right. So when you look at this,
I have a whole bunch of repos that
I'm creating that I'm going to go ahead and use.
I've got my infrastructure's code.
I also have my a DNS checker function that I'm deploying as well.
It's going to check DNS for me and things like that,
and then I have my frontend code and I have my server-less backend.
>> All manages separate GitHub repos.
>> These are all in separate GitHub repos.
>> Awesome.
>> They're all connected in the sense that as soon
as somebody checks in that code,
is going to go ahead and kick off
the build for just that particular service.
So if somebody checks in code for the frontend,
it will just kick off that frontend build.
>> Okay, so I as a frontend developer,
I can do my work and not worry about a backend,
not worry about whoever is managing the infrastructure,
and that's the whole purpose of this disconnected non-relational
between the two that I can just do
my job and not have to worry
about who's doing the other things, right?
>> Right.
>> But the DevOps or relationship
between all these individual services is
that that puts that relationship together between
the two and manages that process automatically.
>> Manages that entire pipeline for you.
It's not just the code.
If you look at this build,
the very first step,
it looks like I'm deploying the infrastructure,
because that's literally what I'm doing.
Remember, one of my repos is holding my infrastructure as code.
So this entire infrastructure that we
just destroyed, the Azure Storage,
the Azure function, the Cosmos DB,
and also we're routing a bunch of stuffs
we're using Azure front door as well.
All of that infrastructure
is captured in our infrastructure as code.
So we can start from nothing.
We can start from completely empty Azure subscription,
and as soon as this build hits
and it starts running through the pipeline,
the very first thing it does is
it starts deployment infrastructure for me.
>> Okay, so that takes the actual DNS relationships
and that's actually building that up,
and that's the first thing that has to
happen before anything else gets deployed.
>> I can't deploy my code if I don't have the infrastructure.
>> So in this case I have in infrastructure,
this first box here,
It's going to deploy the infrastructure for my web frontend,
so it's going to create my Azure storage for me.
It's going to create the infrastructure for my function,
then it will go ahead and create also my Cosmos DB.
>> So how do we know what do we put in,
you've got to check DNS Beta job here,
how do we know that that's ready before everything else goes.
What's the dependency before the everything else gets done?
>> Okay. So notice I have
three parallel deployments going
on at the same time, and these two,
the infrastructure DNS, this services,
I'm actually deploying out all my DNS settings to,
I think I'm using Cloudflare at this time.
So it says, "Okay, this is in your CNAME,"
and all that stuff that we put in there.
This DNS checker.
This is a an Azure function,
and this function is smart enough that what
basically it just queries DNS to say,
"Hey, did your information propagate from
Cloudflare all the way down to my local DNS?"
>> All right.
>> So what I end up doing, is these two when they're done,
it goes into the DNS checker state.
Where I have, I'm using
a post-deployment automated deployment gate.
In this gate here,
>> We'll go ahead and ping my DNS tracker and say,
"Hey, did DNS update?"
If it did update, hooray for that pass,
and if it doesn't, go ahead and wait.
So when you set this up,
you can set a polling frequency.
So I'm saying, listen, every five minutes, let's check the DNS.
You also say, how long do you want this to run for.
>> Okay. So let's say like 24 hours.
>>24 hours, and if it's still
hasn't propagated in 24 hours, something has gone wrong.
>> Okay. Great.
>> So this will sit here at
this Check DNS Beta state and it will
ping the DNS until DNS actually returns.
The reason why I need to do this is because,
when I deploy my Front Door Instance
and then configure that Front Door instance,
there are some configurations inside of Front Door
where DNS has to have propagated for the configuration to work.
So not all situations
are where you have to wait for the DNS to propagate.
There are some things where you can just blast all the code in.
But for this example,
that's what we had to get.
So this entire block here,
that is all just deploying the infrastructure and
setting everything up and wiring
all this stuff together through Front Door,
my functions, my web app, frontend, all of that.
When that's done, I go ahead and deploy my application.
So that would be here,
my frontend-Beta and my backend-Beta.
>> Okay.
>> So deploying the frontend,
remember this is just a static website.
So literally, I'm just packaging up the files that I need
to into zip file and I
send it over to Azure Storage. It's up there.
>> Okay. In this case, it could be anything.
So this is just a static website that's running on Azure Storage.
It's probably something like a View app or
or it can be just static web files,
HTML files, and we're just placing it there.
So that is just one step.
>> That's just one step in.
So this is really a View app.
>> Okay.
>> Right. Then I go ahead and deploy my backend.
Deploying the backend is equally as easy because remember,
we're deploying a.NET Code into an Azure function.
>> Okay.
>> So it's just one App Service task.
Deploy this into this particular
app service and [inaudible] that we're done.
When both of these are finally done,
then we get to a manual approver gates.
Where, of course, I'm making myself the approver.
But basically, now, I get to say, hey,
now that the app has been deployed into my Beta infrastructure,
let me go ahead and test it, make sure it looks right.
If it looks right, I can go ahead and approve it.
As soon as I approve it,
it then flows on over into my production stage.
So my production stage, notice,
my production stage, I do the same type of stuff.
First, I need to deploy my infrastructure for the frontend,
the infrastructure for the backend,
then deploy the code, and then hooray for that and I'm done.
>> Okay. So would you say that
DevOps in this particular situation is like the glue?
We're gluing all of our steps, all of our infrastructure,
all of our code together,
and that's really the relationship that we have here.
Looking at your flow that you have here,
this is an initial stage,
but if I was just to make
a simple change to like my.NET Core Azure function,
could we have a flow that's maybe
parallel to this and says this is an update.
We know that our DNS is good.
We know that our front door is
setup and I just want to make an adjustment.
Do I have to go through this whole type of a flow or
is there another concept where we can say we know it's an update,
everything else is check,
and I just need to go ahead and post an update?
>> If you know it's an update,
you can just deploy to you whatever particular stages you want to.
>> Like a Feature Flag almost, right?
>> Yeah.
>> Okay, perfect.
>> So you don't have to pull it all at once.
In fact, as soon as we add
some more code so that
our services will communicate with each other.
So if I'm the web frontend acquiring my backend,
I could be like, what version on your app?
You've run version two and not on version three?
Then, I'd better just run the version two code on
my end not the new
version three stuff because you don't have it yet.
So once we have that type of code in place,
then we can just deploy
the Microservice and not the entire stuff all at once.
>> Got it. So I'm going to step
into a scenario that probably you and I,
we've been in this business,
we've seen monolith applications.
We've done the right-click publish,
but I want to paint this scenario for us.
I know that you and I,
we didn't work at the same company in
the past but we probably lived
the same stories where our QA,
and our production, and our development
environments didn't match, right?
>> Right.
>> We had one Dev box probably under our desk,
and we had two maybe QA,
and as we went to production,
those environments didn't match.
>> Right.
>> Okay. So how do we ensure quality across
our environments in a DevOps practice type of situation?
>> One of the coolest things about being
a Cloud Native application that
means our infrastructure all runs in the Cloud.
Which means notice I'm using infrastructure as code.
So as I go from one environment to the next,
the very first thing I do is I go to
my infrastructure as code files and say,
hey, deploy this infrastructure format.
So now, we are absolutely guaranteed that
my Dev environment is exactly the same as my QA environment,
exactly the same as all the way out into production.
>> Okay.
>> It's cost-effective because we can just spin it up,
run whatever we need to and as soon as it's done,
tear it down so we're not paying for anything anymore.
>> I can really manage all of my apps using Containers as well.
I mean, that's one of the beauty of Cloud Native.
>> Yeah.
>> We're using containers.
I have that all of my dependencies inside of that.
Now, in this particular situation,
we're not using Containers.
Server-less helps us out in that situation.
The frontend app is just static HTML.
We could wrap that in Containers but that's shipping
your blog on a on a semi type of thing.
>> Right.
>> But we could manage that infrastructure that way.
>> Yeah. We could have done this all with
Containers but it's such a simple application.
>> Right.
>> It literally is static website, one Azure Function.
It seems like containers would be a bit overkill.
>> But this is almost the simplest form
if you will of a Cloud native application.
>> Absolutely, yeah.
>> We are using the Cloud in our Server-less.
We are managing our environments.
We could add a QA,
and a Dev, and production,
and a test environment.
>> Absolutely.
>> We can do all of that.
Again, like you said, this is very simple
but it does set the relationships up for
us across all of our infrastructure in
our code in order to to grow up from there.
>> Yeah.
>> So let's move forward a little bit.
How much can you really automate this?
You've got a couple of manual steps in here,
and I've built some pipelines playing around
in here where I get an e-mail that says, "Hey, approve this."
And I'm blindly go sure.
Push it forward, I'll deal with the problems later.
Can I really automate all of these types of steps?
You said you've kind of self approve.
Could I have multiple approvals or you do it and maybe
I sent it to Susie and Susie says
yes and then it has to go up the chain.
How much of this can we really automate with this process?
>> So this is super cool because you
can automate almost everything,
but I do like having
manual approvers when I go
from one environment to the next environment.
I want to have someone actually check
it to make sure it looks good.
>> Okay.
>> Within Azure DevOps,
a tool that we're using to to build out our pipelines.
There's a concept of an automated approval gate as well.
So you can use automation to help you
decide should we go on to the next stage or not.
So I'm using an automated approval gate to do my DNS check.
Has DNS propagated on them?
>> Okay.
>> Right. So before
we had this automated approval gate for the DNS checker,
there had to be a manual approval step. Stop right here.
Don't do anything, check DNS and when it finally propagates,
then say I approved then it can go on.
I can save myself as manual step now
because I have this automated gate that can do that for me.
>> Sure.
>> However, when I finally deploy into my Beta environment,
I still want someone who looked at that.
I still want someone to be like, yes,
I'd give it my blessing before it goes on.
>> Right, okay.
>> So the idea is I want to automate as much as I can.
Is 100 percent automation possible?
I don't think the goal is for a 100 percent automation.
>> But we get include things like as far as automation,
we could put in testing.
>> Absolute.
>> I can deploy it to my QA.
I can run a bunch of tests.
Have that as a block in here.
It says it run my tests and then still have that manual gates.
So we can insert those manual spots wherever we want to.
>> Absolutely. So trying to keep quality in your pipelines,
that's really difficult to do as well.
So yes, you can do things
like let's go ahead and run all of my tests,
my automated UI test for this particular environment.
Let's say I deploy this into a QA environment,
by the time my QA testers even look at it,
it could have run through like hundreds,
thousands of automated UI tests already.
So there's much less than a human being needs to do.
>> Okay, perfect. Is there any other concepts that we
haven't touched on just wrap up this session
here that you think are important
to mention when it comes to building Cloud Native apps and
when you've talked about using
actually a Cloud Native practices here like you've
used a Server-less function to check your DNS.
>> Yeah.
>> You're using Cloud Native to check your Cloud Native.
>> Yeah.
>> All right. So to wrap this up,
is there any other things that you want to touch
on other than just go and check it out.
>> Just do it.
>> All right. So that wraps up
our session on Cloud Native apps using DevOps.
For any other information,
be sure to go check out the show notes. Thanks for joining us.
>> [MUSIC]
>> Thanks for watching the Cloud Native Show.
Be sure to subscribe,
watch for future episode and
especially our streaming shows on Twitch,
where we build apps based on
the conversations had right here. We'll see you next time.