 So, thanks for coming. This is our story of how we got to Cloud Foundry, so I would start by saying that, you know, we had similar problems, but obviously we're at the Cloud Foundry Summit, so we came to similar solutions as everyone else. But I'll give you a brief history of DemandBridge. We are a small technology company that has a large but kind of a niche customer base in the print industry, and we're a Java Spring shop, and our main product is a B2B e-commerce platform that our customers use and resell to their customers, and it has about a 20 code base that I've worked on for about 12 years, and, you know, it's been through a lot, and we've added a lot to it, and we've not refactored a whole lot with it. So we had the same problems that most of the Cloud Foundry adoption stories start with. We had a large outdated monolithic application, deploys were awful, and we wanted to scale evolve, move faster, risk less, and deploy more. But where we differ, I think, from most people, and especially from the people that are highlighted in the keynotes, and Abby and Chip helped us out by highlighting Comcast, who, Comcast is amazing, and we followed them through their whole journey, but, you know, they're boasting 2,500, 3,000 developers, 40,000 app instances. We have four developers and zero dedicated ops, and that's not something that we tout. It's something that, frankly, it gave us kind of a complex where we didn't feel like we belonged, and so we would hear these keynotes at the Spring conference, and now at the Cloud Foundry summit as we were kind of evaluating, and, you know, we kind of felt like this stuff, a lot of the cutting edge technology was just out of reach for us. So that's, we tried to remain, you know, relevant, we tried to keep up to date with things that were going on, but we just couldn't touch it. So we were on our own, and the reason for the zero dedicated ops was we were for a long time the software development arm of a print distributorship, who are now, you know, one of our many customers, but the most we could ever hope for was that our application server and our database VMs were online and connected to the internet, and everything else was in our hands, so, you know, we cobbled together what we could, and, you know, it worked wonderfully for us for a long time. So, due to our kind of licensing restrictions, mostly on our web logic server, we were stuck at Java 1.5, and that wasn't a problem for a very long time because of backwards compatibility, and Spring did a great job of allowing us to use some of the newer features, but we would attend the Spring conference every year just to kind of stay up to date, and over time the Spring conference even became less and less relevant to us because the newer things were just not backwards compatible, and we couldn't take advantage of the latest Spring framework, and that was a problem, and I think that one of the light bulbs that went off was, I kept hearing about this monolith, and we're like, what's wrong with the monolith? We've got a monolith, and it works great for us, but we got to a point, and we're hearing about Cloud Foundry, we're hearing about the infancy of Cloud Foundry from Pivotal, and it was amazing, but we just couldn't see where it fit, and Spring Boot as well, we saw Spring Boot come from its infancy up to a point where it was like a mainstream conversation at the Spring conference, but we just didn't see a fit for it, and we had a big giant web logic server, and that was all we ever knew, and it didn't like us doing anything new and fancy. So I think the light bulb went off when we were sitting at one of the Spring conferences, and it was like everything that was thrown out of the keynote speech was just over our heads, it was just something that we couldn't reach out for, but the monolith was resounding, like we've got one of those, that's great, and then it was the first time I heard the term technical debt, I said we've got that too, that's the only thing we can take away from this conference. So I think it was when the Spring Cloud suite really came to the forefront that we started to realize maybe we could take advantage of some of these things, maybe we could leverage some of this new technology, we started to wrap our heads around the idea of 12-factor and the idea of maybe breaking apart some of the pieces of our application and hosting them elsewhere. So now we kind of met back up with everybody that was going on this Cloud Foundry journey, we've got a problem, we know what it is, it's the monolith, we're no longer defending our monolith, we realize it's the problem, so we have to learn what microservices are, what containers are, but okay let's do it, we don't have a choice, we were running into two performance issues and we didn't have a solution, there was no upgrading the monolith, there was no upgrading our WebLogic server, there was no hardware we could throw at the problem, so maybe we can use Spring Boot, maybe that's our answer and Kim, all of our developers are here with us today, which is not a stretch, so Kim said we came back from whatever the latest Spring Conference was, it really was the one that technical debt, monolith, okay we're on the same page now, and she said we just have to build one of these things to try it out, and we saw the benefits of it, but what do we do with these things? Spring Boot is great, it's going to allow us to use newer technologies, it's going to allow us to not worry about the nightmare of our dev WebLogic server versus our prod WebLogic server, but what do we do with it? So for a while this thing, which we forced into production, we forced ourselves to use it, it just lived on an otherwise empty VM with Java installed, which was scary and we thought to ourselves like there's no way we can have more than one of these things, so what do we do? So we spent a few months playing around with Docker and the idea of containerization and that whole methodology was a no-brainer, awesome, but that just really abstracted the problem of where to put these things, so we realized that without that dedicated ops, without dev ops becoming more a part of our culture, we have no way of managing these other applications or these other environments, we have no way of managing a Docker machine. We ordered a couple pizzas, but that didn't work, we were just sitting there eating cold pizza, but we realized that we needed to solve this problem, we needed to branch out, but we didn't know who to hire, because what is the solution that we're going after? We didn't want to hire someone fresh and say, here, help us solve this problem, we wanted to say, here, are we going to do, is Docker the answer, is Swarm good enough or are we going to go with something like MISOS or Kubernetes? There were all these different things we were weighing to try and find, okay, how do we narrow down our search for someone to join the team and help us move into the future? As we were evaluating the complexities of MISOS and the complexity of Kubernetes at the time, and this was in its infancy, and I know that it's still very complicated, but it's also more mainstream now, this was, we were just scratching the surface at that time and we knew we were in over our heads, but I guess serendipitously, we received an invitation to the Cloud Foundry Summit, and this was, we didn't even realize there was a Cloud Foundry Summit, we had been hearing about Cloud Foundry from Pivotal at the Spring Conference, and that was awesome. Again, we didn't really see how it fit, and we actually talked to Pivotal, they came and met with us and talked about our infrastructure, and I think we came away with more questions than answers, but they were extremely helpful. More questions about ourselves and about the way that we had structured our own application and how we could even move it into the future, but we saw this invitation to the Cloud Foundry Summit, and it was an open source. The Cloud Foundry Foundation, it wasn't one vendor, all the vendors were represented, and it was eye-opening, and we thought, we're looking at Mises and Kubernetes, why not try out Cloud Foundry, and see if an open source Cloud Foundry is something that we could achieve, is something that we could maybe hire someone to help us out with and join our team and build, and so we attended the Cloud Foundry Summit, and we got there and it was awesome, it was eye-opening, it was the big lights and the big presentations about how wonderful CF push is, and what it really spoke to us, especially over the Docker solutions, was how it just naturally took our spring boot apps and just spring in general, and I remember listening to Ansi after we were touting his famous haiku, listening to him give a talk about how Cloud Foundry wants to take your app and love it as much as you do, and take care of it, and we thought that's perfect because when we were trying out Docker, it wasn't pretty. As far as what we were able to do with it and as far as the image that we got, it wasn't so much the big beautiful ship with all the containers neatly stacked up, it was more like the second season of the wire, if anyone is familiar with Union Reps losing containers, and it wasn't the nice wholesome story that Cloud Foundry tells, so we get to the CF Summit, awesome. We want to try and do open-source CF because monetarily, the way that things broke down when we did talk to Pivotal was such that for such a small company, and I realize that now there's probably so many more options, different pricing tiers, and there are also so many more certified distributions, which is awesome. At the time there weren't many, and we wanted to check out the open-source side of things, so we got there and as part of the keynote, they made an announcement about brand new Cloud Foundry support for the Azure hypervisor, and we thought, wow, we didn't even know that was a question we needed to ask, but perfect because we use Azure and I guess now we can use Cloud Foundry. After the keynote, we ran to the vendor booth or the vendor area and we made a beeline for the Azure booth. You guys are who we need to talk to. We were on Azure, we want to do Cloud Foundry, tell us how. I said, it's so easy, it's so easy. You just click the install PCF button, and we said, that's awesome. I'm glad that that works, but for us, unfortunately, that model wasn't what we thought was sustainable for us, and we probably weren't looking at it right, but we were so focused on the open-source side of things, and we only saw that as our only option for Cloud Foundry, monetarily, but also our ability to scale at a very small number of apps steadily and have it be cost-effective. I said, no, no, we're not looking to install PCF right now. We were hoping to check out open-source Cloud Foundry, and I think she said, yikes, I don't want anything to do with that. I think she actually said yikes, but the general theme in the vendor area, when we talked about open-source Cloud Foundry at the time, and this is one of the earlier CF summits, I think it was 2015, 2016, but the feedback we got was like yikes, that's really hard, good luck, and that was kind of a bummer for us, but we were determined, and so we tried to absorb as much as we could, and then we went back to our hotel rooms and banged away at Bosch Light, and that was a head scratcher, but we came back and we, like I said, we were kind of a little bit beaten down, but there were so many things to learn at the summit, and that year Dr. Nick was the emcee, and he's larger than life, and and also, and I see you guys are wearing the blue shirts, and I like the blue a lot, this is a nice bright blue, but they had a bright red shirt, stark and wane, and they were everywhere, they were like 50 of them, I don't think I'm exact, I mean I guess that's an exaggeration, but but they were the they were like the authority, and so we said, okay, we spent all night banging away at Bosch Light, trying to get this thing working, nothing's working, let's go talk to these stark and wane guys, they seem like an authority, and so we hammered them with questions, and they, I think we wore on their patience, I'm sure, but I think it, like the solutions to our problems and the answers to our questions were so complex that we just, we realized, like listen, we can't do this alone, we understand that now, we need to find someone with experience to help us, we realize that, it's not something that we could shepherd through with someone that has a little bit of knowledge of CF, and maybe could join our team, we need a much bigger presence, a much more expertise in order for us to make this happen, but we are still in this mindset of, like do we deserve this technology, we're so small, and everything we hear, and certainly everything we heard at the time is, these stories of these big, huge enterprises, and it's amazing and we need that, and that's so important to making sure that we have a, you know, a platform that is, that is, you know, full of life and can, and can, you know, carry our, our platform and our, our business in the future, but, but we didn't feel like we kind of really belong, so we said, okay, stark and wane, these guys are, these guys are the authorities, we need to find someone like that, but who caters to small businesses, so we, we, we racked our brains and we searched and searched, and then months later, we would tell the story, and it was a joke, because someone, it was, Brian, it was, someone came to us and said, look, we need to have a talk, like, you keep saying that, you know, you were looking for a stark and wane for the little guys, and you know, haha, but we ended up with stark and wane, and they said, what are we doing wrong with our marketing, because why didn't you just come to us, and, and I say, you know, it wasn't, it wasn't you guys, it was, it was us, it was this mentality, it was this complex, it was, it was this, just feeling like we were too small to deserve something like this, feeling like we were too small to, to play in this community, but we did end up reaching out to stark and wane after walking in circles for a month, and they were super accommodating. They answered all of our questions, they, they, they walked through, you know, and level-set expectations with us, they talked about how, you know, how complex the, the, the, you know, certainly Bosch is, and just the whole, the, the maintenance of Cloud Foundry, and how you need it to be a living, breathing thing, and you need someone to be maintaining it constantly for you, and so, you know, whether you're open source or you're through one of these distributions, it's, it's, it's not an easy thing to bite off, and it's not, it's just not something you can do alone, but luckily they could help, and, and we, and we believe that, and so we went through a bunch of different options, but we ended up saying, like, let's just, this, this is what we need, and by the way, meanwhile, we're having all sorts of, of performance issues, and our customers are noticing, and like I said, we, we didn't have another solution, so we said, guys, please help us, and they did, and they sent a couple people to, to, to kind of immerse us in Bosch and CF, and yeah. It was 2016, the end of 2016 was when we were doing our evaluation, and when, when we, when we first started down the journey, I think it was, it was maybe even January of 2017 that we started the actual build with Starkeman. So, so they, they, you know, we, we partnered up and, and they came out and, and like I said, they sent two rock stars to help us out, and they, they sat with us for an entire week, and built out our Cloud Foundry environment, but they built it up with us, and I, you know, we, we took what we could from what they were teaching us, but they also taught us best practices, and they taught us, you know, how to use Cloud Foundry responsibly, and they, they left us with much more than just our Cloud Foundry environments, they left us with Concourse, which is our second greatest love these days next to Cloud Foundry, but, but other things like Save and Vault, and, and lots of different community contributions that, that they had vetted, and it was awesome. It was, it was eye-opening to see, you know, the, the, the inner workings and, and how deep the knowledge and the expertise was that, that these guys were able to share with us. So, after a week, we had a dev and a prod Cloud Foundry up and running in Azure, we, we threw our proof of concepts at it, easy, simple, we threw our Spring Cloud, you know, sweet at it, could not have been easier, it just worked, and, and, and it was, it was this, this parting of ways when they left, they, they turned the keys over to us, and it wasn't, here you go, goodbye, and good luck, it was, all right, are you, are you ready? Let's do this together, and, you know, it was, it was awesome. We, we really felt like we had a partner, and, and we had Cloud Foundry, but we had the backing of Stark and Wayne, and that was, that was excellent. So, now we had it, now we started to use it, and we, we threw everything we could at it, and, and everything that we had seen at the Cloud Foundry summits we attended, it came to life, it was, it was all real, it was the, the CF push, awesome, all of the anecdotes about the ease of, of mapping routes, and, and binding services, and scaling apps, it was all, it was all real, and, and the, the, the fact that Cloud Foundry just kind of takes care of your app and makes sure that it's still running, it was great, we, we kind of take that for granted sometime, sometimes we, we had an app that was failing every ten minutes, that we, for months we didn't realize, because it, you know, Cloud Foundry's just bringing it back up before the, the, the second instance was failing, and, you know, so we're, we're gonna get better at that, but, but yeah, no, Cloud Foundry did everything that it promised, and, and that was amazing, and it was amazing for us because, you know, I think it wasn't, it was emotional, I know for me, I think more than, more than just me, to, to sit back and say, you know, we, we, with Cloud Foundry, and especially with, with the backing of Stark and Wayne, you know, we have the same infrastructure as these big enterprises now, it's, it's, it's a matter of Diego cells at this point, and I don't know, that was, that was a huge, huge jump for us from, you know, a couple years ago, when we were, we were really doubting ourselves, so, that was awesome, it felt really great, and the most important thing was that with four developers, we were able to just run full speed, and not worry about our application, not worry about the, the, the, the application server, the, the infrastructure, it was just throw as much as you could at it, and, and, and, and make as much improvement to the system as possible, and, and we were able to do that, it was, it was awesome, take advantage of all the latest features of Java, all the, all the latest, latest spring frameworks, and, and, and everything else that we've been dying to get our hands on, and, and, like I said, not worry about how to manage these things. So, you know, where are we now, we have a lot of code to rewrite, we, we still have a monolith, but our code base, and our application architecture is vibrant, and, and it's a pleasure to work with, and that was not the case for a very long time. So it, it's, it was, it was in the span of from getting up and running with Cloud Foundry to throwing as much as we could at, at the, the environment. It was, it was a few months and, and we, as a team just had a complete 180 in, in our, just our approach to development and, in, in our quality of life. It was just, it was just excellent. So where are we now? So we're, we're, we're Cloud Foundry users now. It's a totally different experience to be at the summit. And to be at the Spring Conference too, because we, you know, we, we, we have shared this journey with these big companies, you know, we've had similar transformations, albeit at a much smaller scale, and, and it, and it feels great. It's, you know, we still, I, I know I, I slip back into this, this mindset of, you know, all, you guys are talking about things that are just way, way out of my league, but, but you know, we, we, we have a great foundation and, and, and we have a lot of, a lot of pride in, in, in our environment and, and in, you know, our application and where, where, like I said, we didn't for a long time. So where we started was we had that large monolithic application, long, painful deploys and the need to scale evolve, move faster, risk less, and deploy more. And so now we have a smaller, updated monolithic shell of an application. You know, we've been strangling that thing as much as we could. We were, before we even heard the term, we were like, that's, let's just get, rip this thing apart. And we had, we had a means to do it, and that was awesome. So we have one occasional deploy. It's, it's, it's not every sprint that we deploy our monolith. But we have now 83 app instances and 53 unique apps out there. That's, which is mind blowing to, they even think about how, how we would manage that a few years ago. And we're deploying them constantly, these, these, these apps, and we're pushing them with very little risks to prod. And, you know, we're, we're doing the same, the same things that we hear up on, on the main stage, just, like I said, at a smaller scale. And we started, we had four developers and we had zero dedicated ops. Now we still have four developers, but we have 10,000 plus ops, I like to say, which is, which translates to one primary resource at Starkewing, 35 members of the collective who support us regularly. And then all of the Cloud Foundry community members, which is, which is awesome. And we, we work with our resource, Kevin, and, and, and so many more on a daily basis. And we, we reach out to the collective regularly. And, and through Starkewing, we have contributed to, worked with and found answers from the community, you know, the whole time. It's, it's, it's been great. So what's next? We have, we have a lot of work to do with our monolith still. But we have the answer, like it's just a matter of plugging away. And we're, we are pushing more code than we ever have. And we'll continue to do that. So we want to work towards continuous delivery. And, and we're not shy, you know, about pursuing that anymore. Because, you know, once we, once we got over this hurdle, you know, I think anything's possible. And then we want to move the rest of, we have other applications. And now with all the, the talk about CFCR, that's, that's a reality for us, I think. You know, these guys, we're talking about Kubo when it was first announced. And how can we, like, what can we, how can we get you guys up and running and, and, and let's take advantage of this. And, you know, I'm confident that we can and we will. So, yeah, that's, that was our journey. So, Jared, I mean, we've been working for two years together, at least, you know, how have the production outages been? Funny you asked that. So there, there've been production outages. We're lucky in that we have a, we have maintenance windows regularly, we're not, we're not always, always up or always guaranteed up. But production outages, we've had one. And, but then we've had to reach out in like kind of an emergency scenario. I think three times total over the past two years, which is incredible. So yeah, that's, that's something that I know, I feel like we knock on a lot of wood. So anything else? Yes. Sure. I mean, working with working with our Java Java one five app, not just not just anecdotally, not just in a, you know, oh, you know, we're not able to use the latest and the latest, the features of Java in spring. But, but that old code base was just painful to work with. And, and we were not able to, to innovate. And, and, and it, and it took a toll on us, I think, as developers, we weren't happy. You know, we're happy to work together. And we have a great team, but we weren't happy with the code with the, with the application. We are now. It's a pleasure. It really is. So from that perspective, our quality of life has improved greatly, I think. Yeah, I mean, I don't know that I have any metrics necessarily other than the amount of the amount of code that's out there right now, that and the amount of code that goes out every day. But we're doing a lot more with less. I mean, it's, it's, we still have four developers, but, but we used to, we used to pull in so many, so many extra resources to verify our large, you know, monolith deploys. And we, we don't, we don't need to do that anymore. We, we were able to, to do, you know, rapid deployment and, and, and it's very simple verification of smaller services. And it taxes less of the team. So we're just everyone's more productive, I think. But also, we tackle problems from a, from a much different angle now. We don't, we were very quick to push out, you know, simple solutions that would be very complex to build into our, our, you know, enterprise archive. So certainly. Yeah, so we knew, we knew at the time that we had to do something. And, and that we were, we were having production issues, performance issues, and, and, and our customers were noticing. And so we knew we had to throw some amount of money at this thing. We didn't have a lot. But, you know, it, there was no, there was no next tier of hardware for a web logic server that made sense. So yeah, the the clock founders not cheap. You know, open source isn't free. The infrastructure cost is, is, is, you know, significant. But once, once you have the brain, you know, once you have, once you have the foundation, we can scale forever now. And we can scale, you know, with a fixed amount of, you know, resource and support from, from Stark and Wayne. And that's, you know, we're not going to, you know, outgrow ourselves anytime soon. So, so yeah, the, the, the footprint of Cloud Foundry, certainly much, much larger than our web logic and Apache and Oracle servers. But this is our future. And, and it's, it was the, certainly the most cost effective option that we had found for, for something that's going to take us, you know, for as long as we can see into the future, if that makes sense. Yeah. So as far as our Cloud Foundry environment goes, Stark and Wayne is our operations resource. They are, they're monitoring and maintaining and implying patches. You know, we, we touch CF from an app perspective. We're, we're in there working with it all the time. And the most we ever have to reach out, I think on a regular basis is to say, Hey, Kevin, we're going to push five new app instances out. Do we need to bump to another Diego cell or not? But other than that, we don't, we don't touch it. We, we, we push to it. And, and, and these guys are behind the scenes doing all the work. It is, it's, it's, it's using the latest genesis, right? So, yes. Yeah, that was one of the interesting, the interesting dilemmas was, while the Azure hypervisor support was brand new, but, but existed, the, the, the genesis, you know, scripts had to be converted, because this was the first time, I think that you guys were deploying to like open source to Azure. And we had to, you know, cut, I say we, Jeff and Dennis had to convert existing AWS scripts to, to, you know, work with Azure. It wasn't a lot of work that I can recall. But, but yeah, it's all running through, through genesis. Talk to that Amir. So like the question is, is losing all those customers and having like a scale JVM cheaper than your Azure costs? Like we didn't want to play that game. So we have maintained business we've grown. And it is significantly more expensive than running WebLogic JVM on a VMware internally. But it's worth of us because, you know, we don't, we don't want to go out of business. But that's the other option. So I think it was a cost we had to spend. Did you scale the, the, did you, did you, I mean, collocate more than usual, uh, push jobs in order to lower the VM footprint on Azure and lower the cost? Or did you just use CFD payment standard scaling? Kevin, I don't know. I don't know if you even recall the, the, the inception. Business that are, I mean, at, we're at the point now where we're like, why can't we just put everything in the country? So, um, it'll probably get bigger. Yeah, the scripts make it so easy. I think we had 10 in production. Yeah, it's about 10. In, in prod. Cool. Well, thanks for running.