 All right, why don't we get started? Today we are going to be talking about a platform as a service in OpenStack. A lot of the discussions that you've been attending, I'm sure, and a lot of the talks at several OpenStack summits really focus on the technology, the processes, the infrastructure around OpenStack. And today what we're going to do is give you a brief overview of work that we've done with one of our customers with regards to platform as a service on top of OpenStack. So we're not going to dig down into the technology per se today, but we're really going to be talking about process and how an enterprise actually went ahead and built out an OpenStack cloud and then layered on top of it a platform as a service, not only the solution, the technology, but more also the processes, what the changes they needed to make to the organization to really take full advantage of an OpenStack cloud. So first of all, who are we? My name is Francesco Paola, CEO of a company called Selenia. We specialize in delivering solutions and services around OpenStack, the OpenStack ecosystem. And today I'm also going to have my VP of Operations, Seth Fox, walk you through that specific case study. We spent quite a bit of time at cloud scaling. We delivered services over the last 20 years from client server to e-business e-commerce, outsourcing, and now cloud for the last four years. And today we'll talk about some of our experiences in terms of delivering not only OpenStack, but also platform as a service on top of that. So very briefly, we're a company that has been around for about two years. We started the company to help organizations embrace and adopt cloud. We've been working in the OpenStack ecosystem for four years since its inception. Our CTO Ken Peppel is actually one of the first folks that actually contributed to the bear release. He built out an OpenStack cloud for his company, Internet, before starting Selenia with myself. We're building some IP around the edges, but really the core today that we want to convey to you is our experience in delivering technology solutions and new technology solutions for enterprise organizations, and specifically OpenStack clouds with platform as a service layered on top of it. So what I'll do first is I'm going to walk you through some very basic OpenStack implementation principles and again what we've seen in the enterprise space in the last couple of years. So let's assume that you've decided to implement OpenStack Cloud on-premise. And really on-premise, typically you drive that decision based upon business requirements, based upon specifics around workloads, based upon what you want to do from a competitive perspective. So let's assume that the drivers are the typical ones. The first and foremost is agility. Agility has been one of the primary drivers of organizations moving to cloud and specifically OpenStack. The second driver has been obviously cost savings, so we'll see later on as to why that is not the first reason organizations are actually moving to cloud. A third is operational efficiency. What cloud gives you gives you the ability to move much more quickly, gives you the ability to architect solutions that are specific to your needs, that give you the ability of your enterprise to actually move more quickly and to create standardization across the organization to create repetitive processes and become more responsive to the market. And then finally, the driver around openness. So not focusing on technology or solution that creates lock-in, but really creating an ecosystem that allows you to swap and change parts as they come to bear. And as you know, technology changes so quickly these days that you really wanna try to remain flexible in bringing in new technologies as they come to bear. But taking these four drivers, really the main one is agility. More and more so, we're finding that organizations want to move to the cloud because they wanna become more agile, more nimble. They wanna increase time to market. They wanna be able to deliver services to customers much more efficiently. They wanna do it in a repetitive manner. And really what cloud, the infrastructure of cloud and the services and processes on top of cloud give you that flexibility to respond to the market. So let's assume also that you've architected the OpenStack cloud. So specifically to support your current and future workloads. We've worked with organizations that are looking to deploy services to the cloud, both private and hybrid in some cases public around media and transcoding. We're working with a customer right now that is looking to deploy services where today they have static infrastructure. The infrastructure is not utilized to its full capacity. They've built an OpenStack cloud solution on premise, private cloud, and they wanna bridge the ability to go to an AWS or a Rackspace or another public cloud with the ability to deliver faster and better services to their customers. Another workloads that we see that are driving cloud adoption is around big data analytics. And in fact, we've worked with a customer in the manufacturing space that has wanted to build a specific requirement around a big data analytics for taking data from their R&D, their quality, their external partners and whatnot and analyze it and deploy value added services to its customers. And the reason why I'm walking you through these workloads is because not all OpenStack clouds are the same. The OpenStack architecture really depends on the workload that you're trying to support. Another example is HPC. We actually work with Cisco and Red Hat with an organization in the US called the Broad Institute where they sequenced the human genome back in the late 90s, early 2000s. And now they're opening up their infrastructure not only for internal consumption but also for the research institutes to be able to access that infrastructure, their data, their processes, their services. And so really the architecture for HPC was very, very different from what we did for a media company and what we did for this manufacturing company. And then there's obviously a proliferation of DevTest environments, which is typically where organizations go first in deploying OpenStack clouds to test it out. And there's more and many more that the workloads that actually drive the decision-making process. So let's assume that you've done your homework and you took our approach and actually approached that other organizations take like Morantis and others that actually help you rapidly deploy OpenStack clouds. And specifically what we've seen is starting with the proof of concept. Proof of concept allows you to test the technology in your environment. It allows you to test the technology that's integrated into the legacy infrastructure, allows your operators and developers to become familiar with the platform. And specifically once you build a proof of concept, you wanna be able to measure. You measure to optimize the architecture to optimize the processes to tune the infrastructure and then iterate on that infrastructure and deploy a pilot. And the pilot really here is getting a single rack up and running with production workloads and you do more measurement, more iteration until you get to a phase one of a production cloud. And this process is actually quite important if you're going to embrace OpenStack in your organization to be able to take full advantage of what it can bring you, especially with the innovations around Juno that have come out recently that are gonna be coming out in the next six months. You wanna have these test environments, POC, pilot to be able to test these new components and deploy them rapidly in your environment. And actually one great example is the case study that was published by the OpenStack Foundation around the car cloud where you can see this process in action and how this organization actually went from POC, measuring the performance requirements, measuring the cost, investing in a pilot and then going out to full production. So let's assume you've done all your homework. Let's assume you've walked through this process and you have a productive OpenStack cloud. And specifically you've got an infrastructure that gives you the agility that you need to deliver services much more quickly to your customers be they internal or external. You've built the architecture and infrastructure specific to the workloads that you're trying to deploy and really architecting the solution to be able to expand and scale beyond the specific workloads that you started with. And you've iterated and measured and deployed and continually deployed the infrastructure. But ultimately this is only gonna get you so far. Ultimately you wanna be able to scale. You wanna be able to scale to be able to achieve the agility metrics that you've set yourself out to get. You wanna start hitting those cost metrics because ultimately you can justify the investment in the infrastructure to your executives up to a certain point. But until they start seeing the results from a cost perspective, then the growth and scale of that cloud is gonna slow down. So you need to really identify those cost metrics and measure the results. And then finally you wanna hit the operational efficiency targets and specifically around quality, repeatability, standardization, being able to allow your developers to use code as a service, call data stores as a service, et cetera, to be able to really take full advantage of the infrastructure. And so what we see now is taking the open stack infrastructure but in and of itself the technology is only gonna get you so far. And really when you're building a private cloud within an enterprise, you really need to look at the whole ecosystem. So open stack is one component but ultimately you're gonna have to look at process. How does my procurement process for a server change from the four months that it takes me to get a physical piece of hardware in the data center two weeks to days to hours? How does the organization have to change in order to be able to take full advantage of this new flexible technology that gives you the agility? So organizationally in terms of how do you break down the barriers between your server team, your network team, your storage team, breaking down the barriers between the development teams and the ops teams. And then finally looking at the skills. Are your skill sets today where they need to be in order to project you into the future and take full advantage of these new technologies? And we'll get to what sits on top of open stack in a second but in other words, you need to look at the entire life cycle. So today a lot of organizations are segregated and separated into very specific discreet units of ownership and there are gates that you need to pass through, right? There's the business that drives the requirements, comes up with new services for their customers. They hand off the specs of the developers. The developers work in a somewhat of a closed environment without an understanding of what really the market is asking for on a day to day basis and without an understanding of what the deployment teams and the operations teams have to do to get their applications to market. So we start looking at the layering on of these softer services. So you look at the layering on of agile methodologies. So going from waterfall to agile. So enabling your developers to be more iterative in their approach, be more connected to the business units, be more connected to the teams that are gonna be deploying the applications and in some cases moving some of the development capabilities into the deployment teams and to the operations team. Then you layer on the DevOps components. So DevOps specifically around tool chain, tool chains and technologies that facilitate the process, the implementation of CI CD processes, the implementation of the continuous deployment capabilities and really getting those core skill sets ingrained within the development teams and the operations teams to kind of mix and match those capabilities and work hand in hand to facilitate the deployment of these services. But ultimately there's one piece that's missing. And we've seen this recently with the financial services customer where you talk about driving agile through the enterprise at the CIO level to get 5,000 developers to move to leverage agile. You start looking at an independent work stream around DevOps or bringing in tool chains, bringing in the technologies that allow you to be much more effective at driving that. But ultimately there's really no glue that keeps this all together. And the glue that we found that actually functions really, really well is Platform as a Service. Platform as a Service here is not really about the technology because OpenShift and Cloud Foundry and other solutions actually do the job pretty well depending on the technologies that you have in-house, that you want to migrate from legacy to Cloud, that you are building Greenfield. So what you really need to do is, the first thing you need to do before we introduce this Platform as a Service concept, again, not a technology but a concept and a set of processes, is defining it. So we've actually worked with several customers and this is a summary of what we've seen fits the definition quite well. And you can see that Platform as a Service really is a combination of common shared services. Services that can be called upon by developers that are commonly shared across the organization that allow the customers, the developers, to actually be much more effective at deploying their applications. You've got Platform Services that are commonly accessed. You've got Published Services where development teams that actually create common services can then publish them and allow other development teams to leverage. And there's data services interfaces. In other words, a lot of enterprises have a lot of legacy data, a lot of data stores, a lot of information that resides in multiple silos and you really want to look at building interfaces to be able to extract that information as a service in a pull method for the development teams to be able to take advantage of it. And then really look, OpenStack is one component. It's the component at the bottom, it's the infrastructure that actually everything sits on. But if you're really gonna take advantage of this technology, get the agility that you're looking for, get the cost savings that you're looking for, you really have to look at the whole when it comes to implementing a full platform as a service on top of the infrastructure. And so what actually, what does this get you? It gives you the ability to automate. So automation in terms of being able to call up services as opposed to writing them from scratch every time that a developer needs them. It gives you the developer velocity. In other words, they are much more efficient and quick and fast in terms of being able to put applications together and really taking all these components that you're starting to build and deploying in a centralized environment and pull them into the applications and leverage those services in a common manner so that you don't have to reinvent the wheel every time. You're also setting standards. Standards in terms of being able to create repeatability, being able to create processes and components that can be used across the organization, and then finally giving the developers the control. So the ultimate goal of platform as a service is to turn and invert the way services are pushed out to developers and turn it around and let the developer actually call those services up when they need them. So now I'm gonna turn it over to Seth and let me introduce this case study in a second. So one of our customers, a Fortune 100 Financial Services Institution, actually has been investing and building at OpenStack for the last 12 months. And what they found is they've developed a strategy to migrate applications to OpenStack, but they found that the development teams were kind of left behind. There was an agile initiative within the organization to get all the developers to be much more efficient at delivering code and applications, but it was segmented and segregated from the OpenStack deployment. And so what they did was they said, look, we need a platform as a service strategy, right? Yes, we understand there's a technology component that sits on top of OpenStack, but ultimately we need to understand how do we reconfigure our environment? How do we change the culture in the organization so that developers are incented to use these common services? Developers are incented to create standardized services and processes so that we can be much more agile and much more efficient at delivering these services to our customers. And specifically with the competition that exists today with the rate of change of technology, this is a very critical component in being able to respond to market changes, new technology introductions, being able to address competitive threats much more readily, whether it's competitive threats coming from your traditional competitors or new entrants in the market. So if you look at this financial services organization, with the proliferation of payment options, this was a real threat to them. And so what they needed to do is they needed to not only embrace this new technology, but also be able to deliver services on top of their legacy environments and move some of those legacy environments to this agile platform to be able to take full advantage of the opportunity. So with that, I'm gonna hand it over to Seth and he's gonna walk you through the case study and kinda talk about the business drivers, the infrastructure that we set up, the processes that we looked at and some of the benefits that came out of it. Thank you, Francesco. So what were the business drivers, right? Francesco touched on the first one here, competitive threats, the small company that's gonna come and overtake the Fortune 100. It's happening all the time and they really need to be able to respond to that and handle those types of environments and the way their development environments were set up today and when the beginning when we started this project, there was no way for them to respond quickly at all. They really could not react to the environment. They had to, and when this happens to these big companies, it's extremely frustrating and that goes to time to market, right? Being able to get those things out and serviced and to their customers very quickly and iterate on them, right? Go through that agile enterprise and really make sure that they're getting what they need to their customer base. Service quality and availability, uptime is obviously very important for a financial institution, so making sure that they could maintain that as they moved into a platform as a service environment was critical for them as well so that their brand was not impacted by these types of changes. They need to make sure that in this new technology, they're using OpenSAC and a PAS platform, right? Using those environments that their brand is still there so their availability and quality is still showing through. Reduced costs, I think Francesco touched on it, wasn't a major driver for them. Their goal was really the other three, but it was definitely something that they knew was gonna come along for it. They weren't focused, however, a ton of energy on that because if you're just doing this to reduce costs, you're not really gonna see all the benefits out of this. So by taking this and literally putting it to the bottom of the list for their priorities, I think it gave them a lot of ability to focus on the other areas that they needed to be successful here. So what we did with them is we worked out some guiding principles, right? If you're gonna do this, this is actually a very big shift. They had a very large set of waterfall development process. Wanted to move to Agile, they had a ton of outsourcing, a lot of customers, a lot of companies that they had worked with doing development processes in different ways and they needed to get that in line. So to do that, Agile was a prerequisite, right? We didn't wanna embrace waterfall development cycles into this past platform. It was gonna be too much of a learning curve for those teams at that point. So we had to make sure that there was a prerequisite. The teams were all migrating to an Agile development cycle and this really was a prerequisite to get started. Inversion of control, Francesco touched upon this. You know, typically in their organization, which we see a lot in a lot of places, is software is pushed over the fence, right? And if you wanna use somebody else's software in the enterprise, you have to have a meeting, you sit down, you work out what you're gonna do, and then you go and you start to consume it. This inversion of control really works the other way. You're not building applications anymore, you're building services that are consumed by developers. Developers can just start using services and there's a development environment to set that up. So you have an authentication service, for example, people can really just start using it. So the stuff doesn't need to get rebuilt. You know, what we always see is we don't wanna have the meeting so we're just gonna build it ourselves. The inversion of control really eliminates that and make sure that people can get started doing what they're doing. Developer-centric environment, I think, in a lot of our large enterprises, developers aren't sort of the focus, right? I think some of us work in small companies where developers are really the core. They wanted to be able to take that and create that environment inside this financial services organization so that they could entice people to come work for them. You know, we heard stories about people that they couldn't hire. So they didn't have this type of environment for their developers, so they wanted to create that here. So, and invest in the platform and not the projects. What this is really about is, you know, everyone built their own projects and rebuilt their own services and they all had their own infrastructure as well. So build this platform up, build this path together, and make it an enterprise path and really not just, you know, it's not this department's path or this project's path. It's really getting that, getting it up and running. To do that, it has to be centrally engineered and centrally managed. So you have one team that's growing that out and there's a focus to actually build just the paths, team to build that, and we'll talk about that as people are building services to run on top of it. And paths must be prescriptive, right? What this is really talking about is, you know, inside this financial services company, every group sort of picked their own tools and their own products. We're gonna use this J2E engine, right? Everyone's got a different version of something that they wanna use. Paths, really, you have to get that in line. This is how it's going to work, right? And paths eliminates a lot of those barriers so people don't have to make those decisions. But if you have a service to consume, you tend to make different choices and that was pretty important to the success here. And an open community development approach. So when you have, you know, maybe you're trying to consume a service and it doesn't have that functionality that you're looking for within the enterprise, take this community approach and maybe you can build it for that team or you put it in their backlog and keep that process moving forward. So basically take what we've got here in the open stack community and try to build an internal community of developers. You know, for Jessica said, 5,000 developers, it's a good size, they can really, you know, generate this type of stuff inside their organization. So what were the base platform characteristics? This is kind of an overview. If you look at it, you know, the key thing here, developers generate their specific code, their service code and infrastructure code. You know, this concept of infrastructure as code is coming through the open stack community, pretty well, but you know, a lot of large enterprises haven't seen that before. Make sure that you're describing your infrastructure in a way that is maintainable, repeatable, version control, all those things that you need, so that as you move between environments, that'll happen here, you know, stuff is the same everywhere because you run into problems in particular, in this case, the differences between each of the environments was so wide, you know, it would take a long time to go from dev to test to prod and so on. So what we created for them was a sandbox environment with common services that I'll talk about in a little bit, but they would be able to play around and learn paths in this environment. And then when they wanted to get into their full, in the full environments, source control, CICD, code review, text fixtures, test fixtures were all there. They had very specific release gates that they wanted to go through to do this. Some of them were human, some of them could be automated. So as you went into the test environments, you know, that was automated, but as you get to production, there needed to be a person to say, yes, this code is ready, we've officially tested it, and the release tools were doing this. It was fully automated. The goal is to make this fully automated throughout the life cycle, so you don't have the oops as you're putting it into the production environment, right? And to get there, it's about service discovery, SOA enablement, the community development model, which we talked about, and their focus was open source where possible. They wanted to start consuming as much open source as possible. In this particular case, they weren't as comfortable yet in contributing to open source. They were working on that, but they wanted to definitely consume it and make sure it worked. So how do you get there? We put together for them was an MVP approach, minimum viable product, get something up, get people using it, and get the ball rolling inside the organization. So to do that, we built some base common services, logging, monitoring, single sign-on. So these are things that everybody could come up and consume. These were the top three in this organization of things that they knew all the applications needed extensively, right? So they didn't have to come in and build a logging facility or build a monitoring facility. They used a single sign-on service. So all the applications would sort of have these to start. Build out a Hello World app that people could come in and clone and start working on, right? People have to learn these environments. So put together a WordPress application, a three tier application that does single sign-on and integrates to a logging and monitoring service so they could see how it works. And with that, people would actually come in and extend these services, right? Certificate management, caching, load balancing. These were the priorities for this organization. And you'd go through the different milestones and eventually you'd end up with these scaled applications. People were just adding to the services. They would start in the sandbox and that same production release that we talked about would actually get them all the way through in the production environments. And at that point, your platform is growing. Not applications individually, but the entire platform is growing. So when you're done, you have to measure success, right? This is very important in a lot of large enterprises. We have to know, did this work or didn't it work and why didn't it work, those types of things. So there were three major categories that we talked about for them in terms of measuring success, agility, efficiency and quality. In the agility side, production release velocity was a major measurement for them. Their production release cycles were very slow. Typically in an agile environment, it's kind of a coming to a point, right? You deploy a lot and then eventually you're stopping. You do one deployment and that's your production. So getting that release velocity down, the cycle times down was very important to them. Development environment provisioning time, I think we've probably all seen this. You give a developer needs a set of machines. I've seen this with several of our customers and it takes six months to get them a development environment set up and then they hoard it, right? Because they can't get it back, right? So to make sure that this provisioning time came down in a PAS environment, they could come up, push a button and their development environment would appear and they could destroy it because they knew they could get it again. So you're not wasting these resources. Those six servers that developer got and they're hoarding are sitting there doing nothing when they're out of cycle, but with this they would actually get a lot more efficiency. I think they estimated they had some like, some like 80% of available resources were idle because of used resources were actually idle because developers were keeping them because they knew they couldn't get them again. And then PAS adoption, we wanted to make sure we're measuring the adoption rates. When they're coming on with new services, were they actually choosing the PAS platform, right? How are they making sure that this is all happening in the right place? So the developer wait cycles was an efficiency task as well and it kind of goes with the provisioning time. The developers end up waiting when the hardware is being provisioned and that takes a lot of time. And then dev test defect rate. As you can, you know, as you go through these things and your services are actually getting smaller than your bigger applications, your defect rates go down and that was a great way to measure for them. So in terms of success factors that were important to this enterprise, you know, developing the technical community, making sure that these people were not just good at building applications for them, but they were actually getting better and getting smarter and growing, right? Getting that developer centric focus. Minimize lock in, it's pretty common. That's why we're all sort of at this open stack event, right? We don't want to get stuck on one vendor and really get locked in so we're stuck doing things a certain way. And then taking an MVP approach that we talked about, right? Get something out, get it started, get people using it and then iterate, get it moving forward. And that same methodology applied to all the agility they needed with their external threats from companies that were trying to take them over the market. This one's pretty critical because you'll find in a lot of organizations we've seen there's always one or two people that want to do this and they're really excited by it and there's a bunch of people that are just, they're terrified or don't want to do it, they don't like change whatever that is. So you need to find the champions inside the organizations that want to do this and tell everyone else how great it was. So you pick one or two people and we walk through, as we talk to the different development teams, it became very clear to us who was ready for this and who wasn't and who was really excited by it. And you take the really excited people and get them to lead the charge and they really make a big difference in terms of way this adopts through your organization. And then the SOA enablement, right? This is really again, I think I've said this a bunch of times, build services not applications so that you're not duplicating things as you go through and then measure the key performance indicator so that we talked about, right? That you need to have those metrics when you're done. So to do this, it's actually a different organization than they had today. You know, when we stepped through this, the ID here, the program manager sort of runs the overall PAS program for this business. There were five major areas that reported up to that. In this case, it's policy, KPI, tracking communications in the PAS architect. Different organizations, those are gonna be different. This is sort of the way this organization was laid out. And those people are really driving the overall PAS platform. There's product managers and project managers. Product managers would grow over time as the platform got bigger. They'd handle different areas. Maybe over time you'd have a data-centric product manager, service-centric project managers and so on. You can grow that out. And project managers to make sure everyone is sort of going on. And below them you'd have PAS engineers and scrum masters to really make sure that you're moving through. The governance is also important, and Francesco talked about that, making sure the business is ready for it. Those would create working groups that would involve security program. Other groups in the organization would fit in here. When they needed to bring something into this group, it would go through the governance body, it would create a backlog, go into the project management group, and those would feed into a task team. The task team was actually multifunction. They came from different parts of the organization. They would feed into this group and build these tasks and clear out the backlog in that fashion. There was also an exchange between operations and PAS engineers. I think I've seen this a lot with our customers. The operations guys are generally not, and a lot of times that's where I get a lot of, I've seen a lot of most of the resistance, excuse me, from cloud and platform as a service. So getting those guys to work with the PAS team and have the PAS team work with the ops team so everyone sort of understood what everyone else was doing, really created this culture for them that would enable this DevOps and they'd always feed in external resources. There's always an SME somewhere that understands this particular product better. They could feed into this task team. Maybe it's an app owner, a business owner, or a third party in their case. They had external resources that needed to come into this environment. So what we're looking at here is sort of the timeline that we put together for them. This was seven quarters to get this going and you start with governance. You have to have that operating body. You have to make sure people know what they're going to do. If you were just having a conversation earlier, you don't do the architecture. You don't do the installation before you do the architecture. In this case, in terms of the business process, you have to have the governance in place. The tool chain, they had a lot of different tools running around the organization. Everyone was using a combination of Jenkins and everything else. Get that in order. Make sure everyone's using a similar platform so it all works together. Then you go out and you actually do a deployment. You put together a PaaS environment and then what we put together for them was a series of workload onboarding. You start with those PaaS champions, they're working in the sandbox, they're actually building out sandbox services and then as they add their services on, they're getting to the point where the platform gets to a certain size and then you sort of have critical mass and then you can build this self-service PaaS platform for people to come through. So, you know, this is really the... I'm going to just put up the boxes here. But, you know, the goal here, one of their major drivers was this development-centric culture. They had offices around the country. They were building an office in Palo Alto in California right to get up and running, to make sure that they could actually hire the right people and get this developer-centric culture in place so that they could build applications that were modern, that would handle the loads that they need and give them the ability to innovate when needed. And the PaaS tenants that sort of are... When they're done, this is what we've got, a centrally managed platform. Again, invest in the platform, not in the project so that it grows and then the prescriptive framework that we talked about and then shared services. So, with that, we can open up the floor to questions. We have a few minutes left. Yes. Sure, so the stack here was open stack and VM were underneath and then it was OpenShift on top and working with cartridges, right? They would pull in different cartridges to make that work. So yeah, they were very open to the open source environments for sure. Which platform was it? We went through an evaluation with them and we were looking at cloud foundry from a couple different vendors, right? And OpenShift and based on the relationship with Red Hat and everything they were doing, there was also a very specific J2E requirement that OpenShift met very well for them and would help them move a lot faster through this. So that was one of the other reasons they chose the OpenShift platform. So, from that perspective, we were building cartridges that would actually run in the OpenShift platform that would expose their legacy data into the cloud. They're also looking at potentially using Cassandra to cache data in the PAS platform. So they didn't always have to reach out to the central Oracle database or to the mainframe sometimes, right? This is a big financial institution. So, getting those services cloud ready is part of the foundation that you have to build to get these platforms successful. We actually, we helped them with the strategy around developing the processes that they needed to put in place and also the architecture, the fundamental architecture that they needed to put in place on top of the OpenStack environment that they had. We work in both, right? We can go from the process down to the deployments, right? So we work across the spectrum. I think there's a question behind you actually, yeah. We don't have the measurements yet but we're still working with them so we're hoping to get that soon. Don't have the answer to that one yet, sorry. So, but the before processes were measured in months. Correct. And they're trying to get to weeks and if they get to weeks, that's a win for them, right? Exactly. Yes, in the back? Sorry, I'm having a little trouble hearing you. Maybe you can step up to the microphone? Sorry. The question was around what other case studies? Yeah, we can share those with you after the event if you'd like but specifically you're talking about the case studies for the other workloads. Okay, yeah, we can certainly share those with you afterwards but one of them, the Car Cloud case study you can find on the openstack.org website and download that, yes? Sure, so the way we defined the platform services were ones that were centrally developed by a core incubation team so to speak. The published services were services that were written by the individual development teams that they wanted to allow other teams to actually use. So that's how we, it's basically, they're both common shared services but the generation of those, the development of those services is really one is centralized and one is distributed. Okay, any more questions? Anyone else? Great, thanks very much for attending. Thank you very much. Appreciate it.