Coming up on the show, we go deeper on the Ops side of enabling
a DevOps approach with Azure stack.
Which provides a model for developers and IT to work together
throughout the building and ongoing operations of apps
We're going to show you how DevOps evolves conditional, development, and operations lifecycle.
How you can forward with Azure stack.
And how that approach can be applied to all of your apps in a hybrid cloud.
Microsoft Mechanics
I'm joined today by Natalia from the Azure stack team, welcome.
Thanks Jeremy, it's great to be here.
If you're not familiar with Azure Stack,
it's really a new way to bring the power of Azure
into your own data center.
In doing so, you can use some of the same infrastructure and the automation,
and developer resources that you might use an Azure in your location of choice.
But, more importantly it supports modern development practices.
Yeah, that's right.
The key is consistency.
So the things you do in Azure
could translate to what you do in your local Azure Stack environment.
It's the same code.
You can use in mix the two environments to create true hybrid services.
Something we hear a lot today is the term DevOps.
Most folks watching are probably
on the Ops and IT side of that.
So what are we solving for here in relationship to the approach that we're taking with Azure Stack?
Let's start by defining DevOps.
It's really the merger of the application life cycle and the operation life cycles.
To illustrate it might help to take a step back a bit
in the context of building and running an app,
to see why DevOps is such a powerful force in the industry.
Now I've got an app built here around a fictional healthcare company.
They're trying to invest in new underserved geographies
with limited network infrastructures to help manage a hospital.
It really is to help them move from a paper to a digital business.
The hospital information system has rich features
to effectively manage the complexity of hospital operations.
This app can manage patients, appointments, imaging, and medication.
Really everything required to manage the electronic medical records
and logistics in the hospital.
The application runs in Azure Stack.
If we go to the Azure Stack portal,
you can see that the instance of the hospital run is running in the Azure Stack portal.
If we look at the resources from the infrastructure perspective,
all the resources
to run this application are in Azure Stack.
To build this type of robust application,
we need people.
Poeple to understand healthcare specific features.
Developers to write the code and make sure it works.
We need people to buy the infrastructure hardware,
set it up, management,
and people to ensure the system continues to operate like it's supposed to.
This is true for any kind of app development project.
How is this done today?
I'm going to talk in really broad strokes here.
You have the development team on one side
that understands the workflow,
they identify requirements and ultimately they put that into code .
They're typically paid to complete the feature work on time and with quality.
I think we all know how this goes.
They throw that work over the fence to us, the IT operations team.
We've got to pick up all the pieces and determine how everything gets running.
Yeah, that's when the operation team takes over.
They read the documentation on how that works.
And sometimes there's not always documentation for that.
So again, we have to figure that out.
Yes, and they get it running and keep it operational.
For the Ops team,
reliability, compliance, and financial management really become their main focus.
As a result, Devs don't need to access the infrastructure resources
unless there's a critical issue.
IT is focused on up-time or they're in brake fix mode.
The outfall of all of this is IT is left alone.
If something is broken, they have to figure out how to fix it.
A lot of times the Devs have actually moved on.
So how does this now change and get better with dev ops.
DevOps remove the barrier between developers and IT.
And then it unifies efforts around the customer experience.
So if we reorder the life cycle.
The developers continue to be accountable for the app.
So IT is aligned from the beginning in defining and supporting application resources.
That means we can build and deliver reliable applications faster and with higher quality.
Now you'll see the support has moved to the front of the cycle.
It's no longer just the IT related break-fix
kind of help desk function.
But, it focuses on supporting a great customer experience.
That includes ongoing customer requirements management,
shipping new features and functionality,
application monitoring through telemetry, automation, etc.
DevOps continues to iterate with customers through the entire development life cycle.
Creating hypothesis on functional requirement.
So really, it's a virtual feedback cycle.
Apps are also instrumented to get data on usage patterns, failure, etc.
Support can be proactive and not just reactive.
Since developers are really on the hook to support their own code
they're probably going to be incented to make sure their code doesn't break.
And, IT can better understand their requirement.
So what's the next phase?
Next, the develop and build phases are merged.
So there are a lot of DevOps practices.
One of the key DevOps practices that makes this possible
is the introduction of infrastructure as code.
That allows developers to get their infrastructure from a cloud.
They build the environment
they need as a code artifact and create the exact same thing from dev to test to production.
With infrastructure as code,
the infrastructure becomes part of the app.
So, bringing us back to what we're delivering Azure and Azure Stack,
are Azure Resource Manager templates.
Really the automation and the mechanism that lets you deliver infrastructure as code
Yeah that's right, it give IT the ability to work with developers
to automate and monitor the assignment of app resources,
and set guard rails and policies for the app.
Developers can easily see the resources available to them
and continue to use their preferred code management tools.
Things like GIT or Visual Studio online.
Let me go back to our Hospital application to illustrate.
Merging the app code and infrastructure code has huge benefits.
So here is the arm JSON template
that describes the infrastructure building blocks needed to get that hospital app up and running.
If you look, all the resource specification apps are here.
You've got things like storage
You've got network profile.
And we've got some of the VMs down here.
An Ops team can additionally add management functionality.
So if I drill into the template
I can add the operations management suite workspace into the code for the app.
So that means every time the resources is created from this pattern,
it will be brought under management.
Here I have the same arm template
they have for the hospital application.
but we've added a snippet of code
that installs and configures OMS.
Okay, so I can see the OMS agent install and workspace.
Yeah, look how little code it takes to make sure the resources are managed.
If we go back to the Azure portal,
we can see that the management extension
that the Ops team can use to make sure that the application is managed
and that asset is managed.
Here you can see,
we've got the OMS agent for Linux there.
That's the beginning of managing inventory
and availability and spend on the application.
If I switch over now to the OMS workspace.
Here we are in the OMS workspace that we previously configured.
You can see that the application is under management.
Anytime it's deployed and that means anywhere in the world.
Whether that's in Microsoft's data center,
an enterprise data,
or with the service provider offering Azure Stack .
The consistency enables the same skill set to manage the applications in Azure
or in Azure Stack.
The nice thing here,
the arm template is really a blue print.
Every time I provision that app,
I'm going to have the same management everywhere.
So, this is really great.
Now Devs actually get what they need from an Ops perspective.
I from the IT pro perspective get what I need,
visibility into what the Devs are actually building.
I can see who is using stuff.
What resources they are consuming and which rate they're consuming.
But, what happens then after developing and building?
Then we consolidate test and stabilize phases of the life cycle.
You want to test code and stabilize the infrastructure.
So here we'll do more automated testing
and we're adopting continuous integration and deployment.
That gives us more agility.
So let me show you automated testing.
So here,
since we're building a cloud we can automate testing in both
the app code and the infrastructure code at the same time.
Here as you can see, we're in Jenkins.
That's our app integration service.
We configured it to deploy and test our infrastructure.
This is the deployment output
from the template that we showed earlier.
You can see
that it's succeeded, the deployment succeeded.
It's basically a log of what happend?
Yes.
At the end, we can actually see the test results.
Since this is succeeded in Azure Stack,
we can deploy the same code to Azure and vice versa.
That's the value of the consistent platform.
It''s really a great place for IT to bring your knowledge in and expertise
about the build process.
Because all those years you spent hydrating out Dev test environments,
building all those task sequences,
educating Devs and other infrastructure folks on your team.
That really comes in handy here.
And maybe you'll get a few less emails for reprogramming stuff that's broken
Yeah, you invest in automation
because you know that it's going to work wherever you choose to deploy.
The feedback can be provided to the development team to improve the code,
and the Ops team so they know what's coming.
Since we used OMS to manage this,
we can track inventory and spend for every phase of the life cycle.
That way everyone can focus on what they're good at.
Ops can focus on the operational integrity of the system.
Developers can focus on the functional quality collaboratively.
And of course since we're using the cloud.
We can actually dial up and dial down resources as required
and really use it's elasticity.
Yeah, you can use subscriptions in Azure to control access to the resources, too.
The last piece to think about,
is the merger of Maintain and Deploy.
The way to think about this is continuous deployment and continuous maintenance.
We have ongoing configuration management,
availability, monitoring, and importantly placement.
Since everything until now has been tested,
placement of the app becomes a business decision.
Whether it's an Azure with a service provider.
Or, an enterprise instance of Azure Stack.
Everyone gets visibility when something goes wrong.
The nice thing is
because we just saw what Natalia did to get the OMS agent running.
It's just built in.
Every time I run this ARM template,
it's going to come under management
and we can have complete visibility into that environment.
So let me show you how to configure placement using arm.
If we go back to Visual Studio online.
If the app has a geographical requirement
and that sometimes data sovereignty laws or latency or something like that.
You can simply place the app on Azure Stack.
Here in our Hospital app that we saw before.
We've configured it to run in different locations.
In this case, everything has been tested and we're ready to put the app in the hospital.
We just choose where the components of the app or service run.
We call it placement.
So here you can see a few locations.
We've got Brazil, Melbourne, Mumbai, New Zealand, Poland, etc.
There's lots of ways to deploy.
In this case, we chose Visual Studio Code.
You could have even used PowerShell.
Here we're using VS code.
It's a really great place to start if you're an IT pro.
There are even extensions that can help you author your own PowerShell scripts
and do everything that we've seen here.
Now you've seen how Azure Stack and Azure can help with the DevOps approach.
It really unifies that deveopment
and operations workflow.
It also provides additional flexibility and deployment options
giving you another way to match requirements for unique workflows or situations.
You can use the same tools and modern methods
to build your apps no matter which cloud you target.
How would people get started today in doing all this stuff?
I'm very excited we just released Azure Stack TP3.
The best way to get started is to team up with your developers
and start prototyping you're apps in Azure.
And then validating in Azure Stack.
You can download it at the link below.
You can also learn more about how to collaborate with your developers at this link.
Really great stuff.
Thanks for joining us today, Natalia.
Try it out and let us know what you want to know more about.
And start using it today.
As always, keep watching Microsoft Mechanics for the latest updates across Microsoft.
Thanks for watching and goodbye for now.
Microsoft Mechanics
www.microsoft.com/mechanics