 To get started, I just wanted to give you a chance to introduce yourself, because I think a lot of people know your companies, but there might be people who don't. So, Maddie, why don't you start? Yeah, sure. So, Maddie Meyer, IT manager of CCOM, we've built a tool logistics platform on Cloud Foundry, which is run by SAP Cloud Platform. And so, we're here as an end user representing, I guess, the small and medium-sized businesses using Cloud Foundry. Jay Piscor, director of platform engineering at Dick's Sporting Goods, the best sports company in the world. We're Sporting Goods retailer based out of Pittsburgh. We've just joined the community recently, and we're kind of changing the way we're doing our business from front-end to back-end. Jay Schneipp, I'm the director of product for Liberty Mutual Insurance. We sell insurance, and we've been leveraging Cloud Foundry since 2013. All right, let's talk about why we're here. Why are you using Cloud Foundry? Because there's options. Jay, you want to start with that? Sure. We started using Cloud Foundry back in 2013 because the team that I was on was a small web, we built small web services, and when we were, you know, offered the opportunity to move to a new platform, it seemed that Cloud Foundry was a much better option than our alternative is to move on-prem in a WAS environment that took eight weeks to build, times two because we ran HA, times three because we needed a dev prod and non-prod environment. Sorry, I love interrupting people. That's okay. Was that your only alternative? That was our only alternative at the time, yep. So we brought Cloud Foundry in for a fit-for-purpose solution for ourselves. Got it. So from the Dick's morning goods perspective, we wanted to shift the way we were working. You come up with an idea, and there's that long process of trying to get your hardware in place and do all that thing, all the things like that, and the paperwork that goes along with it, and by the time you've got that done, that idea could be stale and you can't get into production fast enough. We wanted to deliver quality apps to our athletes as fast as possible. So Cloud Foundry allowed us to kind of break down some of those barriers and put more of the productivity in our engineering teams' hands rather than the kind of sit and wait and get to the next step. Now when I think of sporting goods stores, I don't really think about apps and data centers and Cloud Foundry. Why? What are you trying to achieve? We want to be the best. We want to have the best overall user experience. And everyone has a phone or a piece of technology in their hand pretty much at all times, even when they're driving, which is not that great. But when you're doing this stuff, you have to realize that people want that constant feedback, that instant feedback loop, and if you can't give that to them, they're going to go find it somewhere else. So you need to have that engagement. You need to talk about things that your athletes or your customers want when they're working with you because if you're not going to deliver it again, they're going to go somewhere else and find it somewhere else. Actually for us, that instant feedback loop was also one of the major reasons why we switched to Cloud Foundry. We're running a bunch of apps on SAP NEO's Cloud Platform and they didn't deliver this performance and responsiveness that we had hoped for. So we talked to SAP and then they suggested, well, how about you go with Cloud Foundry? So we looked at that, we looked at a couple of other alternatives like running it in VMware or whatever other environments they are. But then we finally decided, no, for us, it's a rather small company. It is better to go with Cloud Foundry because it is easier to use and we don't have to worry about all the infrastructure and stuff underneath. So we really, up to this day, love the CF push and whatever goes along with it. How long does it take you to get started? Well, actually, the first, well, newly built apps just took a couple of days to get really into the first environment and then some more days until you've set up all the pipelines and all that. So after all, I would say two or three weeks, so we got the very first app running and then, of course, migrating all their apps took a couple of months until we got a really steady production base. And that's the first app running in production in three weeks? Yeah, it was pretty much that. Now you've only been doing this for a few months, really. I love the months. Yeah, we're very new to this, but we're also very passionate about it. And that's the thing about Cloud Foundry, the barrier to entry is very small. So you can get up and running very quickly. And I'm lucky, I work with a world-class group. The teammates at the exporting goods are phenomenal and they've been so passionate about what we're doing. I mean, we've been running, I can't even tell you when the first app went out. I know people were going and doing. So, I mean, we were clipping at a pretty aggressive rate right out of the gate. You don't know when the first app was. And you could probably say it's a bad thing for someone who runs the platform to not know what's on the platform, but this is what the whole point was to get it out there, get in the hands of the engineers and our product teams and our great designers and product managers who want to go and build something. So the first app may have been something very small, learning these processes, learning the way the change of life there at the exporting goods has been. I actually want to just kind of talk a little bit about what Jay said and kind of abstracting ourselves as managers and directors from our teams and really allowing our teams to go out and what Cloud Foundry has done is allow our teams to go out and experiment without us needing any handholding or direction. And that's what's been really powerful for us is to just put it out there and let people consume it. Now, when I think of insurances, I don't think of let's just put stuff into people's hands and play with it, right? We've done, you know, because we started in 2013, we've done a lot to secure it and really enable it. So when our developers do have access to it and can go out and do it, it's in a way that it's secure, it's consumable and it's easy to use. Is that something the rest of you found as well? Yeah, and that's the big piece. I mean, you want to break down those cycles of having to constantly be patching and going through, you know, how long does it take me to get an environment set up? And then from there, what does the patching cycle look like? How are we securing this? When you put just standards in with Cloud Foundry that you can just pop up your projects and keep moving forward. Again, cutting out the overhead and just going and doing is a big thing. The other interesting thing, I think that, I think we've said three or four times up here, we don't look at people as technology companies or like Liberty or the exporting goods. I think everyone's a technology company at this point. I think there's just so much going on in the world that just because maybe your core practice may be around insurance, if you don't have the proper technology stack around it to support that, you're going to lose business and clients because again, as I mentioned earlier, they want to be able to pull it up on their phone. They don't want to wait for the mail to come go open that up and then respond. I really agree. For us, it was the same thing. It was kind of tedious to figure out, okay, how many machines do we need and what services and what database is and you don't have to fill out all these forms and that's gone with Cloud Foundry. So it's a lot easier now and the engineers can experiment. However, it was kind of difficult to figure out which services really to use because you have a marketplace now that's filled with so many services depending on the size of your cluster, of course. But now for the engineers to choose the right service and not to overwhelm certain services is what we have found kind of a bit of a challenge. Let's talk about that for a moment. The perspective of the developer that we haven't really talked about yet. What did you learn in bringing developers onto the platform? Sure. So when we first started really expanding the usage beyond our small team into the entire development environment, we found that we couldn't, as the platform engineers, we couldn't guess and determine how another user or another developer would consume it. And we did a lot of user research. We were lucky to partner with Pivotal on that and really start to ask and understand where the blockers were for these teams. You know, as an enterprise company with almost 50,000 people and almost 5,000 IT employees, we had to use our enterprise systems like identity, like DNS, and some of our security tools. So we didn't have the opportunity to use things that came out of the marketplaces easily. So for us, part of the developer experience wasn't just offering Cloud Foundry. It was partnering with what was traditionally siloed organizations to bring to bear those other technologies. And so for us, it's again asking, talking, breaking down those barriers, and obviously agile methodologies have helped us a lot there to bring everything a developer needs end-to-end to deploy their application. And it's more than just Cloud Foundry, its identity, it's their vanity URLs and the security that goes behind it. Sure. So from onboarding early on, again, we're young and it's been 11 months, but I think the thing is the ability to go out and kind of do whatever our engineers want to do and managing that, the expectation. Going from they can go real-time and set up an environment and start testing something that they were thinking about, and then they have all these other tools that are available to them. It's kind of managing the expectations of what is Toolset 1.0 going to be to move the technology forward. You're kind of drinking from a fire hose right when you get there because usually you're waiting for that long period so you can think through things, but if you can move, you have to make quicker decisions. What was it like before you started? Were developers just sitting there depressed? We did have one of my favorite examples is one of my buddies, Brian. He was a very quiet engineer. Always had his headphones in, always had his sunglasses on, walking in and out of the building. He's very talented and he's a funny guy and I always used to talk to him and I was probably pretty annoying to him most days, but he went and did a lab's engagement with Pivotal and worked as an impairing, extreme programming, and really what Brian wanted to do is he wanted to be an engineer. He didn't want to be an admin of another third-party tool. He wanted to go out and do engineering. So Brian comes back after six months like a completely different human being, like the one I knew he could. I actually use him as an example when some of the students come in that we talked to because I mean we're on a big, my shameless plug, we're on a big hiring bonanza right now. So go check us out, check out Brooks at DSG Tech and come work for us. It's not a better time than now. Now I have to give everybody else a chance to block too. We'll do that in context. I saw an opportunity. I had to take it. Sports, hustle, you know. Aggressiveness. What you mentioned for us, it was key when hiring people to say, hey, we run on Cloud Foundry. You have the opportunity to try things out. It doesn't take long to get new things started. And that was really like a differentiating factor towards other companies that were also recruiting. Yeah, absolutely. I mean, when you get that opportunity to say like, we're bringing you in to come and be an engineer and do what you do. And we're not going to put this big, all these guide rails around you. We want to see what you can create with our team, because you're going to go into this balance team. You're going to have the ability to think through problems and deliver as fast as possible. I think that is a big recruiting tool. Yeah, absolutely. So with Cloud Foundry, you can even make small parts for the logistics company. Interesting, isn't it? Yeah, absolutely. And that really is a big challenge for us. It's a small company. You can't really play around much. You have to focus on getting your projects through and delivering to your customer, because the customer is very close, usually. And so for us, it's hard to find people that can understand the domain, get a lot of stuff done, and not get stuck into all the myriads of, let's say, infrastructure ops and all that. And we can achieve that using Cloud Foundry. Now, Brian is obviously really happy. He's turned his life around. Do you have any examples? What kind of challenges that you run into or what are the issues you run into where you developers said, well, maybe I prefer the old way? I think one of the biggest challenges is when you do an overall cultural shift like we did at Dick's Sporting Goods is people are used to their everyday kind of schedules. They know when they come in, they go to their desk, they do certain things, they know when they go and get their coffee, that type of thing. When you open up the space and there's a lot more communication and a lot more people are dependent more on each other to get things done. I think that creates a little bit of fear because anything you want to perform for your teammate, you want to make sure that you're there and you're helping them move the ball forward. But you also have your set schedule from what you were doing before. So I think one of the challenges was just figuring out how we were going to work together in this new collaborative structure. And there's some ramp to that, but one of the great things is like just hearing the buzz now around the office about how passionate our teams are about what they're building. And it's because they're collaborating not just within their own team, but they're kind of cross-pollinated around the room just talking through ideas. Yeah, I think for us it's also the, you know, again I talked a little bit about kind of breaking down the silos and getting the teams to talk, which is an amazing thing once it starts to happen and finding ways to influence and drive the same behaviors across the organization. Things like change management and even some of the security tools that we use, really challenging audit to come with us rather than to audit us at the end, learn and understand what we're doing right now, how we're implementing either these new controls or these new policies so that when it comes time to audit they understand it and we're not, you know, waiting until the end. That's been actually really powerful, especially as we brought in our cloud providers as well. Do you find the same thing about it? Well, for us the challenge in the beginning was we knew how the system worked before and what like the security procedures were and all that. And now there was this new platform, Cloud Foundry, and we didn't have any experience with it. So some were actually quite afraid of what's going to happen. Does it have the same levels? What are the procedures to go through if something happens and so on and so forth? So there was a bit of a fear, but over time of course we overcome this and now we're quite happy with it. You guys talked about the culture change. I don't want to be labored at too much because we talk about that all the time, but that is difficult to manage. Do you have any tips for people what worked for you? I think for us is to go in it with an open mind. I always say to people the intent is positive. Don't expect that people are being negative or standoffish on purpose. Everyone has positive intent when they go into a meeting. Some are just being either protective of their teams or protective of the tools that they operate. So really think about it from the other person's perspective and just maintain that positivity going into it. I think patience is a big key and your ability to kind of listen to the people that you're working with, your teammates and hear what the feedback is about the area. So you have in your mind, you set it up a certain way and it may have worked for another company that you work with, but you may have to adjust things that are different in your office. So just listening and trying to understand the other person's situation. Working with German engineers? Yeah, working with German engineers, but I think it's not much different though. Got it. You brought up, you work with SAP. I think both of you work with peer-vault. Any of you consider just building your own and not working with a vendor? So we started, we gave it a shot. We were pretty aggressive again out of the gate. We wanted to kind of go and do. And I'm not going to say we stumbled, but we needed that support, that next level of like, here's how we do things and them being able to bring their expertise, not just from a technology standpoint, but a way of working. I think that was what really helped us. I mean, we've gotten really organized around our rituals and things that, you know, pivotal brought to the table. I know we can go out and read a book and say, you know, this is how agile works and things like that, but having someone to come in and pair with you and kind of move you through the process was really big for us. But we did give it a shot early on, but having the guard rails there were actually very important to us. What happened when you gave it a shot? I mean, we got CFL. I mean, it was working in theory. So... But there's some things that you need to talk about, the things you need to go through, scaling. And my team was all net new. We had brought people in from different parts of the company, all working on completely different items. One of the guys here, he's in the front row. He was in security. He was doing nothing as far as like hands-on keyboard technology. He's come a ton a long way. I mean, we've just had to continuously move people into these new positions and watch them grow, which has been pretty awesome. We started with another vendor prior to Pivotal, because we started in 2013. Who was that vendor? Staccato. Been a while, yeah. So we moved to Pivotal in 2015. And really, there was a dramatic change. And, you know, like Jayce talked about that cultural shift and understanding, you know, how we can improve the developer experience through user testing and user research and simply asking the question, what problems are you having and then bringing the right teams in together to help solve them. And knowing that it was beyond our own organization and we had to start partnering with others. Actually, we did not try to build up our own infrastructure and that is very simple. We just didn't have to know how the resources are at the time to do so. But actually, I want to kind of pick up on Abby's kayak metaphor because I really like that. Because in the last two days or so, we've been talking mostly about, well, that kayak that looks pretty much like a cruise ship to me. Yes, they're rapids. We're talking about large enterprises, lots of people, shiny things, big apps and so on and so forth. But think about the rapids when you sit in a little nutshell. So you need a partner, a big partner to lean on to and someone that navigates you through those rapids. And this is why we have chosen SAP because, A, they're close by and B, they had all the resources, the learning, the people and so on and so forth. And the knowledge, most likely. To go with that and to have a strong partner helping us navigate through that and I think that was, well, after all a good choice. And with close by, you mean the few towns over? Yeah, a few towns over. Okay, if it is everything. Time for the other vendors to open up some office in southern Germany. Actually, I think pretty much everyone has a partner but for us it was a good choice and there was one other reason than being close by and that is if you work with a lot of the big enterprise systems such as the ERP system from SAP you need the right connectors and so if you have a platform that already offers quite a variety of connectivity of connectors then you can start with that and don't have to go through the hassle of building or trying to figure out protocols for that stuff. And we don't often talk about Cloud Foundry in the context of small and medium businesses but it seems to be changing a little bit. Yeah, and I really hope that's going to change because the simplicity that Cloud Foundry brings to the table is really something that I see big value especially for medium businesses in. I mean, yes, the scalability and all that stuff we've talked about in the last couple of days is something for large enterprises to leverage the scalability and being ready when a big wave hits their systems is an awesome thing but at the same time they can go with a smaller environment and still run all their applications on it so to me it's quite a good platform for those two. The problems are all the same regardless of what size you are. I mean, you called out we don't know what we needed to buy when it came to hardware. Either you're overbought or you're underbought and then you're trying to scramble to figure out what to do if you're underbought. So with having the ability to scale on demand that's a big thing from not only a budgetary perspective because then you can save that money throughout the year and then you can write size whenever you need to. We've been so positive. Let's go the other way. What's your biggest misstep in getting started or using Cloud Foundry since you got started? What went wrong? I would say not necessarily what went wrong but what's been hard for us is definitely the idea of at an enterprise level not being able to leverage and I talked about this a little bit already but those marketplace services and really we've had to abstract the CLI from our developers except for in the development environment because of the inability to really get granular from a rollback model standpoint so having to put those pieces in it that we have to now run and manage so we've abstracted it into a web portal that's difficult because now that's a hurdle that we need to overcome every time we move forward with a new version and so I guess in the interest of thinking about Eric's presentation yesterday I would love to see a more fine-grained rollback model put into the platform, that would be my ask your developers didn't revolt when you took the CLI away we never gave it to them so they don't even know they don't know what they're missing I think our opportunities so far have been around becoming a learning company so like going from always trying to be perfect to understanding that we're not going to be perfect I mean we've had to redo some of our foundations two or three times just basically because our first idea we didn't like once it was done but the beauty in using something like this is we can repay whenever we want and make those tweaks and adjustments I think the biggest thing was going a little bit easier on ourselves me specifically, I'm one of those guys we've got to get this done right the first time where we're really learning that everything that we're doing we're getting better each and every time we roll something out I think that's been the biggest challenge or opportunity that we've had for us the biggest challenge was really the security part and trying to convince the operators and the classic IT department that what we do is to secure in as good as what they do so that was a challenge really I can imagine an insurance company that it continues to be a challenge and again that's why I talk about bringing your risk management team along with you and you need to change the way we do things like risk management change management how we define our security policies and standards it's no longer that you're going to put something out on a wiki and expect our developers are going to go read that we take on responsibility of enforcing a lot of that through our pipelines, through our development practices so it's not even something we have to think about anymore running short on time here so you've got the whole community here what would you like them to do what do you need from the community besides coming to work for you I know that well I need that too so we'll get to that I think from my perspective it's just keep being proactive and doing what you're doing we're seeing great things just from yesterday's keynote of how cloud foundry is growing they're not waiting back to see how things are going to shift they're actually going out there and looking at what the new tool sets that are available and trying to bring them in and continuously build the platform out to be stronger for us it's bringing the word about cloud foundry and also into Asia China is an important market for us where we don't see so much cloud foundry activity yet and also small and medium businesses we're in so I'll put another plug in for the role-based access control but then I also think scalability I think as we start to grow our foundations and we're running in three internal data centers as well as three regions in AWS we sometimes don't know how much more we can push a single foundation before we need to add another so really understanding kind of what our load looks like across the board do you think that in five years you'll still be using cloud foundry I think so all of you you're smiling he's like I'm going to Microsoft I think it'll be a flavor of cloud foundry I don't think we'll be talking about it the same way as we do now so I think it'll just be the community will grow and move into a different direction but it'll just be we'll be talking about something much different in the shift but I'm sure cloud foundry will be involved in that all right you hiring? yes we are hiring you have a URL? look us up online it's hard to find you we're launching a new website on cloud foundry but there are different reasons I wanted to fly you gotta get a hashtag we are hiring across the board in IT and it's tech at liberty and Dix is not hiring we're hiring everywhere come join us thank you guys