 Good morning. Thank you for joining us this morning. My name is Jonathan Regear, and this is James Stueve, Stuvy? Stevie, sorry. We both work for Garmin, a little about the company. We were founded in 1989. Our revenues this year are targeting around three billion dollars. We're on the on the scale of a Fortune 100 company, although because our official base is Switzerland, we don't actually show up on the Fortune list. And we make GPS products. You may know us for the Nuvi, which is the car navigation product. However, our first product is actually in an airplane. We build really amazing glass cockpit systems for companies like Cessna, Beechcraft, and Lear. We're also huge in fitness. We make some really awesome watches. We do marine and outdoors as well. We also just released a product called Verb 360. Think something like a GoPro, except you've got two cameras and they're shooting a 360 degree field at all times and you can, if you load the video footage on your phone and you start turning the footage turns with you. So that's a pretty amazing product, your Move GoPro. A little history on our our cloud native journey. So we started our first introduction to Cloud Foundry was in December of 2013 at one of our company Hackathons. We started deploying to Pivotal Web Services and had had a great time there and learned a lot. Knew we needed to, we needed to move down this path. At that point we didn't have any Cloud Foundry foundations. All of our deployments were manual. We were deploying about two times a month. Emergency releases as necessary, but those were kind of... There was a big deal and nobody wanted to do them. So we didn't do a lot of those. Our dev culture was done, man, hey, I got something in the code review and done to our customers, of course, was 60 days later by the time that that software actually made it to production. All our production at that point was VMs and our VMs were vastly over provisioned. We'll talk more about that a little bit later. So here's a little overview of our journey. We've had a couple of Pivotal Dojos. We've made significant time and money investments in automation. We've got production applications now running in Cloud Foundry. We're shooting for Cloud Native and everything we do. Later on we'll talk a little bit about where we are now and Garmin Labs. So I'm gonna start with our first Pivotal Dojo in February 2015. I call this Dojo Lite. We saw Cloud Foundry and we knew we needed to have Cloud Foundry running locally and so we were going to install it very quickly. Thanks in large part to our Pivotal Rep. He rounded up a band of Pivotal Gunslingers and brought them in to help us get that done. And the reason I call this Dojo Lite is because we didn't really do a lot of the prep work that we needed to do. And the slide here with Neo, I chose this picture because yeah, we had a Dojo and if you think about Neo at this point in the movie, he goes, I know Kung Fu. And then he proceeds to have his ass kicked. And that's really what happened to us. A lot of times doing software or doing the hardware we do, building GPS's for aviation, building car GPS's, we're really good at building hardware. We build some really amazing stuff. Our autopilots are second to none and that's a whole other topic. So we have this thing called the Garmin Way which is basically, hey, this is how we do things and it's worked really well for us. Well, when you come to something like Cloud Foundry where you have a team of 600 people building this amazing platform it's a dumb idea not to listen to what they say. So take it from us, if they tell you this is a bad idea, you should install your platform this way. That's a great thing to listen to. So our first platform that we stood up, it was a success. It was certainly not production grade and that is nothing on the platform that was on us on how we employed it. And we learned it was a good time to move ahead down the road from there. So then for real, we started a true dojo with all of the planning that comes with that process in May of 2016. It was an eight week process. The first four weeks we took and we built a production grade Cloud Foundry. That Cloud Foundry is still running today and it runs production applications. The next four weeks of the dojo, we brought four different teams in and the goal was to take their applications and make them cloud native one week at a time and run production. That was a little bit optimistic. We did take production traffic on one of those applications but the other ones weren't quite ready. They are mostly running on production now or running on Cloud Foundry in production now. But again, that was one of those things where Pivotal said you should take a little bit longer when you bring a product or bring a group in. And we were like, no, no, no, we want to expose as many people as we can. So Garmin away again, our bad. So obviously doing Cloud Foundry, you must do automation from my perspective. Yes. It's my joy at Garmin to be kind of responsible from an IT perspective to get us into CI CD and make sure we're doing automation as much as possible. So obviously we want to automate all the things. Jonathan started out in automation with Jenkins jobs that were several Jenkins jobs linked together, which was extremely brittle, kind of hard to maintain, copy, paste reuse. It was kind of a pain. So I said, no, don't do that. It was great. It was a good place to start, but it wasn't a good place to stay. And so I looked at concourse, to be honest with you. And at that time, that was a while ago. Concourse has made leaps and bounds since then, but you needed to install it in Bosch back then. And I did not have anybody who could do that for me. They were all busy doing other things. And so because of that, we really went with Jenkins. It had developer familiarity. People were comfortable with it. And I can reuse existing infrastructure. So we did it down the Jenkins pipeline path with pipeline as code using Jenkins files. I think that was probably the right approach for us at the time. I'm not saying that Jenkins is always going to be the be all end all. But what it did lead us to was what I would call the pipeline Wild Wild West. Everybody was doing their pipeline their way. And people were copying code. There was, we weren't doing dry at all. There was no reuse at all. And there was one project that had five separate Jenkins files that are essentially identical. And then they needed to make a change. Well, good luck because that's five different changes you're going to have to make and affect five different applications from a deployment perspective. So we have instituted what I would call, go ahead and go to the next slide. What I would call pipelines that are opinionated and it's a shared library pipeline. And I can get somebody up and running with that pipeline in maybe five minutes now. So they copy and paste a Jenkins file and make minor JSON config file change and they're deploying to Cloud Foundry in minutes. So that's kind of a big win for us. The developer doesn't have to know Jenkins. He doesn't have to really understand a lot about how to get his app deployed to Cloud Foundry. He just checks in code and it deploys. But one thing automation we've kind of failed at from my perspective is the feedback loop. Garmin has historically had a QA department that did all of our QA testing for us. And as a developer, you threw it over the wall and hey, test this for me. That culture, which is a change that we're working on making, still exists. And so the developers are not used to actually being responsible for their code all the way through to production. So we really, really need to implement automated acceptance testing. It's something that's on our roadmap. We'll be working on it the rest of the summer probably. Get that going. Then we also need automated security analysis because from our perspective, you never know what the volans are and the dependencies you've got. So we'll be doing static analysis on a lot of our stuff and some real-time analysis on things that are key. For us, automation is about failing fast. So I want to talk through a couple of apps that we have in production today. On the left where it says help starts here, that is our support portal. If you have questions or issues with your Garmin products and you are in either the US or the UK, you're going to interact with something that looks a lot like this and you will be interacting with Cloud Foundry. And the interesting thing about that app is that's kind of one of our biggest wins to date. The business was highly involved in the development of the application. We started in August of 2016 with kind of a concept approach and by November we had working code in production. It wasn't live to the end users yet, but it was live to our business and they were loving it. And the true, I would call it the true success story is right before we were going... Don't spill the beans yet. Don't spill the beans yet. Right before we were going to go live, there was a bug. And the director of the support group said, hey, we can't go live with this. He sat down with the developer. Literally five minutes later the developer fixed the code, checked it into the repo and it was deployed to Prod within 15 minutes. So he didn't care. Great, we fixed it. Now he trusted us even more. So I think that was the true success story of the... And we live in December or November or something like that. It's going well. Yeah, we have a great product evangelist for Cloud Foundry and that guy now. Yeah, he loves Cloud Foundry. Yeah. Oops, I didn't talk about the other one here. So the other... On the right side, you're looking at our e-commerce platform. And today, if you look at any product detail pages, like for instance, this watch, or if you look at a category of all our wearables or all our automotive or anything like that, you are also dealing with a group of Cloud Foundry web apps and microservices. This app doesn't look like much, but that's our SSO or single sign-on application. And I don't mean single sign-on for our internal domain. This is single sign-on for all of our customers. I don't remember how many millions of customers we have between Kinect and Fly Garmin and some of our other products, but we have, I think we're 20, 50 million somewhere there. We have a ton of customers. And this application is how every single one of them signs on to Kinect, to buy, to what used to be My Garmin, Garmin Express, Fly Garmin. They all sign into this application. Not only that, but every single time they make a request, that request on the backside, their token is validated against SSO to make sure their token is still valid. So this app takes a ton of traffic. We are also hosting a lot of HTML applications, some of our marketing apps, including Garmin Turning Points and probably Wear This. Probably Wear This is kind of a, it's a cheeky little app that gives you kind of a quick interview and then tells you, hey, this is the Garmin product you might want to put on your wrist. It's kind of a fun one. SSO was one of our first applications to take production traffic. And it was also, they still do VMs and the only reason they do is because we don't have Cloud Foundry in China yet. One thing we learned with SSO was how incredibly over-provisioned we were on the VM side. So we have SSO running in two data centers, we have, I think at the moment, we had at the time this went live approximately 12 VMs per data center running SSO. And the two major reasons for that were Christmas Day and the end of the weekend when everyone uploads their run data. And I think at some point we had a production issue and so they scaled up again to make sure that we'd never have that production issue again. But the problem with doing that on VMs is you just stay that way forever. So Christmas comes once a year. We all know that. We're scaled for that. But hey, we're going to just keep all those VMs around all year long. SSO is running on two Cloud Foundry instances in two data centers in production. I think one might be able to handle the load, but it's a terrible idea to run one instance of anything in Cloud Foundry for the reasons that we're spoken about earlier, the previous presentation. You have instances that drop and come back up, all those sorts of things. And the last two releases, that's how many we have sitting around in Cloud Foundry. We have the current running instance that we have, the previous one in case we need to roll back. Those two instances have autoscalar hooked up to them, but they have never recorded a scaling event. So two instances in two data centers are running, our entire production SSO load. Another huge success story for Cloud Foundry is ERP. You want to talk to that? Yeah, so we have a group of developers that are fairly new Java developers and really don't understand how to get things to production. And literally, we stood them up with probably about 10 ERP services that are actually directly accessing our ERP system, and they were able to take those 10 services and probably from inception to working in Cloud Foundry maybe a week. And these are what I would call junior Java developers. I mean, they're pretty experienced developers from a perspective of ERP, but from a Java perspective, they're all newbies and they don't know really what they're doing. So we hook them up with a Spring Boot app and give them this pipeline and they deployed 10 ERP services that are accessing our ERP system in seven days. I mean, that's pretty impressive for people who don't really know what they're doing. So I think it's a huge success story from that perspective. We would never have been able to do that with VMs. No, not a chance. They would have had to understand how to configure Tomcat or something. They would never have figured that out. You can provision the VMs that fast, I don't think. So think Sesame Street for a minute. Your presentation today is brought to you by the number 1100. We have a lot of other numbers, whether we like, but this is the number for today. I like 42. 42 is a good number. 3.14 is a good number. But this is our number today. Why is this our number? This is the number of deployments we made to production in one month in December of 2016. That's about 50 times a day. Just let that sink in a minute. That would not have been possible without Cloud Foundry, without deployment pipelines, and without Spring. On their own, those three things are amazing, but when you put them together, do you get this kind of magic? I should say that kind of magic. So where are we now? We are definitely here. We built it, and they're coming. People are interested in our platform, and they're constantly asking us for access to the platform. I used this slide in 2015 when we were here presenting, and I followed it up with a joke about cat herding, and that is definitely still true. As it turns out, interest has been amazing. We've got it from inside IT and from outside IT. Many groups are now treating Cloud Foundry as their default deployment destination. I heard the other day, I don't know how many people in the room are familiar with GDPR. Not very many. So quick explanation. The EU has come up with a number of what they call general data protection requirements, and the fines for not being compliant with those requirements are huge, like 4% of your revenue. Not $500 a day or anything like that, but huge revenue percentages. For all of the apps that need to be built inside Garmin to comply with GDPR, they're looking at the standard being you have to have a pipeline, you have to have a Spring Boot App, and you have to deploy it to Cloud Foundry. Did you notice the email that Bobby sent this morning? I didn't. So this morning, as of this morning, I got some statistics from essentially what we are lead architect. He says we now have, as of yesterday, I guess, 400 AIs running in production for Cloud Foundry, which is pretty good from our perspective. We added over a 25% increase in AIs from last month to this month, and we anticipate that growth to just continue moving forward. So the developers have bought in, and we're just getting bigger by then all the time. It's good to stick it for him to send me that this morning. So on the joke of cat herding, to prevent those kinds of issues, we definitely have a you have to be this tall to ride this ride mentality on our team, and as we're onboarding people into Cloud Foundry, we are doing 12-factor. That's really important for us. And configuration has been a really interesting thing for us. So when we started down the Cloud Native path, we started to use config server, and we still do. And the original goal was, hey, all your config is going to be in config server, and you're going to consume all your configuration that way. That has come, and it is gone, and we're now looking at config server being kind of a generic place of, hey, where do our services live? And while that seems like it's kind of backward, if you think about a pipeline deployment, sometimes it's faster to just check code in and let the pipeline run and get your app back to production than it is to go change what's in the config server and let that reload the application. So all of our apps are doing zero downtime deployment, so as we make those config changes and we push, we're not taking outages, and config server is still valuable to us. We still use it a lot, but we've ended up configuring our applications pretty much using properties built into our jars. Logging has been a real fun thing for us. With VM development, we were heavy Splunk users, and all of the logging was dropping to file on our VM systems, and then from there we were pushing into Splunk or Elk or other tools like that. Obviously with Cloud Foundry, you don't have files, so that's a bit of a challenge. We also had to turn all of our logging from line-based logging to JSON-based logging, because when you have a log aggregator that's taking multiple instances of your application, and one of them drops a stack trace that interleaves with other logs, and it's almost impossible to tell what's what. So JSON for logging has been a big deal. If we have time at the end, ask us about the stream data platform. We'll tell you a lot more about how we're logging, because we've got some really cool stuff there that will save that for the end and make sure we have enough time. So from a developer education perspective, though, the problem is, is most of our developers don't really understand what a 12-factor app is. They don't really understand how to do the configuration, and they don't really understand logging, so we're still fighting that on a day-to-day basis, and we're continuing looking for better ways to educate our developers, and part of that is something we will talk about briefly in a minute. So where are we going? So from a build pipeline perspective, what I'll follow in the model of Spring anyway is having an opinionated build pipeline. You get a pipeline out of the box, and it's going to make you have it deployed in non-prod and prod, and if you need something else, then that's up to you to figure it out. But that way, I can get people up to speed really, really quickly. We have automated routing with HA proxy, which sits in front of our cloud foundry. We need to be much more highly automated from a pipeline perspective. We need to add automated acceptance tests and add automated rollbacks today. We don't have any automated rollbacks. It's all manual. And we're in the process of transitioning all our release engineers that used to do all our deploys to us, and they're actually getting to do real work now. So versus pushing buttons. And then last, but not least, we built a lab. We call it Garmin Labs. I would like to think that we got to spend time with our Garmin Labs, but it's not really puppies that we're spending time with. We're spending time building out what I would call our approach for how we're going to do development. And Jonathan, you could probably talk a little bit about that, too. Yeah, so we started out with our first lab. It was BYO. As far as the computing in the lab went, you brought your own machine. Pairing that way didn't work out real well. You know, I have my own set of keyboard shortcuts. I like Adam. He likes VS Code. We debate about that all the time. And that didn't work out so well because, you know, just, hey, this is my machine and you don't feel totally comfortable using the machine if it's not yours, etc. So we have moved on to something much closer to a pivotal lab style where we have single machines with two keyboards, monitors, and mice hooked up. And we have them set so that on Friday afternoon when a team rolls out of the lab, we reimage all those machines, then we grant access to the folks that need it, and then we script loading everything back up. So when Team B walks in Monday morning, they get a machine that looks just like we want it to look. And they can customize it if they want or install whatever they need. But I don't have to worry about any baggage that another team has left on a machine. So our goal with labs is to have teams in for four to six weeks at a time. We are going to be extremely opinionated about what we do with them while they are there and how they work. And then it's up to them when they go back to their regular work areas to take what they want to take. We are going to introduce a bunch of concepts to them and we are not going to tell them what they have to do. But we are hoping that a lot of it will stick to the wall. So we are going to take a throw it out the wall and hope it sticks approach. Kind of like when you are cooking spaghetti, you might want to throw that wall and hope it sticks and then you know it's done. But we are going to be extremely opinionated in the lab so they don't get to do what they want to do in the lab. They have to do it our way in the lab and that's going to allow us to try new things and to experiment in the lab with real world problems and real world applications. So this is kind of, we are a little bit excited about this because this is our culture and our development education approach. We are going to be taking our developers down a path that allows them to see how to do development a different way. So I think that is kind of the key to our success moving forward. If the lab doesn't work, then I guess we will try something else. We also have, we are transforming our physical space as well. Opal this morning mentioned the idea of the cube farm that you kind of smack run into when you walk into most corporations today. I wouldn't call ours dark or dank but I would say there are still way too many walls and we have taken a couple of areas of our IT shop and we have ripped out a lot of walls. We put people in a fairly lab-ish like environment and we are kind of experimenting with which one works the best. So I think in the future you are going to see Garmin having a labs type look throughout our whole floor. And no more gophers popping up. That is right. He is over the wall for me so I am always like trying to chat with him. So I think that covers everything that we had planned to say. We wanted to finish in time for questions. I kind of left some time for that so if you guys have anything you want to ask us, feel free. Of course you can find us later as well. Yeah. Yes we are. Yes. The question is whether we are going to end up using public cloud for these applications. Right now we are on-prem. Our boss would love us to be able to essentially burst to the cloud whenever we need to but obviously that is still something we have to figure out. We will be looking forward to that. And really I think the main challenge we have had there is it is easy to push an app to the public cloud. That is not a hard concept. The trouble is getting the data where it needs to be. We are using gemfire and that has made certain parts of our infrastructure such as SSO very, very HA and we have that running in two data centers. We have other things that are on our DBMS and when you start talking about data centers it is hard. I think there is another question in the front. Yes. Oh that was it. Well we have it. That is what we want to do. We will be automating scanning of all the applications prior to go live so that we won't be pushing products to production that have security vulnerabilities. That is the plan at least. Right now the current solution we are using takes too long to do that as a real-time pipeline so it is a static analysis that we are going to do. The plan is to have something automated soon probably before the end of the year. Interestingly enough the tool that we are using like he mentioned I think it is a good tool but we never heard of sneak before until yesterday so we talked to the sneak guys and that is definitely something we are going to take back to our security team. Hey look we heard of this. Take a look at it and so you may see sneak at Garmin at some time. That is not something I call but it might be there. Any other questions? Well thank you for your time everyone. Thank you guys.