 All right, we're really close. I think we'll get started here. I can start. Yeah. All right. Good afternoon, everyone. Thanks so much for coming to our session. My name is Parak Doshi. I'm part of the platform architecture team at Pivotal. I have Patrick Huber, he's a domain architect, and part of the PCF team in Qmanna. And what we're going to talk today about is how do you go from one application team and scale Cloud Foundry to an enterprise? So some of the things we will be discussing is what are some of the consideration you need to take for scaling Cloud Foundry? What are the different phases in your platform maturity as you scale your foundation or your platform? And how do you prioritize some of the things you need to do in there? And Patrick will talk so much more about from the human perspective and how they have approached Cloud Foundry and how they are going through their own journey of measuring that platform based on their enterprise needs. So I will start it off to hand it off to Patrick. He'll give us some more introduction on the context and background of how Qmanna started the Cloud Foundry journey. Thanks, Parak. So Qmanna started their Cloud Foundry journey with Pivotal Labs engagement. And through that engagement, we sent some developers out to New York to kind of learn how Pivotal develops software. And one of the outcomes from that is they came back wanting to use Cloud Foundry at Qmanna. We didn't really have a space for them to do it. So they kind of got shotgun to random buildings and worked in agile formation for a while until we built something called the Digital Experience Center at Qmanna. And it's modeled after Pivotal Labs. I think they even used the same architect. So you too can do this if you have enough influence. And that's where we're kind of growing the seed of Cloud Foundry at Qmanna. So this was the first team to get started. So a little bit of history on the deck. It's an acceleration center, like I said, just like Pivotal Labs. They focus on rapid application to a bit livery, partnering directly with business units, your traditional, I wouldn't say traditional, but your more modern agile processes. And they use Cloud Foundry pretty much exclusively. They do augment it with additional tools to help deliver their tools. But maybe they're developing an iOS application or something like that. That would be external to the foundation. But the core backing services and non-critical data services are in Cloud Foundry. So a couple of apps, we pulled this. There's actually a site called Qmanna.io that's hosted on Cloud Foundry that you should be able to have access to. And here's some of the apps that they have hosted on that. We just grabbed these directly from that site. There's additional ones coming along. We have a Go360 product that's looking at doing some backing services on Cloud Foundry as well. But for the most part, this is our product suite to date. And we're looking to expand that into pharmacy, clinical, digital. And really, how did we get from this one team to try to sell this to our enterprise? So that was the big challenge for us was, hey, look, we've got this small little group. They're using this particular technology. Are they a unique special flower, or is this something that we can spread across to have all application teams use it? And the way we got started was we focused right on quality right away. So going to, hey, you had a major incident, or oh, you botched this deployment when you were trying to push an application, or how long does it take you to get a VM? Like just asking sort of abstract questions, like how much time to developers spend writing code, and frame that up into a presentation deck. And we took that and delivered it to our senior leadership. We also looked at TFS and did CI and CD, so we're a Microsoft shop. And TFS was sort of a natural extension of what we were doing. And the delivery pipelines kind of set a different story. So we had delivery pipelines, and then we needed a place to run our stuff. And that was sort of the cloud foundry was a good fit for that. We also, like I said, the history of success was looking to cloud foundry as the platform we'd run applications. The pitch deck was gathering the support, and really the catalyst was the dojo session. So if you work with Pivotal, you'll know this, that you kind of get started, maybe you'll do Pivotal Labs engagement, and then you look at scaling your platform, that's typically a dojo session, where you sit down and you immerse, set your goals, lay out your goals for like the next six months or whatever, and then you start building pretty much right there. Which is kind of a different change for most people, because we sat down from an operations perspective, and Pivotal wanted to start coding that day, and it's just like, wait, what? We're not gonna sit here and talk endlessly for a while, we're actually gonna do something, which is kind of neat. All right, so while enterprises start off just like deck did, and now they want to scale their foundations or their platform to be enterprise good, what are some of the considerations they have to take? So they need to start thinking about some of these things like the DR topology, how are they going to have the platform, gonna be active, active, active, passive, how are they going to migrate the data, then you start thinking about that. Capacity planning, as more and more application teams start onboarding, there has to be a mechanism of doing some proactive capacity planning so that you can plan the resources you need to support those teams. Chargeback model, that's another thing where enterprises are used to traditional models of VMs and how they get charged back on that, so you need to come up with a new chargeback model which works in this environment. Centralized log management and application monitoring, so most enterprises have their own log management systems and they also have their own APM tools, so how do you integrate Cloud Foundry with that? And finally, pipeline for automation because now you're gonna scale it on enterprise grade, you cannot sustain by doing things manually, so you need to start thinking about the automation pipeline, not only for a platform, but also for the application development teams. And the lastly, the rules, so some of the traditional IT rules of system admins, middleware admins, those are changing because now you have to start thinking in terms of platform operators and how does that work and how does that organization structure work. Another way of looking at all these things is in terms of the maturity of your platform. How does your platform mature and what are the different phases in which it can mature? So most enterprises will start here, it will be the Cloud Friendly platform stage where they're doing most of the things manually, they have no DR strategy yet, there are still a couple of versions behind in the platform and then they start thinking about, okay, now I'm gonna start taking more speed, I'm gonna have more applications getting onboarded, what are some of my charge back model, how will my app teams get onboarded? You start thinking about DR a bit because now you're trying to bring some mission critical apps on the platform. Then from there, you start thinking more about resiliency of your application, what is my platform and what is my DR and then you start implementing those things. You also have your automated pipelines in place. And finally, you get to the cloud native stage where you have implemented all those things and now you're also trying to implement most of the security controls which are available for the platform to make your platform really resilient and really scalable. Now you could go from left to right and try to do each and every step here and or you could take a step back and say there's a lot of things here. How do I pick up some of the things which I need? How do I prioritize it so that it can give the value with the business it's looking for while I'm still making my platform very resilient? So one of the ways of doing that is by using these value drivers, the PhiSS which we call it where you can measure the ROI returns of a platform for an enterprise based on these drivers. So speed and agility, this is something we have heard throughout yesterday and today. The time to market, how fast can your applications go to production and be available to your customers? Stability, in terms of a disaster, how soon your applications can come back up and how resilient is your platform? You can think in terms of scalability, it's like I'm more and more users getting onboarded, how are they going to use the platform and can my app scale fast enough? Savings, this is more in terms of your operational efficiency, your application development productivity and what kind of savings you're getting out of it. And finally security is how are you using your security controls which are provided by the platform to drive more ROI, to drive more stability and to drive more scalability. Now, you could go and do everything which is here to get the most of your ROI, but every enterprise might have a different need. Some might look for speed, some might look for stability, some might look for scalability of the platform. So based on that, what you can do is you can pick and choose the activities you want to do based on how you want to utilize or get the most ROI out of your platform. So if you look from a speed and stability point of view, you can start thinking about how to onboard my application development fast enough, what is the chargeback model for that and for stability, you can start thinking about your DR pipelines and you start thinking about automation and how fast can that work. If you think from security and scalability perspective, you start picking up things like metrics, log management, application monitoring and you can start looking at some of your security metrics which you might want to use there. So that way you can pick and choose what works for you for your enterprise and start doing all the things which are needed to make a platform enterprise ready and Patrick will talk more about some of the steps they have taken on this journey. Yeah, so you can do your own color by numbers here. This is ours. So the stuff that's in red are things that we've implemented. Things in yellow are things that we're planning. Stuff in blue on the right, we think we'll be able to take care of with some of the automations in place. Security is important. We've kind of isolated our environment to this point. So we're not as focused on beefing up security right now because we need to become more efficient before we can start to implement more security constraints. But as you can see, you just basically pick what you want here. So we were really focused on stability. DR was very important. That was one of the first questions. Once we had, we started with two foundations, one non-prod, one prod, and we needed a DR scenario for production. So that was one of the very first things that we did right out of the dojo was start spinning up those networks in our different data centers. And then we also got a lot of questions around charge back models. We'll get into some of that later, but they wanted to know how our customers are going to consume this and how we're going to pay for it. That's a new model for our IT business. They're not really used to the concept of charge back. Or usually it's you buy something out front. We have this really weird deal where you can buy a VM forever and you get it for free. And it's used against us every single conversation that we have around VMs. But like what Prague was saying, you pick the items that are best for you and you build out your own roadmap based on those types of features that you're looking for and what's important to you. So we are a healthcare provider that's very scared of cloud. We're starting to get more and more into that but the HIPAA compliance and our security team are a little slow to adopt. We're picking up momentum there. But the way that we're structured right now if you look at across our data centers we have two data centers. We have a QA foundation and a production foundation and we are set up in an active passive scenario right now with CF Ops doing backup replication from our data services. So there's a lot of questions about data services. We have to do a backup restore. It's not gonna be an active active scenario. We wanna change this and we're looking at options to moving and making it more like a replicate type of scenario where we may have listeners in a secondary data center. But your basic topology for across the data centers is listed here. Load balancer firewall in front of the foundations. And then from a inside the data center perspective we have the slash 23 network for our entire foundation. Turns out we're probably gonna have to change this because a lot of the tiles that are being released now require an additional network. And that's triggering us to start looking at software to find networking because asking for a new network right now is a pain in the butt. And we wanna make that a lot easier. Which means giving it to the people who run the infrastructure as a click type of deployment instead of filling out a ticket and requesting that. So this is pretty standard reference architecture for Cloud Foundry. We have cluster and then in that cluster we have resource pools. In each resource pool we map them to availability zones in Cloud Foundry through ops manager. And then we put our ops manager Bosch and some ERT tiles in one of those, the Singleton instance. And then we have additional resource pools mapped to AZs for additional ERT tiles. And then we have service tiles available as well in each of the availability zones. And then our data source is just attached storage to the hosts. One other thing in there too, we have .local and .com. So .local is internal addressable intranet type services.com is available external. So developers can pick how they want their apps to be exposed. We do that through the domains, I think it's called. From a capacity planning perspective we need to know when to add more hosts. So what we've done to date is set up the JMX tile in Cloud Foundry and then we took a plugin in Dynatrace because we're a very large Dynatrace customer and hooked that up to the JMX tile. And that allows you to expose some platform metrics. I think Dynatrace is beefing up their platform monitoring capability. But right now you just get things like console health and really these measures on the right I ripped this from the Google SRE book and those are like the four big things that we try to measure. Latency errors, traffic and saturation. Saturation is probably the one you're most concerned about like how full is your stuff. So if you're running out of disk space for example you'll wanna add more disk or if your hosts are over committed you wanna add more hosts. And because we're using resource pools in vSphere we can just add additional hosts to the cluster and the resources get divvied up among the resource pools. All right, so for charge back we're also kinda starting the left here. We are measuring four things. So the app instance count, the service instance count, the RAM and the disk. So that's basically based off of our licensing model we get charged for app instances and service instance count from our vendor and we have to provide disk and RAM. CPU's kinda rolled up into everything else. We don't really charge for CPU because we're accommodating forward in the pricing of the RAM and the disk. But roughly it would be equivalent to your app instance count. And then how do we measure? We sample continually. So we'll measure maybe every couple hours or every day. The idea is to try to capture the maximum because of the way that our contracts are set up and most contracts are set up. You get billed based on your max utilization so we wanna capture that. You might scale up and down but your vendor will charge you for your scale up peak. So we wanted to be able to capture that when it happened and not just true up at the end and miss the scale up and be out of compliance. Another thing to consider too is you don't wanna be at 100% utilization ever because you'll basically hit a cap. So you wanna watch for 70% utilization, at least that's what we picked in our case and then that's a trigger to go buy more hardware or scale up your infrastructure a little bit more because you're running at the point where you are gonna start hitting limits, hard limits and experiencing problems across your foundation. So some features of this that are great. It allows app owners to pay only for what they use. We've been tossing around some stuff around t-shirt sizes and trying to use org quotas to limit stuff. We got a lot of complaints from our users that, hey, what if I'm just using one app instance? I don't wanna have to pay for five or 10 or whatever that your pack is gonna provide. Same thing with service instances. Like I said, it fits most contract models unless you have an enterprise agreement of some kind where you can eat as much cloud foundry as you want. I'm jealous, that'd be awesome. We're a really low utilization right now so we don't have the numbers of apps on our platform in order to make that buying decision. So we really need to pay for only what we use and give people small bites to pull off so they're consumption based. And then it allows for future expansion. You can increase your sample rates, you can increase your billing cycles. A lot of IT is based on yearly budgeting so you can charge every year. We wanna shrink it down as much as possible and continually pull money instead of pulling every year, every month. Just getting to monthly is gonna be a huge step for us for billing from an IT perspective. So with that you can figure out exactly when you wanna true up. All right, so a way we're trying to change things from an operation perspective, we have right now, Prog mentioned that I'm on a team, it's there's two of us, which is not great. So there's an infrastructure engineer and I came from the app side, solutions engineering is what we call it and I serve as platform product owner. So I spent a lot of time talking to consumers and I'm getting more and more into actually operating the foundation. The way we wanted to structure this was to have the org manager be the single person that we talked to about what that customer needs. So we've got our product teams, these would be like clinical, digital, whatever our consumers are. We have a representative that we communicate with about their needs. We also try to drive as much support through that person so that we don't get hammered by 50 product teams at one time. Trying to get them to self-service. There's also set up like a Slack-like channel within Humano, it's called Buzz. It's a product we brought in before Slack was cool and we're using that to try to make the product owners talk to each other about problems. You know, how do I push this app or add a problem? What build pack do I use? Like do I need to be answering that every time? Probably not. Get the consumers to talk to each other and then they'll pretty much self-service and you build a community among your developers that way. Some things that these product teams have to do, they still have to request vanity URLs. The Humano.io URL is a vanity URL. And if they need any firewall rules open to external services. Sometimes we'll do that for them if it's platform-based but for the most part we say you guys are responsible for your applications, open up your own firewall rules. We also utilize infrastructure relationships. You scratch my back, I'll scratch yours because we hate tickets. And if you can get away without using tickets, more power to you. And then also trying to get more direct access to vSphere. So the one other guy on our team, Tony Staples, he has full access to the vSphere environment and I keep begging for access. I think I finally am getting close but we'll see. So just trying to understand how the platforms utilizing the infrastructure and being able to manage it in the event. You have to do some sort of discovery or something like that. So as far as future state things, we are at the point where we're ready to start automating more and more. I've done way too many platform installs to be happy at this point. I think at one point I did like 14 or 15 installs trying to get the right version ready. Looking more at zero trust, software defined network policies, just managing the networks in general too with software defined networking would make our lives a lot easier because you get the storage and network virtualization the next step, sorry, get the storage and compute virtualization. The next step is to have the networks virtualized as well. GSLB, we're doing local load balancing and some DNS trickery right now that I would like to get away from. But we're looking at bringing that in, an F5 or a net scaler, typically for on-prem, those are your options, there's probably other ones as well. Still debating whether we need to look at reducing the number of foundations for this but the thing I want is sort of a you don't have to worry about DR as a developer and I think this might be pie in the sky after a lot of my conversations but an active, active deployment for apps and the data. The apps part's a little bit easier especially if they're stateless and you have your developers creating 12 factor applications. You don't really have to worry so much about the data on the foundation but this is probably one of the questions I hear the most about is what are you doing with data and I'm asking it just as much as everybody else. Consulting, business metrics, using the APIs and the foundation, surfacing that as well as metrics through, that is the alarm, metrics through Dynatrace which is what we're using for application monitoring and then Splunk integration, the tiles that are provided by Pivotal, there's a log search tile and you just set up a syslog endpoint in Splunk and you pump it to that. Our Splunk team is kind of like a vertical that is hard to get a hold of and they wanted budget up front so we had a little bit of a challenge getting together with them. Hopefully we're gonna make some progress with that. Right now we're just using the log search tile and we have to dig in there manually. We really wanna get those into the place where all the other business metrics are. All right, thanks Patrick. So when you look at all the work it needs to be done so how are the ops team and apps teams really enable so that they can take their cloud foundry and take it to the next level? So what we do at Pivotal, we think of it as two journeys. So one is the operations journey and one is the application journey, one's for ops guys and one is for the app developers. So what we do is, and which we did with Humana also, is we did like two-fold, one we stand up the environment and help them learn the best practices for the day-to-day management of the environment, of the platform and at the same time they can either do new application development with Pivotal Labs where they get to learn all the best way of developing software to test your own development, agile, pair programming and TDD. So while the development team is learning the ropes and doing that, the operators are standing up the platform and making it ready for them. Once they moved from that point on and as more and more teams start using the platform there are two other things which happen is one from the ops side we call it the day-to dojo where you get to do all your integration into your log management system, your application performance system, you start hooking up your pipelines, let's say the concourse pipelines which are there and you also start working on the DR strategy aspect of it. So that's something we work with the operators on that and the application teams then have two options. One they can start looking at re-platforming some of the applications. So there are a lot of legacy applications which can meet the 12-factor requirements which are there and which can leverage the platform and what it benefits which are there. So they go through an immersion education concept of it where they learn how to re-platform the applications and move them to Cloud Foundry. And obviously what is underlying everything and we heard is that they still have to establish a culture and train new leaders so that they can take it forward. So people like Patrick can then take and have the vision which is there for Humana and take it further for the platform and also for the development teams. And finally they reach a maturity point where the ops guys are also very well versed in adding more and more foundations with the need to meet the business needs and the application development teams are re-platforming and moving more and more of the workloads from on-prem which they have into the cloud or the Cloud Foundry instance is there running for that. So that way we work hand in hand with ops and app dev teams to make it easier for them to scale the platform at the same time gain the technology skills and also the knowledge to manage and maintain that platform. With that I'll come to the conclusion. So it's a journey, the whole concept of taking your foundation and taking your Cloud Foundry to the next level to make it enterprise-grade is a journey. You saw there are a lot of different tools, a lot of different ways you can go and start working towards adding more resiliency and making what enterprise-grade to the platform. End of the day to realize the Cloud Foundry's promise which is like developer productivity and operator efficiency. Those are the two main things which will really enable your business to deliver better, faster, in the most efficient way. And final guys have fun. This is a great platform. You can learn, you can grow with it and can really do wonders with it. Thank you. So have any questions? We're looking for questions. Do you have questions now? Yeah, so we thought it would be a lot faster but it was about six months or more. We started in November with our Dojo and right now we're at a point where we have our foundations up. They're on the latest version. I think it's 110 we're on right now and we're bringing users into our QA environment. We have to migrate them off the old environment and there's just a lot of challenges around firewall rules and things like that that just continually slows us down. But the best thing I can tell you about trying to get accelerated is try to think ahead as much as you need specifically around networks. That was where our biggest challenge was. But yeah. Yeah, we have five foundations up right now. As far as the journey, we are probably can go back. Yeah, sure. I think it was the last slide there. Is that the one you're talking about the last set of slides? Yeah. This one? Yeah, we are probably in the middle. Yeah, I was talking to some other customers like Home Depot and Comcast at a customer panel and I said that we are stuffing the powder keg right now ready to let it explode. This is where you really get a ton of adoption on the right side. You're ready to take on more consumers at that point and it sort of spreads virally. Developers talk a lot to each other and oh I had to spend four weeks filling out tickets and this other guy says I got an app published in five minutes. They're obviously gonna start asking questions and they'll be shoving it up to their leadership. Any other questions? Yep. Yeah, so right now it's organic more than anything. We're gonna be starting to drive more and more stuff into ServiceNow which is our self-service platform. We brought it in for cloud service management and it integrates well with VMware, Azure, things like that. Our first step in that was to create SonarCube. I don't know if you're familiar with that but it's basically like static code analysis. Self-service capability. We use that as a learning experience. Next step we're gonna automate org creation. We wanna be able to track the org ID and use it for billing. So we're gonna start driving more and more consumers into that self-service portal and drive their needs that way. We'll also do things like scaling up your org quota and things like that through that self-service portal. Yeah, so that's the goal, yeah. Yep. Yeah, so the pivot of sales is actually hitting the top up and we have too many consumers right now. There's enough gossip happening to where people are hitting us up left and right trying to get on the platform. So we don't really have an adoption problem as much as we're scrambling to meet that need. We had to sell it up to our senior VP of development and we had all of his direct reports in the room when we did that. That was sort of the initial introduction and then we focused on taking apps that were existing and moving them onto the enterprise platform and then from then we're gonna start to sell more and more. Any other questions? Oh yeah, like mainframe, for example. We have a pretty big footprint in mainframe. We went the Greenfield approach just saying it's sort of the bimodal IT. That stuff stays over here. If you're gonna do new app development, specifically web apps is really where we're targeting. Those can go on Cloud Foundry and it's not a platform of choice yet but the interest is being drum up from that. Our team also handles like Cloud self-service as well. So we're focused on VMs right now but we're looking at other IT processes like DNS and firewall requests and adding those to our backlog for implementation. So we're kind of building up all these different pieces at one time but the only thing that's in state right now is Cloud Foundry which makes it a good choice if you just wanna get a web app up and running really quick. All right, any other questions? All right, yeah. So, yeah, CFCLI and then we're using Pivotal Cloud Foundry specifically so the apps manager within there. I don't know if there's an equivalent to that in the open source ecosystem but we allow them to have access to that and then through the CI CD pipelines since we're using TFS release automation, it has a tile or task for CF push and we tell them to use that for deploying to their production environments but yeah, for the most part, you're developing, if you're doing .NET Visual Studio and then you're deploying through your CI CD pipelines. Yeah. Yeah, so we have an enterprise integration group that handles API management. They also handle things like data power and they were doing some work with enterprise logging and Splunk but we tend to push those needs to that group. As we get more and more mature, we'll start to look at more things to where the developer kind of has a single set of tools that they can utilize. Probably ServiceNow, Cloud Foundry, their developer workstation tools and TFS from our perspective. All right, any other questions? All right. All right. Well thank you everybody. Thank you everyone.