 Thank you so much for the introduction, Brandon. We are so excited to be here and share just a piece of our cloud native journey with you all. As Brandon said, you know, Delta is known for, you know, a lot of things, one of the main things being moving people from place to place. But a lot of people don't know that we have a very, very large IT organization. And today we're going to talk about how we're working towards making IT our competitive advantage for Delta. So today we're going to first introduce ourselves, tell you about who we are and a little bit about Delta. Then we'll get into exactly what sparked our cloud native journey for us at Delta. We have, we leverage a platform as a service, so we'll dive really deep into the team that does that management and also how we were able to implement that platform as a service and what it's meant for the organization today. And then we'll give you some stats about the adoption for that platform as a service, okay? So without any further ado, I'm going to introduce myself. I'm Jasmine James. I'm the manager for the DevOps Center of Excellence at Delta. And our team pretty much enables DevOps at Delta through tooling, best practices, and we're also working on getting the cultural adoption going now that we have a lot of the great tooling in place, including GitLab. So, Chris? Yeah, good afternoon. I'm Chris Bolts and I'm the lead engineer for applications on OpenShift. So if you know Kubernetes, OpenShift is just a little added features plus support. I've also led bringing in a number of the tools and architecting those systems at Delta. So glad to be here. Nice. So a little bit about who we are at Delta. So if you don't know why now, we've pretty much connected people through transportation on planes. We saw over 200 million people every year, primarily in America. Our largest hub is in Atlanta. We're both of us are based. We have over 1,000 daily departures from just that location alone to over 225 destinations. We also have a very, very large employee base, most of which are frontline employees, the flight attendants, gate agents, but 90,000 people. 5,000 of those folks are within IT, enabling our frontline employees through technology and also our customers in technology. So most of us know that the travel landscape has shifted quite a bit over the last 10 to 15 years. And one thing that we're focused on at Delta right now is making sure that we can adapt to just the changing lens, the shift in the travel industry and are able to quickly deploy applications with quality and reliability that is necessary for our mission critical applications. So the one way that we're working on doing that is by leveraging Cloud Native, of course. In our journey, we did a lot of research and decided on leveraging our platform as a service, leveraging a platform as a service, and in our case, that was open shift. So I'm going to throw it over to Chris to talk a little bit about what that team looks like that manages that platform as a service. Thanks, Jasmine. So I want to spend a few minutes talking about the Delta Pass team and how Delta has accomplished creating this product team and really what that means and how we've succeeded doing that. So a part of the Delta Pass team, we've really focused on four different sub-products of the Delta Pass team, and those are developer experience, onboarding process, supported technologies, and platform life cycle. So real quick, developer experience is all about what can we automate for the application teams at Delta to make their life easier. And really what I've seen is with the future of Kubernetes and where it's going in the later versions as operators. So we have created some custom resource definitions where application teams can apply those objects in the higher environments and that kind of thing. So just looks at what are they struggling with and what can we automate. The onboarding process is all about what does it look like from day one to an application running in production. So we really have a personal sandbox where someone day one, they can onboard to OpenShift, they get a couple of gigs of memory, some CPU, they can deploy some sample apps and that kind of thing. And then it really looks at what's dev to production and how does an application move through the environment. And then supported technologies is really all about what containers can we run in production. So it does focus on the build aspects as well, what kind of build agents we use and containers we use to build our tools or our applications. But it's really all about the containers we can run as delta in production. And really what we've done is we've created one GitLab repo for this. And basically all the metadata for our images resides there. So we can basically take that one repo and apply it to a cluster. And then all the delta supported technology images exist there. And then finally we have the platform Lifecycle, which is really dedicated to making sure our clusters are reliable and for our customers and stable. So I primarily focus on developer experience, support technologies and onboarding process. I have a peer that leads up the platform Lifecycle. And really we have infrastructure, application services, security all coming together to make this one product team where we've really worked together very well. And we've seen a ton of success working together, cross collaboration. And it's been really great. So I just wanted to add one thing, like any large company, delta was segmented infrastructure and application development. And what we've done with this delta pass team is really unique for delta and it's really new. Because usually a team is focused within their silo. But by having this cross functionality we've seen a lot of innovation, a lot of us synergies that we've been able to build up. And it's been really, really great I think. So that's important to note. Okay, so now we're gonna go into our tooling. So these are the things that we've chosen to implement at delta to enable dev ops. So I'm just gonna walk through the dev ops and Chris is gonna take us dev and Chris is gonna take us through the ops side. So for our planning phase, right? So with all the work that we're wanting to implement for delta, one of the things that we have to do is plan that work. And we're working on becoming an agile organization, not only from IT standpoint, but from a business standpoint as well. There are a lot of large value streams at delta, so we've chosen to leverage version one. There's probably a lot of Dura users out there and maybe version one is not really well known to a lot of you. But it primarily supports large portfolio planning. So when you have maybe 10 to 15 teams that are working together to deliver a large incremental value, it really plays well into that. So that is what we've chosen to leverage for our planning phase. For coding, we've chosen to, of course, leverage GitLab. And we've been on the journey with GitLab for about three years now. Primarily, we're using it for version control right now. And it's really great because we come from not a modern version control tool. How many of you are familiar with Clearcase? Any familiar with one person, two people? Three, okay. So it's a great tool, but it's really not conducive and it doesn't plug into DevOps methodology as well. So when we brought in GitLab, it was kind of like a culture shock for everyone, it's client servers, what Clearcase is based off of. Now you have this distributed version control within GitLab. So we've been working towards getting adoption going and educating our enterprise on how to use a version control tool like GitLab. So it was a great, great choice for us. On the build phase, we're primarily Java, the development at Delta, a lot of Spring Boot, and all that jazz. So we're leveraging right now Sonotype Nexus for our dependency kind of repository, a centralized dependency repository, and also Gradle and Maven for our build. So we chose Sonotype Nexus because it provides you the ability to have that centralized visibility into what is being leveraged in your organization. In the future, we plan on having some security around what dependencies are being used and where, because as we all know, security is super important these days with all of the vulnerabilities that are floating out there, especially in the open source world. So we want to just make sure that we're informed. So that's what we're using for build, and then of course testing. So testing is, it's not a new thing for Delta, but the level of testing that we're trying to get towards is a new thing for Delta. So starting with test driven development, behavior driven development, we're really working to educate our organization on these new concepts that were not being done previously. So we leveraged SonarCube for our code quality scans and for making sure that teams understand exactly what code quality is and what are some of the things that they can be improving in their code base. And of course, a lot of that is enabled through JUnit tests within their code. So that's the dev side, we'll throw it over to Chris to talk about our ops. Yeah, so for the release, we use ServiceNow for change management incidents and things like that. Deploy, we're using OpenShift. Again, if you're not familiar with OpenShift, it's really just Kubernetes with a couple of extra features and support from Red Hat. For when an application is running in production, we use SumoLogic for logging and we use Dynatrace for monitoring and alerting. So when I look at this slide, I kind of think of two different things. When I kind of think of like onboarding or that kind of thing. So the first one really is looking at it from a holistic picture. And so if I look at this, I see five different teams at Delta that own different products. So I do not own the SumoLogic and Dynatrace tool. We helped bring in GitLab and we did Jenkins and some other things like that. But if an engineer starts at Delta, they have to basically onboard all these different tools, they may have to go through different processes to get onto those tools and that kind of thing. And so that creates complexities internal to the organization. So first off, really just looking at what's the kind of the onboarding for an engineer in your organization or Delta's organization to really make that a lot simpler and easier for the customers. And secondly, if you may be in this approach where you have a lot of tools or secondly, you may be using GitLab and a lot of GitLab's features for sprint planning or maybe it's for your building, your CI portion. Maybe I know they're going to be working on their monitoring and their logging. So if you think about kind of onboarding there, it really does help the holistic view when an engineer comes into your company and what they have to go through to really get up and get going. So yeah, I just wanted to add that a lot of these tools are like fresh at Delta. So we've only had service now, I think, four year and a half. But a lot of the great things that our team is doing is bringing a lot of the automation mindset into these things. Because when you think about cloud native and integrating all of these things and to form out and deliver value, there's a lot of automation that has to go into place like the Sumo Logic and Dynatrace embedding those into OpenShift. So a lot of great work being done there as well. So now that we have a good understanding of tooling, we'll talk about the meat of our talk, which is our cloud journey and how we actually implemented the class. So we established all of that tooling and one of the first decisions that we made in 2017 of Q1, we had to get rid of the waste within the organization. So previously it took, I would say, maybe eight to 10 weeks to get infrastructure provisioned at Delta. So think about all that wait time that a development team is just trying to do stuff. They want to do awesome stuff, but you're waiting on infrastructure. So of course we looked at what platform as a service that we would want to leverage and we did some proof of concepts. So we were in between two providers. We made the choice to go with Red Hat OpenShift. We were a rel shop anyways. For VMs, we leveraged Red Hat as well. So it was a pretty national transition, I would say. So after doing those proof of concepts, we had a great understanding of what it would take to actually implement it at Delta. So that was kind of the result of Q1 and that led us to actually start the implementation in Q4. Yeah, so in December of 2017, we signed a contract with Red Hat to bring OpenShift in as the official pass provider for Delta Airlines. And so that picked off something called the CAP team, which is the container adoption program. And really the objective of that team was to basically take three applications, messaging API, checking API and airport inquiry and get them into production on OpenShift and basically build our clusters side by side. So if you look at that in Q1, basically that was just kind of a project spike that spun up, we called ourselves the CAP team. And really we saw that, hey, there's gonna be a lot of more features that our customers are gonna need when we scale and that kind of thing. And so that kind of rolled into Q2 of 2018, us actually forming the pass team, which is what I've talked about already. So we're like, okay, let's start to actually continue this on. We've got three applications in production. We know there's going to be a lot more coming through the pipeline. And we need to focus on the scale and the reliability of this as well as the automation. In Q2 with the pass team, we did something called a metrics-based process mapping exercise, which is really great. We don't have a slide for that, but it basically takes you through the whole process of from sandbox to production, what is every single step along the way. And then we basically just started to iterate on what has the highest lead time, or who takes the amount of people, does it take 10 people to complete this process? So we focused on just iterating over those and delivering those features to our customers. And then in Q3, you started working on app modernization. Yeah, so out of the CAP team pilot applications, three applications that we work through all the way through production, we established them patterns. So we were able to say that, okay, it takes this amount of time for a team to take a new application that's green-filled all the way from ideation and to deploy it into production. With app modernization, it was a little bit different because in this case, we were trying to modernize applications that existed at Delta. So this meant that there was some refactoring that probably happened because, of course, 10 to 15-year-old application was not really architected with microservices. So we had to break down those monoliths and define a new architecture in order for it to be refactored and to go into OpenShift. So in Q3, we're able to migrate 60 applications and it was very, very long road. But the great thing about migrating all those applications is that that set the foundation for us to continue that modernization journey for other applications at Delta through the established pattern. So it was a really, although daunting, it was a pretty educational undertaking. So in Q4, adoption kind of ramped up for OpenShift. We had pilot application teams, we had 60 applications that were modernized and we had to figure out, okay, how do we support all of this stuff that's in this whole new world separate from our legacy infrastructure side? So we leaned on the community for that. So we established a PAS channel in Slack and the great thing about the Slack channel is that not only is this the PAS team, they have the education and background to support that but we found that those people in those pilot app teams and within those modernized applications, they were actually contributing to the support of newcomers to the platform. So it was a very nice thing to have. And we also established our PAS port, it's conducive to the travel industry, so it's a pretty cool name. But this is where our documentations for all things PAS live. So that onboarding process is established there. Pretty much how a team goes from start to finish through deployment through high level environments like SI. So it was a really cool thing. Move forward to the beginning of this year in Q1 of this year, we were able to establish a lot of automation that made our developers' lives easier. One of the key things I want to highlight about Q1 is certificate management. So within OpenShift you have routes and in the legacy infrastructure world, we would download the certificates and you would have to add them to the key store and then you go through that whole process. So the PAS team was able to deliver an operator and now a manager I believe that will not only allow teams to do this in automated fashion but through code. So basically in their OpenShift configuration, they ask for a cert and then it's supplied. So things like that are some of the features that the PAS team has been able to deliver which ultimately makes our developer experience very easy and developers really want to come to the platform now. Yeah, so I'm really adamant about the PAS community. There's two kind of things internally. It's really great to have inner-source repos and GitLab which we've done but also the PAS community, the PAS channel, we have over 400 people inside that channel now and there's all kinds of questions in that channel and basically our approach really is okay, we want to be able to provide a link to documentation, a link to one of our inner-source repositories with an app example or something like that that demonstrates this is how you do this kind of functionality, right? This is how you apply a certificate to a route. And so one of the things that we're starting to see now that we have over 400 people in that channel is that not only are we getting people from within Delta to answer questions for us, we're actually getting people to contribute to the repos themselves that we've created for application examples, maybe it's a Spring Boot app that connects to Delta's SSO and demonstrates how you do that. And so it really has brought a lot of the app teams together and so that's been really, really awesome. So, but I'm gonna go forward now to 2019, Q2. There was a big initiative, so in 2018 we basically got three pilot apps up on the platform in production and we really rate our applications under four tiers, tier one and two are mission and business critical applications. And that's really what keeps our planes in the skies and our business moving forward. When you check in, if that's down, it really causes airport chaos and that kind of thing. So in Q2 of 2019, we really focused on enabling mission critical applications for the platform. So really this was around blue green deployments, making sure we had more production clusters. There was a lot that went into this, but that was one of the big initiatives in Q2. And then in Q3, we did a lot of automation work or for our supported technologies and that kind of thing. Early on, we only had one cluster where we needed all of our supported technologies. Pretty easy to apply that to that one cluster, okay. So now we've got multiple sandbox environments. We have multiple dev environments and it can grow depending on how centralized or decentralized we go. So we worked on basically the ideas. We want someone to make a git commit and that sparks everything else. So that metadata is applied to all of our clusters and obviously our images are secure and that kind of thing. So that was a lot of the focus in Q3. And finally in Q4, like Jasmine mentioned, in Q1 we implemented something called the SIRT operator, which is just something that is sitting there on that cluster running and when someone basically gives the route an annotation need, it fires off to Venify and grabs a certificate and applies it to your route. Well, that wasn't that great because a couple of things, how about key stores and different things we have to manage. So for the app teams at Delta, doing that was pretty manual. They might have a pipeline that runs to apply that but it was still kind of a slow process of like getting the key store from a team at Delta then applying it and that kind of thing. So what we've been focusing on and it's actually going to production, I believe next week is a SIRT manager. It's a product created from Jetstack and it's really great. But it does routing layer, it does the service layer and Kubernetes as well. It's really awesome. They created a custom resource definition of type certificate. So it does the renewal for you and all of that. So it's a great thing for app teams at Delta. They can have end to end encryption and it's fully automated. There's no passing certificates around or creating pipelines to apply certificates in the higher environments and that kind of thing. So going forward into 2020, right now we're in the sandbox in AWS and we're gonna be running some workloads in the public cloud. So they'll have some of their, if you look at their holistic architectures right now of the applications going out there, some of their workloads run OpenShift on-prem, some of their workloads run on OpenShift on AWS as well as use some AWS native services. So that's kind of going forward into 2020 and who knows what else is gonna be coming, right? How many OpenShift or Kubernetes clusters we'll have. It's pretty exciting. So anything else to add? Well yeah, it's super exciting and I think that it also presents like a new problem for us which is a new challenge, not problem challenge. So now that we're going into the public cloud space, we have to kind of reevaluate our tooling and make sure that everything that we're using is effective within multiple public clouds, right? So we made those selections for core tools but we're kind of having to pivot a little bit and kind of do things a little bit differently with the tools that we have. So how are we going to deploy into the multi-cloud space now? There's a lot of network implications and things like that that we have to think about but I think we're up for the challenge in solving that. So we'll move on to our last portion of our talk today which is just to tell you a little bit about how adoption is going at Delta. So we're gonna start off with our tool usage which is GitLab. So we have just over 2,000 GitLab users and these users are comprised of multiple roles, not just developers. We have an agile development team so pretty much the entire development team including QA, BAs and the developers have access to GitLab and this is just to ensure that the team can, we don't delineate between roles. We want to have a cross-functional team so everyone gets access to GitLab. So there's just over 2,000 users is kind of about half of what our IT organization is the number we're at currently. So we still have a ways to go with getting people onboarded to GitLab. I think one of the biggest challenges that we have with bringing people on is just the education. As I said before, we're going from clear case to GitLab so it's really a huge mind shift. So we're working towards educating the organization so they can make that jump. We'll have just under 8,000 projects in GitLab. So these are not only the cloud native applications which are a piece of these but these are also those applications that are still leveraging legacy infrastructure, maybe traditional CI CD and maybe not a cloud native application. So I'll let you talk about the applications in prod. So yeah, we have 98 applications in production. This is like month old so I know we have over 100 now. We have 2,500 pipelines and over 5,000 containers running inside the environment. So like Jasmine said, the old world is basically VMs with web sphere and a lot of applications that are going from monolith to microservices being ported over into OpenShift and that kind of thing. And so in the old days, a lot of what people would do is they would maybe jump onto a VM, they would change something in production manually and that kind of thing. And now it's like, oh yeah, we're not gonna do that anymore, right? And so what we're gonna do is everything that goes into the higher environments goes through a pipeline. So it starts in Git and it goes through a pipeline. So it's great to see how far we've come over the past couple of years. These 2,500 pipelines that we have are only for our cloud. It's not, they're also creating pipelines for deploying applications to VMs as well. Another thing for the pipelines number is that we take in the approach that everything goes to a pipeline. So even day two operations, if you want to stack trace a heat dump or you want something out of your container that maybe you're not seeing in dinotrace, I don't know, but something the application needs is everything goes through a pipeline and basically that's stored in your Git repo. And so we've had a lot of application teams creating just very common day two pipelines for all of our applications. So it's easy to get up and running. But yeah, it's amazing to see these numbers after a couple of years. It's pretty exciting and we have some really big mission-critical, business-critical applications coming into the platform now. So these numbers are just gonna go up big time over the next year. So yeah. So anyway, I just thank you so much for having us. It's been a pleasure. And come ask us questions. Would feel free to answer anything. Been doing this for a couple of years now. So we'd love to share more. And even learn from you all. If you're doing the same thing or are even further along this journey, come tell us. We want advice. We really want it. So thank you so much for having us and enjoy the rest of the conference.