Find out how we can help your digital transformation. Contact us to learn more.
Evolving DevOps: The Benefits of PaaS and Application Dial Tone
The DevOps movement has enabled organizations to leave behind months-long procurement cycles and instead get the infrastructure they need in a matter of hours, or even minutes. While many organizations have benefited from this automation, even greater gains can be realized when the application development and hosting platform provides capabilities further up the stack.
Tune in to this webinar to learn:
- The symbiotic relationship between DevOps and PaaS
- How to transform your infrastructure into an abstracted application layer that stands ready to initiate services on demand
- The kinds of outcomes experienced by early adopters of the Pivotal Cloud Foundry PaaS
A self-proclaimed propeller head, Cornelia Davis is the Senior Director of Platform Engineering in the Cloud Foundry team at Pivotal, where she helps customers and partners develop and execute on their cloud platform strategies. Fundamentally responsible for making developers successful with the Cloud Foundry PaaS, you can generally find her knee deep in the (OSS) code base, writing apps and deploying them onto the PaaS, teaching at a whiteboard, presenting at conferences and passionately driving new features into the product.
Abby Kearns is the Technical Product Marketing Manager for Pivotal Cloud Foundry. Her goal is to effectively communicate Pivotal Cloud Foundry to the market and drive a broader market awareness of PaaS. A 16-year technology veteran with a career that has spanned product marketing, product management and consulting services at OPSWAT, Verizon, Totality, EDS and Sabre.
Abby Kearns: Thanks, everybody for joining. My name is Abby Kearns. Today's webinar will be about Evolving DevOps and the Benefits of PaaS and Application Dial Tone. Here to speak to us today is Cornelia Davis. She's the director of Platform Engineering at Pivotal and will be providing a walkthrough DevOps, PaaS and the evolution to PaaS around our applications. Cornelia?
Cornelia Davis: Thank you, Abby. Thank you, everyone for joining this morning or this afternoon or this evening depending on your time zone. I'm delighted to be here today speaking with you about DevOps. First, let me give you just a little bit of background on me personally. I'll share a lot of stories throughout the conversation. I find anecdotes make things very, very real.
So the first story I'll start with is the way that I came to the Cloud Foundry Team. I came to Pivotal as you know Pivotal is a spin off from EMC and VMWare and I came to Pivotal from EMC where I worked in the Corporate CTO office. I have about 25-year career as an application developer in the Corporate CTO office. I work on emerging technology.
About two and a half years ago, one of those emerging technology areas that I was working on with Platforms as a Service and Cloud Foundry. At the time, I believe that Cloud Foundry and Platform as a Service in general was all for the developer, all for me. After Pivotal its own entity, I joined the Cloud Foundry team because I was quite bullish and quite excited about the product itself and I started working with customers.
So Platform Engineering is an engineering group. We're in the product organization but we are field-phasing and we work with a lot of customers and partners helping them apply this technology which is quite frankly an emerging technology area for all of our enterprise customers. Helping them apply that and also doing innovative integrations with other third-party applications.
Once I started working with clients out in the field, working with people who are interested in Cloud Foundry and Platform as a Service, it took me about a month and not very, very long at all to realize that Platform as a Service is much for operations as it is for development. That really gives me the backdrop on the conversation for today. We're talking about DevOps, so we're in fact not just talking about Platform as a Service being in advantage for the developer but today, we're really going to focus on the advantage to the developer and operations and what DevOps is all about.
Without further adieu, let's move forward. Let's make sure that I can ... Here we go, advance my slides. The first thing that I want to talk about here is what's happening out in the marketplace? Many of you have probably heard the term 'software is eating the world'. If you haven't already seen it, you should really Google an article that was written by Marc Andreessen back in 2010 for the Wall Street Journal, Software is Eating the World.
Back then, it was a very eye-opening, provocative piece and here it is four years later and it's now quite accepted but still very informative. The notion here is that every industry is being impacted by software. Very large corporations, entrenched corporations, corporations that are in areas like financial services or media or telco, those types of organizations, they're being threatened by software, by new companies, by new startup companies that are coming in and starting to eat some of their market share.
For example, I've been spending a lot of time in the financial services arena working with large banks in the New York City area and they're all incredibly scared about the Squares and the PayPals that are coming in and starting to eat away some of their market share. In Cloud Foundry, we've really been looking at, we've been trying to address that that innovation gap that you see here on the slide.
On the X axis we've got time and over time on the Y axis, the expectations by consumers have ramped up. Traditional IT is having a bit of a difficult time responding to those expectations while the startups are able to address that. In fact, startups are to a large extent responsible those increased expectations because consumers are getting those experiences out in the consumer space with the consumer applications. So they want that from everyone even large corporations that are providing them access to applications.
Traditional IT has been trying to respond to that by first of all, moving toward Infrastructure as a Service. Now, moving to Infrastructure as a Service certainly streamlined operations a great deal. Rapid provisioning the stories that were used to take six weeks to provision something, now being able to provision that in hour or maybe even minutes. That's certainly a huge advantage.
All of you who are in IT know that provisioning virtual machines is only the beginning of the process. There's still a great deal that you need to do. Traditional IT is moving up in their game and saying, 'Okay. Well, we're going to start doing once I get those VMs, I need to do a whole bunch of automation on that. I need to configure those VMs. I need to install things on those VMs. I need to network those VMs. I need to configure my router F5 routers and so on.'
Automation is getting them part of the way there as well but there's still a gap. What we do on Cloud Foundry is we're really focusing on what that gap is and our platform, the Pivotal Cloud Foundry platform is focusing on proving you, the consumer with the enterprise, the consumer being the application developers and the application operations team in the enterprise. Providing them a platform where they can more easily act like a startup if you will.
Then we started looking at that and if you take a look at that, is it really ... What is the difference? Is it that startups are just able to create better applications, that they have more creative staff that can create new and whizzbang mobile applications or web applications, those types of things? I assert that it's not. I assert that there's plenty of really great designers and application developers in the enterprise.
What is it that's leaving that gap in place? Our belief and our assertion is that it's all of the practices around the application development process. So it's around continuous integration and delivery, around DevOps, around agile development. So what we're doing is we are building a platform to address those things. You probably all seen a slide that is very similar to the one that I'm showing you on this screen here today which is this evolution of Cloud Platforms.
Originally, wehave these traditional platforms where an application development and operations team had to deal with the entire stack. They had to acquire physical machines. Maybe they didn't have a virtualization platform but then they had to install operating system then middleware and then finally, they can get to their application code.
Infrastructure as a Service, of course has abstracted a way everything from the physical servers up through the operating system allowing you not to have to deal with that lowest layer but you still have to deal with installing the database software, installing the application server and the web server, installing RabbitMQ, those types of things. Then you can install your application.
Platform as a Service brings out abstracts even a little bit higher. So now, we've got ... We've abstracted a way that consumers of a Platform as a Service, they are really just focusing on their application code and they no longer need to install their database server, install their application server, install their messaging software and those types of things.
Now in the next slide, I'm going to show you in just a moment that there's some subtleties on that and that's really what we're going to be talking about here in DevOps. If we now just take a look at the Infrastructure as a Service and Platform as a Service the way we've defined it here, my first goal here is to crystallize the difference between Infrastructure as a Service and Platform as a Service. It's really not quite as simple as that previous slide that I showed you.
It turned out that all of the work that I've done in the last year, I've worked with a large financial services company who has what I'm about to show you, a large e-commerce retailer that has what I'm about to show you. We've learned a lot about that process. What is it that I want to show you here?
If we push IS to the left a little bit, it turns out that many of these organizations have built a platform if you will that sits between Infrastructure as a Service and Platform as a Service. What they've done is they've attempted to have that same abstraction layer that we have in Pivotal Cloud Foundry above the PaaS layer but they really aren't exposing a different dial tone. I'll get to the dial tone more in just a moment.
What they've done is they've created what we sometimes call an IS+. Instead of just serving from their Infrastructure as a Service offering which is a self-service portal where individuals can go and request virtual machines, instead of just serving up virtual machines and then leaving everything on those virtual machines to the consumer of the virtual machines, they are serving up virtual machines that already have some software installed on them.
So they're serving up a virtual machine that already has the database installed on it. They're serving up virtual machine that already has the web server installed on it or another machine that has RabbitMQ installed on it. These virtual machines already have the middleware components installed and now the application teams can simply build their application code leveraging that.
It sounds great but it turns out that it's ultimately still just an Infrastructure as a Service offering. What I want to spend the rest of the time here talking about is what is the difference between an abstraction that looks like it's very comparable. If you look at IS+ in the middle and the PaaS on the right hand side, it looks from the application code perspective almost the same. We've got a level of abstraction that abstracts away all of those middleware components even in the IS+.
As it happens though, that abstraction isn't very clean and that is what we mean by Application Dial Tone. An Application Dial Tone what we're saying is that we are abstracting a way all of the infrastructure details. The infrastructure details are things like the IP address of the machine, the port of the machine, the specifics around the network ranges, specifics perhaps even around storage volumes and those types of things.
We're really hiding all of those abstractions and providing a different abstraction at the PaaS layer. For Pivotal Cloud Foundry, that abstraction layer is an application. So it's all about the functionality that we provide around an application. I'll go into some of those details in just a moment. There's a number of them listed here which is that we configure the application. We don't configure virtual machines that are then running the application. We configure the application.
We provide a run time context for the application. We do not lay down that run time context on a virtual machine. We lay down that run time context just for that application and for nothing else running on that machine. We provide operational benefits such as logging an application performance monitoring to the application level. We provide health management for the application, security for the application. We do operations on the application.
As supposed to doing all of those things and saying, 'Ah, if I want to look at logs, I need to get to the right machine first.' We abstract away the machines and all of those capabilities are provided at the application level. A pause for just a moment to let that sync in but I promise you that we'll get into the details along with each one of those.
Abby Kearns: Cornelia, this is a great introduction. We maybe also want to talk about how this maps back to the practice aspect to and where enterprises can take advantage of this and the practice around it.
Cornelia Davis: You mean the processes and so on?
Abby Kearns: Yeah and how they can adapt this and take advantage of these types of platforms within their environment and make sure that they're getting the full value of it.
Cornelia Davis: That's right. What Abby is referring to there is ... How do I get there? I'm familiar with doing all of these things at the machine boundaries. How do I make that transition over into Application Dial Tone? There's a number of very interesting things. The first thing that I'll tell you is that application developers fall in love with this very, very quickly because they ... and I can speak very personally to this but I'm an application developer for 25 years. I'm not operations person. I really don't know how to configure an F5 router. I don't know how to configure firewall rules.
So it's brilliant if I don't have to do that. Application developers are very in-tuned with that. Operations teams, they're used to those primitives. It's perhaps maybe a bit more disruptive for the operations team. Nevertheless, once they find out that they might get paged for an outage but by the time they get to looking at the logs for that outage, the platform's already corrected the issue. Then they become very, very engaged in that.
The good news is that you don't need to drop everything that you're doing. One of the things that you'll notice here is that in this picture, we're not showing that we have Infrastructure as a Service below Platform as a Service. That's quite intentional. We don't need Infrastructure as a Service in place before you can Platform as a Service in place. Pivotal Cloud Foundry simply requires virtualized infrastructure. It does not require that you've already got that Infrastructure as a Service offering with the self-service portal and all of that already in place.
So you can get there immediately if you've got virtualized infrastructure which I'm betting all of you have. Then the other part of it is to note that it's still often valuable if you already have that investment in Infrastructure as a Service. There are in fact workloads that are still better suited for Infrastructure as a Service. Going through and analyzing your application development portfolio and the applications that you have in place can help you identify which things you want to migrate to Platform as a Service and which things you want to leave on Infrastructure as a Service for the time being.
The good news is that there's huge benefits to Application Dial Tone and we'll go through that as we go through the slides.
Going back then, looking at this slide, we're going to step through many of the bullets here. The first thing that I want to talk about is configuration. What we see here on the slide is we're talking about application configuration. What we want to be able to do to optimize, remember, I said that startups are finding success not only because they're developing really cool nifty applications but because they've nailed the continuous integration, continuous development process.
One of the things that's pretty well understood about continuous integration and continuous delivery is that you need to have uniformity of your platform across your entire application life cycle. You need to have the same platform in place that you're doing your development and your development level testing on, the same type of platform or the same platform for your staging environment and then the same platform for your production environment.
The reason for that is if you take a look at what slows down your application deployments, it's all of these manual processes that you need to put in place, that you need ... It's those configurations of the routers and it's the approval processes and all of those things, the allocation of URL, et cetera, all of those things that need to be in place before you can go to production.
Let me tell you a very anecdotal story of a Pivotal Labs client of ours. A Pivotal Labs client of ours had engaged us to build a nifty, new application. We built that. They built that together with us in the Pivotal Lab style which is our agile extreme programming consultancy that's part of the Pivotal Company.
During that agile development process, they used Cloud Foundry. They were doing their development. They were doing all of their cycles in Cloud Foundry. They were doing their continuous integration, so all of their test-driven development and all their test ran. They were deploying into a Pivotal Cloud Foundry environment during development.
This particular customer hadn't yet purchased Pivotal Cloud Foundry. So when the application was complete, they said, 'This is great. We're ready to go into production but we're going to run it on our own infrastructure.' It took that client six to eight weeks to get that application running in production when it had been complete and ready to run and it was already running on Cloud Foundry. They had broken that principle that we see here on the slide which is uniformity of platform across the entire application life cycle.
So that's the first thing. We establish that we need uniformity of platform. Our assertion is that the Pivotal Cloud Foundry Platform is the right platform for that because of the Application Dial Tone. Let me get very concrete then and talk that configuration being one of those steps. Obviously, when you are in a development environment, let's say you're building an application for an e-commerce site. When you're doing that in development, you're probably connecting that to a very small developer-oriented database.
In fact, that database might even be stubbed out. You may not in fact have a database that is running at the backend. You might just have some endpoints that look like databases so that during development, you always get consistent responses from that database endpoint. In development, you might be just binding to a sample database or a stub for a database.
When you move over into staging, you want that same application code to be running but now you want to bind to a different database. So you want to perhaps bind to a database that has all of ... It has your entire customer database but you obviously can't allow anybody to have access to all the personally identifiable information that would be in your production systems.
The database that you're binding to in the staging process, that's been cleansed of all that PII. It's a full database so that you can do load testing and you can test against something that's very close to real and in staging do you performance testing and so on but you're not yet binding to the actual production database. Then when you push over into production, you can bind to the full production database.
The key is to not have to recompile your code and create a different artifact as it moves through the application life cycle because as soon as you create a different artifact, you open the opportunity for something to leak in, for there to be something that, 'Hey, we've all heard those developer versus operations challenges around.' The developer builds something. So it's, 'Oh, I'm done.' Washes their hands, they're going off and having the release party. The operations team is struggling with it, can't get it up and running on their machines. They're saying to the developers, 'Hey, this isn't working,' and the developer says, 'Well, it works on my machine.'
Providing a platform that emits Application Dial Tone and allows configuration to be at the application level not applied at the machine boundaries eliminates one of those areas where there can be a discrepancy between the developers and the production environment. So that's one example of Application Dial Tone is we do application configuration at the application boundary, not in the machines, not in all of the other periphery components that are in your infrastructure.
Let's move on to another example. Now, we're moving a little bit closer to production. Application logging. What you see here on the screen is a pictorial. It's a graphic of some of the components under the covers inside of Pivotal Cloud Foundry. Don't worry, I'm not going to go into a deep architectural discussion here but I think it's probably ... I think everybody can probably understand that you need a router and we have a router that's embedded as a part of Pivotal Cloud Foundry.
You need machines where your workloads are running. Those machines are depicted in this slide as DEAs. Know that does not mean Drug Enforcement Agency. It means Droplet Execution Agents. Droplets are prepared applications, applications ready to run. Those are really droplets are the things that are running. Those are your applications running with the run time context and everything.
Then we have something called the Logger Gator which is what I'll talk about in just a moment. Each one of these green boxes that you see on the slide, those are all different virtual machines. In this particular case, we've deployed multiple instances of our application. By the way, those multiple instances of the application are automatically distributed across two different availability zones.
So that the application developer doesn't need to worry about that infrastructure concept of applications availability zones. They just need to worry about their application logic. They deploy their application and the platform takes care of that infrastructure concern of, 'Well, what happens if I lose part of my infrastructure? I still need the application up and running.'
Here, we've got four instances of app. If I lose availability Zone I, my application is still running in availability Zone II. So that again is another benefit of the developer gets to write the application and doesn't need to worry about the infrastructure concern.
Now, we have four instances of this app running on four virtual machines shortly on two different pieces of hardware. One rack is Zone I and the other rack is Zone II.
If I want to do some troubleshooting for this application or even just see that this application is up and running properly, how do I do that? In the past, you might have made some log in to two different virtual machines. You say, 'Ah, okay. I know I've deployed this application to this virtual machine and the same application to this other virtual machine, so I'll SSH into the first virtual machines and look at the logs. Hmm, I'm not finding what I need there. SSH into another virtual machine, look at the logs, Okay. Maybe now I'm finding what I need.'
What we have done is we've included as a part of the platform something that we call Logger Gator. I know it's a funny term but it does the job of log aggregation for you. So that the application developer and more importantly the application operations team can go to one place to look at the logs for all application instances. They don't need to SSH into boxes. They simply go to the logs for my application.
It's not machine logs. It's not Tomcat logs, it's application logs. In fact, it doesn't only aggregate the logs from the application instances, it also aggregates the logs from things like the router. So the router is going to also say, 'Hey, I got to request for this application and I served it,' so that you can track everything that's going on in the platform but it's application-centric.
Now, I know some of you are probably thinking, 'Well, I have a log aggregation solution,' and yes, you might one of those log aggregation solutions but that means that you have to manage that relationship between your logstash or your Splunk or something like that and your Infrastructure as a Service, you have to wire all those things in together. We have that included out of the box in PCF.
Now, another thing that we do at the application boundary is we manage application health. Now, I'll go back and tell you another anecdote. One of the clients that I have worked with this year that has one of those IS+ systems, when something goes wrong with an application because they're really an infrastructure-centric view on their world, they need to go in and they need to do a whole bunch of troubleshooting at the machine level.
In fact, they might have to bring an entire new virtual machine up, configure that virtual machine, wire that virtual machine into their routers and into their networks and so on. That's a pretty heavyweight process. In Pivotal Cloud Foundry, we have built into that a component called the Health Manager. The Health Manager, the simplest way of describing that is to look at the two little icons that you see above the Health Manager box. The Health Manager is in the business constantly monitoring the entire system, monitoring all of the application instances that are running across all the DEAs across all of the different availability zones.
It's continually building up a model of the actual state of the Cloud. You can see that depicted there with the little incomplete graph on the right hand side. They're constantly comparing that to the desired state of the cloud. You as an application, let's take the scenario where I'm an application operations team. So my job is to keep all these applications up and running.
I know that I want four instances of this application running and the platform knows that as well. I've let the platform know, 'Please keep four instances of this up and running.' If something should go wrong with one of those instances, it might have been that one of the instances crashed because of a bug or it could be that I've lost an availability zone and now I only have two of four instances running.
The Health Manager will immediately detect that and the Health Manager will resurrect a new instance of that application. They do not need to resurrect a new virtual machine. They do not need to configure that machine into routers. They do not need to go and configure a new load balancer. All of that's done is a part of that platform.
You noticed that there's a little arrow between what's called the Messaging and the router. The router is very dynamic and the platform when an application instance has crashed and it's relocated to a different place and start it up, the router is immediately updated. So you don't need somebody to go in and even create ... go in and configure the F5 router nor do they need to create or update or leverage a script to do that.
By the way, I've talked to lots of people in the DevOps setting that say, 'Scripts are all fine and good and they work the first time but when you need them later on, when you're in the middle of a production outage, they almost never work because something has changed in the infrastructure.' So they have to troubleshoot those scripts before they can execute them. This is all done.
Health is managed at the application level not at the virtual machine level. I actually lied to you there. We also have a whole layer that manages the health of the virtual machines that are running the platform. We'd be delighted to do another conversation. In fact, you can do a Google search on the four levels of HA in Cloud Foundry and you'll find some blog posts and videos on that. So it will tell about how we manage virtual machines as well.
Then let's talk about another thing that you do at the application boundary. It's fairly typical. I talked to enterprises very frequently who say, 'Okay. Well, here's how I do security. So I have a three-tiered application. I have my web tier and then I have my services tier. I configure firewall rules to only allow access to the services tier from the machines that are running the web tier.
They're essentially putting up perimeter security in the firewall. That perimeter is around virtual machines. Now, if they decide to run something else on that virtual machine or they have to change something about the virtual machine configuration. Let's say, they changed their network settings and they have to change IP addresses, then they have to go in and change those machine boundaries
Instead, what we do in Pivotal Cloud Foundry is we allow you to secure right at the application boundary. Now what we see is we see in this picture, we see DEAs and I'll remind you that DEAs are Droplet Execution Agents. Those are the virtual machines that are in the business of running your applications.
Now, you see a picture here where there's multiple applications running on each DEA. Those applications are running in containers and now I'm stealing my own thunder because we're going to talk more about containers in just a moment. We have a number of containers in there that are running application instances.
Instead of providing security at the machine boundaries, at the boundary of the DEA, for example, we allow for configuration of applications right there at the application boundary. That application boundary is the container boundary. We support outbound firewall rules that restrict network traffic. We do that at that application level.
Now, does that mean that application developers are going to have to learn how to configure firewall rules? The answer is no. We're aiming to keep that abstraction, the application abstraction as simple as possible. Those firewall rules are configured in such a way that depending on the application and how you ... depending on the characteristics of the application, the appropriate firewall rules will be exposed.
For example, if I am deploying my e-commerce application then I know that the firewall rules need to allow me access to my customer database. If instead, I'm deploying an application that is a procurement application or an application where I'm dealing with my suppliers then I know that I shouldn't have access to the customer database but I need to have access to the partner database.
Depending on the characteristics of the application, those firewall rules will automatically be applied and they'll be applied right at the application boundary, not the virtual machine boundary.
Without further adieu, let's talk a little bit more about containers. What we have here on the left hand side is we have a picture that is more typical of the IS+ environment. We have virtual machines that have all the middleware, the guest OS and so on installed on those. Then I have the application installed into the virtual machine. By contrast on Pivotal Cloud Foundry, we have a virtual machine that's provisioned but then the application instances are provisioned into containers.
This has a number of different advantages. First of all, we found very much so that it has better utilization of the virtual machine capacity. One of the things that we sometimes talk about is that it's actually cheaper for you to run your workloads on Pivotal web services which is in the Cloud offering of Cloud Foundry which is running on Amazon than it is for you to run those same workloads tenably on Amazon.
That's because we ink out as much capacity as we can from all of those virtual machine instances. We get much better utilization because we're cramming more on the virtual machines. That's one of the things.
The other thing that it does is it really subtly changes the dial tone. So it's the container that's enabling us for example, to very quickly start up the health management that we talked about very quickly resurrected for an application instance that has crashed or apply firewall rules to the application boundary. That's all done at the container level.
Then there's another thing that I'll point out. You'll notice that the operating system is now a shared resource across this. That's part of the way that we get better utilization of the virtual machines is that it's no longer that the infrastructure is the shared resource and the virtual machines are the components that are allocated.
Now, the virtual machines are the shared resource and we use containers to allocate outside of those. The operating system is a shared resource. We've had a rash of exploits at the operating system level in the last couple of months. We've had shell shock, we've had heart bleed and so on.
When that happens, rather that needing to go into perhaps tens of thousands of the virtual machines and going through the process of upgrading the OS and all of those machines, we now can reduce the number of virtual machines we have because we're now using containers and we have fewer OSs to patch.
Furthermore, I mentioned that we have a whole another layer that does management of the virtual machines. We have a tool chain called Operations Manager that manages the whole Pivotal Cloud Foundry deployment. That has a way of doing automatic rolling upgrades. We will patch those operating system vulnerabilities and you simply go in to operations manager and say, 'Hey, I have a new version of the software and it was zero downtime.' We'll upgrade the operating system out from under all of those applications.
Now of course, in the process, we're cycling the applications but because we have containers, those containers are much more rapid of allocations. So we can take them down and spin them up much more quickly. We can do it in smaller chunks so we can ensure that your application truly has zero downtime by saying, 'You know what? You have 10 instances running.'
We're going to move those 10 instances all onto virtual machines that we're going to leave alone for the moment. We'll upgrade some other virtual machines, move those application instances over here. The platform handling all of that movement, you don't need reconfigure firewall rules and all of that stuff. It's all embedded in the platform.
Those are a host and those are really just a handful of examples. Those are a host of different examples of things that we offer at the Application Dial Tone level. We'll pause here and see whether ... Take a breath and see whether Abby has gathered any questions and I can address those for a moment before I jump into this last point.
Abby Kearns: I don't have any questions yet, Cornelia but I really love the focus of why Application Dial Tone and an app-centric focus is so valuable as part of an inclusion and a model and a platform and how investing in a platform as a service and end platform that abstracts the underlying layer really adds value.
As you go through the operations model, maybe we touched on that value add a little bit further and really talk to why that investment and that app-centric focus is really necessary to the business and the innovation life cycle.
Cornelia Davis: Absolutely. Great. Thank you so much for that comment. Let's talk about this. We're coming down the homestretch here. I've just got this slide and maybe one other to talk about. This is a very interesting thing that we discovered. I mentioned that I've been working with a couple of enterprises that already have an IS+ system in place.
One of those enterprises in particular when I came to know them, they said right away, 'We know it's not a PaaS. We know it's not a Platform as a Service and we know that there's some challenges and we would like you to work with us. I did a very deep Cloud assessment with them. 'We would like you to work with us to understand where some of those gaps are in our platform which is an IS+ platform and what some of those added values are with Platform as a Service.'
Now, a great deal with those were the things that we've already talked about in the presentation until now. So having the health management, having the security applied at the appropriate layers. During the course of several interviews and I interviewed folks from the application development team, from the operations teams and so on, we made an interesting discovery and that is, that they started out with an IS system like this.
Now, their IT Ops team was responsible for the IS+ system. So they provided, they went through ... and they by the way had a very fantastic process in place around governance on deciding what is included in the next version of the platform. They had a tremendous team around operations that were always ready to help out if there was any help that was needed be it in the development life cycle or in production. They were really running a fantastic operation there and IT Ops was responsible for the Infrastructure as a Service.
Now, the application team, they were responsible for their application code. They were increasingly taking on more and more of a DevOps model where they wanted the application team not only do development of the applications but they wanted their application team, they also had an operations element.
Now, that doesn't necessarily mean that developers and operators are one in the same person. It really just means that they're working collaboratively as a part of the same team that were eliminating barriers between the developers and the operations. If we go all the way back to one of the first slides I showed about the application life cycle and the uniformity across the entire application life cycle from dev through staging to productions, it's DevOps to a huge extent about eliminating the barriers between development and operations.
So they're moving to a model where they say, 'You know what? We'll develop at that blue box on the top and we also want to operate it.' It turned out that when they were in production and there was some kind of a production outage and that application team needed to do some troubleshooting, it wasn't enough. They really had a concern that overlapped, that drilled down, went deep inside of the Infrastructure as a Service.
For example, if my application has crashed, they need to go in and look at the Catalina logs, the Tomcat logs, the application server logs or if they're having a performance problem, they might need to look at the database logs. They solved this problem in one of two ways typically. So if they were having a production outage and they needed to take a look at those logs, in theory, the application team didn't have access to the virtual machines.
They did not have access to go in and look at the Catalina logs or the database logs because that's in the realm of the IT operations team. So they would go through a request process. They would say, 'Hey, we're having trouble. We need to look at these logs,' and I already said that the IT Ops team in this case was very responsive but there was a delay. Somebody needed to get paged. They needed to generate those logs and they needed to fire up those logs, put them in a shared location, e-mail them, whatever they needed to do.
So there was some delay incurred in that. Then of course, when they found that there was a configuration change that needed to be made as a result of analyzing those logs, then they would have to file a request with the IT Ops team and they would have to make those configuration changes. So that was one way that they solved it and it was working but it was causing ... It was a pretty significant burden. It took a lot of time from both the Ops team and the IT Ops team.
Unfortunately, there was second option which was even worse and that was in some cases, the application team, there were people who were friends with the folks on the IT Ops team and they sweet talked their way into getting SSH access into those boxes, those virtual machines. So when the production outing happened, we talked about a number of cases where both the Ops team gets paged and the IT Ops team gets paged. They're both in their looking at these things on these virtual machines and they're trying to get things up and running as quickly as possible.
They described scenarios where both teams not in collaboration but independently were in changing the same files. They were in fact stepping on each other's toes while they were trying to troubleshoot an issue. The real issue there is that the dial tone was wrong. The dial tone was at the machine boundary.
If instead, we really, truly are able to create the right level of abstraction at the application tier and we provide all of the capabilities that we've just talked about configuration at the application boundary, all of the logs and metrics, application performance monitoring, having dashboards that are about the application and then also coupling that with looking at logs that are just about the application, not logs that are on a virtual machine somewhere.
Having application instances restarted all of those things. Having enough capability at the application level is proving to allow you to take that operational burden and really create a separation of duties. That, when we were doing the debrief in fact with the executives at this particular corporation, the head of IT operations, she said, 'That, right there, if we could eliminate that overlap, we'd probably eliminate 80% to 90% of our firefighting.' So it's a very significant thing. Application Dial Tone is a huge benefit to DevOps.
Just in summary and then we'll open it up for some questions is just to go back and talk about some of these things, remember, continuous integration and delivery, that's one the ways that startups are coming in and eating away at the market share for large corporations is that they're not only bringing cool software to market and bringing it to market fast, they're bringing it to market more frequently so that when something goes wrong or something goes right or there's some event that they want to take advantage of, they can take advantage of that very quickly and they can release their software instead of every 18 months or even 12 months or six months, maybe they can release their software every week or every couple of times a week.
Amazon, for example is known for on average releasing software every 11 seconds. We know what happen to borders, don't we? It's proof point. Other things are that you can optimize your IT practices around the Application Dial Tone. We didn't really talk a whole lot about standardized run times but when you lay down the run time in one of those containers that run your workload, IT can standardize those run times.
Now, when they do have to troubleshoot a problem, they're not troubleshooting snowflakes. There's some standardization on those. Having application boundaries for security and health management and so on and then finally, that huge punchline at the end about separation of concerns in operations.
At this point, I'd love to open it up for questions. Abby, I don't know whether we have something to man over the chat.
Abby Kearns: Yeah, I actually have a few. The first question is, 'Are there options to extend dynamically the memory that is available for an application container?'
Cornelia Davis: Very, very good question and I believe that question is probably asked by somebody maybe who has a little bit of experience with Cloud Foundry. The answer is in short, yes and what you can do there is there's a number of options. You can go in and change the metadata. When you deploy an application to Pivotal Cloud Foundry, you give it your best estimate on the amount of memory that you need.
If during your application performance monitoring which of course is at the application tier, at the Application Dial Tone, you discover that you're running short on application memory, you can go in and say, 'Hey, I need instead of half a gig, I need a gig of memory associated with this as well.' I'm using more of my Java. JVM is using more of a footprint than it used to. Hopefully, you've troubleshooted some of this in staging but of course, it can happen in production.
You can up that and then you restage the application. There's ways of doing that restaging of the application in incremental style. You can do blue-green deployment where you can say, 'Ah, let me deploy a new version of this application,' and start directing some of the load over to that new instance that has the larger memory allocation. Nothing else is changed. The WAR file is the same or the ruby code is the code. The only thing that's changed is the memory allocation is changed.
Let me start doing some monitoring. That's a separate application instance so I can monitor that application instance and verify that, 'Ah, okay. Things are running better now. This is the amount of memory I haven't over provisioned,' because we don't want to over provision either. 'I haven't over provisioned.' Then you can switch over all of your traffic from the former to the latter. That's all done with zero downtime deploys. Blue-green deployment patterns and there's a lot of information out on the web around those even on the Pivotal Cloud Foundry documentation is one of your best tools there.
Abby Kearns: Great. The next question is really focusing on the importance of assessing what to move to a Platform as a Service platform and what to leave on an IS. Can we drill into some criteria that should be considered as part of that evaluation? What kind of apps should be prioritized for that migration?
Cornelia Davis: Absolutely. I'll jump back and tell you a little bit more anecdotally. When I was in the Corporate CTO office, I worked on service-oriented architectures. I worked with product ribs across EMC. Helping them understand what was going on with the latest, greatest and service-oriented architectures and quite frankly, I did a lot with the web architectures and restful services.
A lot of those themes were around loose coupling and around late bindings and those types of things. There are a lot of applications out there that already don't use say local file systems for storage. They are already using a blobstore because they've already discovered the benefits of having externalized storage. Those applications are ideal candidates for migration onto the Pivotal Cloud Foundry platform.
In that case, so let's take the example of a spring app. Spring app tend to ... The whole spring framework is very encouraging around building good application architectures. Chances are, if you've got spring apps, you've already got a set of applications that can migrate fairly easily over into the Pivotal Cloud Foundry which require to do that migration then typically is some configuration changes.
There, we've already got dependency injection. Everybody knows about that. Spring is really what brought that to the forefront. The dependency injection is what you can do as you move through the application life cycle. So now, you're doing that database binding is you're using spring configuration to do that binding very, very late. That's a set of applications that are really well, well-suited for migration.
Now, let's also talk about applications that maybe aren't suited for migration. There are some candidates on that. Just like you probably are still running mainframes and mainframe load. Some mainframe loads were not suitable for replatforming onto the second platform, the second platform being something that IBC refers to as the client's server architecture.
So there are going to be some applications that are much more suitable to deployments on second platform which are really machine boundaries. Those are going to be those deployments that depend on let's say various components starting up in a particular order. You've got to have the document and Docbroker has to be fully started before you start the web tier. If you don't then the web tier has no idea what to connect to. It needs to have that connectivity when it spins up.
The way that I connect that, the way that that web tier is configured is via IP addresses and ports. If those IP addresses and ports change then I need to start from scratch and I need to reboot the first server from the get-go.
Things that have these infrastructure dependent out applications that really depend on infrastructure primitive, those are the ones that are much more difficult to move over to what we're now calling Third Platform. Third Platform really being Cloud native and those are platforms that have been made famous by the Googles and the Amazons and the eBays because they're running tens of thousands or hundreds of thousands, maybe even millions of servers that are constantly their commodity service that are constantly going down.
Yet, their applications continue to run. So it's applications that are designed for failure. The good news is that if you move to Platform as a Service, the platform handles a lot of those failure characteristics and you as an application developer are not burnt and saddled with those concerns.
Abby Kearns: That's great, Cornelia. One last question. There was an ask if we could speak to an actual customer success story. I wondered if there was one that we might be able to speak to around the migration.
Cornelia Davis: Absolutely. Let me talk about one that I was involved in over the course of this year and that Core Logic. Now, some of you may not know who Core Logic is but Core Logic, you might ... If you're thinking about just the name, you probably wouldn't guess what space they're in but they're actually in the mortgage processing space.
So this is a company that had a pretty good market share around about more than half of the mortgages in the United States flow through their systems in one way, shape or form. They own lot of data. So they for example are there for credit checks, some flood reporting data and condo association information because if a mortgage company is going to give a mortgage on a condominium, they want to make sure that the condominium associations in good stead, that they haven't defaulted on their insurance payments for example. They need to go through that due diligence.
Core Logic is a company that recognized they had very innovative leader come in. They had a new leader come in who said, 'You know what? If we don't change, we are starting to see some pressure from these small startups that are coming in that are able to provide better experiences.' What they've done is they first of all, they engaged ... It wasn't just about the platform for them.
They recognized that they needed to come up with a new way of doing agile development. They engaged with Pivotal Labs and they built out originally one and then followed it with two additional applications where they built that application with a very agile development style. They were using Cloud Foundry to do the first part of that application life cycle. While they were doing that, they were in fact using Pivotal web services in those early days while at the same time in parallel, they stood PCF up in their own data center.
It's a data center that was handled by a third party but they're standing it up on their own data center. When the application was ready, they went live on that. They were able to then very rapidly make changes to those applications. What they've done was in circling back to the migration question is a lot of their systems were left in place. So the flood reporting system or the credit check system, those were all things that were used as backend services and were left on Infrastructure as a Service for the time being.
It was the new condo association application, the new web application that provided the new consumer experience that they wrote new because they didn't have a modern application in this space. That was the new application that they replatformed onto Pivotal Cloud Foundry. They exposed those legacy things as services and those can be exposed very easily as services in the Pivotal Cloud Foundry platform.
Then over time, they will migrate some of those things into the Pivotal Cloud FoundryF platform as well because Pivotal Cloud Foundry is a great platform not just for end user applications but for web services as well. It's a great microservices platform. Microservices is another topic that we've love ... that we've done webinars on and that we'll do more webinars on in the future but it's a great platform for microservices as well. Great question.
Abby Kearns: Great, Cornelia. Thank you. Now that we're at the top of the hour, I would like to thank everybody for attending the webinar and a replay will be available in a few days and will be distributed to all of those that attended. As always, you have our contact information. If you have any follow on questions, we'd be happy to answer.
Cornelia Davis: Great. Thank you, Abby and thank you, everyone for your attention and your time.