>> Hey, folks. Hey, thanks for showing you,
Especially late on the first day. I know you're probably tired
From all the excitement. We'll get through this.
Today's topic is about using pivotal cloud foundry across
Your azure stack for hybrid applications and what it looks
Like and an interface and user experience standpoint.
Pivotal cloud foundry. High-level over view for those
Of you who don't use it. And a refresh arer for those of
You that do. We'll move into a bit about
Hybrid use cases. August applications potentially
In the public cloud as well as your private.
We'll more to hybrid solutions.
A little about cloud foundry. It's a platform service.
It's a little different than infrom you structures service.
It's closer to delivering business value than necessarily
Technical value. It's an enabled really well with
Azure. Pivotal cloud foundry can be
Found on azure market place. If you're curious and want to
Try it, log in, give it a try, not a big footprint.
One of the great points about cloud foundry as a whole is it's
Primarily open source. The majority of cloud foundry is
Open source and you can find it through the cloud foundry
Foundation which microsoft is a member of.
Ultimately the one point about cloud foundry is it's a really
Easy way to get raw code into the cloud.
We can take your raw code and make something of it in in 30
Seconds or less. So why would you run cloud
Foundry on azure if azure has its own preexisting services.
Other than the fact you can push raw code to the cloud and make
Something of it, we partnered with microsoft to write service brokers.
They're great ways to consume azure first party services.
Instead of going out and deploying azure red iss and
Managing it and credentials and cosmos db, through our service
Broker you can tell cloud foundry what you need and it
Will go provision one for you, manage the life psych sql the
Provisions for it. All do you is consume it.
Cloud foundry has two ways of running
Application, first through run time, pushing raw
Code to cloud, then the container run cloud.
The service broker runs for both. Great experience.
Microsoft has done tons of engineering work to make it an
Awesome experience. The great part is it's extendible.
If you juan consume first party services not available in the
Service broker, you can use user successful.
It has first party support and native support for spring cloud.
If you want to run java on azure as well as spring on azure, this
Is the right place to do it. We also have first class support
For the .Net framework, going back several revisions and do
Support awesome frameworks such as wwf or wbcf and .Net core.
We have a library to use spring with .Net.
We call it steel tow. We donated steel toe to the .Net
Foundation late last year. We've found great traction and
Responses from customers through it.
If you want to use spring and .Net at the same time, steel toe
Is the way to go. It's a polyglott.
Whether you're writing in node, go, .Net, java, four tran, we
Can execute on that and help you be successful in ways you want
To be success ful.
If you don't know what you want your aprication to look like but
You know you want to modernize, foundry is the right place to do it.
One of the best things about cloud foundry and this aligns
Really well with azure stack, you write your code once and you
Can push it everywhere. From deployment a to b, no
Difference. It's awesome. So the focus with pivotal cloud
Foundry on azure stack is all about consistency and sameness.
So it's all the same libraries. So it's the same cli, same sdks
For both spring and .Net and it's all of the same templates.
So if you are defining your application manifests for cloud
Foundry on azure, defining it for cloud foundry on azure stack
Is identical, no difference. When you go to log into the
Pivotal cloud foundry admin ui as well as application ui on
Azure stack, it's identical. All the portals are the same,
All ap ikes are the same.
Everything. What's awesome is it's the same
Experience consistently. A great part about the work we
Do s with microsoft is we're very focused on look and feel.
If you go to use cloud foundry on azure public, it should feel
Identical to pcf on azure. You should not know you're
Deploying your application versus public.
We with want to make sure your vision is identical.
Come talk to us if it's not. Let's talk about hybrid use
Cases k and what they are. Let's say you are deploying your
Financial application to a country with high regulations
About where data has to reside and how it can be managed within
Your country. Let say germany or something.
The great part about azure stack is it allows you come and drop
Your applications on azure stack, getting the azure
Experience you but you get to meet the regulatory compliance
And sovereignty rules especially right off the bat.
Let's say you have a ton of data on site and you want to make
Sure you're serving it in a fast and reliable way.
Azure stack is the right way to do that.
You can come in and take the same azure models you have in
The public cloud and do it in the private cloud.
The last major use case for hybrid applications is in both
Edge as well as disconnected solutions. Less say you want to take your
Awesome azure experience and you want to go through and deploy it where azure doesn't currently
Have a market. There's no region for azure in antarctica.
Let say you have a load there you needing to to-do.
You can bring azure stack, drop it from there, and you are able
To be successful with your applications in antarctica
So when we look at the kind of grand scheme of hybrid
Application deployment models, the best you'll ever be able to
Do is close enough. When we look at let's say region
A on the left in the public cloud you have your standard
Application pool that talks a backend database.
It's awesome because it works. Take this and now you want to
Scale from region a to region b. When you go to stale, some of
The problems you'll run into are consistency.
So operators will always try to take a running application and
Make it identical in a new region but the challenge is
Configurations are different, different service offerings.
Maybe the library of a product you're using doesn't support the
Region because it's new and online. There are all these challenges
That come with it. Another is software versioning.
Let's say you have a new version of your application you want to
Publish, now that you've published your primary region,
Let's publish to the secondary.
Really, there's not a lot of easy ways. One of the great parts, with
Cloud foundry, you can really make that a great experience.
So because the focus that pivot and microsoft have together with
Cloud foundry is same expense consistency, we've made sure the
Experience that you have for hybrid applications is the same.
So if you're deploying to the azure public cloud with
Springing cloud foundry, we want to make sure your experience in
Your azure private cloud is identical. There's nothing's different.
Everything is the same. It goes back to the oridge until
Mantra of write your code once and push it anywhere.
Some of the great parts is azure stack has compatibility with
Express route. When it comes time for a fully
Managed solution, you can look at doing using azure pub rick
Cloud with cloud foundry running on top of it and cloud foundry
With azure stack and using express route to tie them all
Together. The great part is you get one
Congruent network all the way across, policies simplified.
You don't have to make weird
Exceptions for applications. We handle all the behind the
Scenes manlike for you. If you can take that and
Interest v it in your private cloud, why wouldn't you want to
Do that? let say you're starting with
Your onpremise cloud because you have onpeople workloads.
Drop in cloud foundry and gives you a great developer experience
Off the bat. Taking it to the azure public
Cloud is simple. All the same operator
Experiences, all the same developer experiences.
Tie it together with express route and it makes management
Super simple when you look at kind of this as
A whole, your takeaway is first it's easy for both the developer
And operator. Easy for a developer because
It's the same cloud foundry experience and it's the same
Management experience through bosh. It's fast.
Right? pushing code is the same?
If you're pushing in azure cloud with cloud foundry and deploying
Like this, you'll yet the same exact experience on premise.
From an operator standpoint, if you're pushing new services
Through bosh to your developers. Pivotal and microsoft both
Recommend it as your developer experience for azure stack.
The reason is it's maintainable. Very inmain expel really consistent.
If you notice nuances between pivotal
Cloud foundry. Our focus has been making sure
Everything is the same, identical, feel goods.
That you're happy, easy developer experience continues
On premise. That's all i got.