As they prepare to speak at CF Summit in June, I talked with Garmin’s Jonathan Regehr and James Stueve to catch up on their cloud-native journey and a little bit on what they'll talk about. Their story includes highlights from a Pivotal dojo engagement, pair programming, and pipelines. Here’s a taste of what you’ll hear at their talk at CF Summit.
Q: First, tell me just a tad about yourselves: what’s your background and what do you work on at Garmin?
A: James and I have both been developing software since the late '90s. (Don't call us old!) Mostly Java with a few other languages thrown in. We are founding members of the Garmin Lab, serving as developers/coaches to the teams that come through the lab. James is also tasked with providing the vision for CI/CD and Jonathan is also Garmin's Cloud Foundry SME [Subject Matter Expert] and evangelist.
Q: What made you look into changing how you do software? Where would you say Garmin is on its cloud-native journey?
A: We knew we needed to change how we do software largely because we need to do more with less. For example, our workload continues to grow and our headcount is staying relatively flat. It's not that Garmin won't hire; the competitive landscape makes recruiting difficult. We also need to speed up delivery to bring features to market faster.
We are still near the beginning of our journey. We've learned a lot and we've started to attract interest, both inside and outside of IT. Our lab has had very positive reviews from the teams that have worked there.
Q: What types of applications and/or services are you doing in a cloud-native way? That is, what are the businesses your software is powering?
A: We have a varied suite of apps in Pivotal Cloud Foundry. Most are web apps but we also have queue listener apps. Lots of microservices, some Node, with more on the way. Pivotal Cloud Foundry is powering our customer-facing single sign-on application, lots of marketing micro-sites, and many others.
Q: How did you end up selecting these applications to work on first?
A: Selection came down to timing, dev team availability, and business need. We were also looking for that one, mission-critical app that would serve to vet and build trust in the platform. We found that in our single sign-on application.
Q: Gary Gruver insists that most important first step is getting CI in place. When you were looking at putting CI (and even CD) in place, what systems (e.g., Jenkins, Bamboo, Concourse) were you evaluating which one to choose?
A: We looked at Jenkins, Bamboo, and Concourse. Our most important requirement was a code-driven pipeline. That knocked Bamboo out. We chose Jenkins for a few different reasons – we encourage folks to come hear our talk to find out more!
Q: On that same topic, what are some lessons learned from things that didn’t go, uh, so well?
A: Our initial pipelines violated the DRY principle in that we had many very similar (but not the same) versions all over the place. When we were adding pipelines to new apps it became a bit of a challenge to keep up with which one had the latest pieces.
Q: Finally, I’m always toying with this idea of the “immutable organization": to improve how software is done in large organizations, it’s easiest set up new organization rather than changing the existing one. Since Garmin has a “Labs” group, what’s the approach you’ve taken with setting up an entirely new organization versus “changing from within”…or balancing the two?
A: We are taking the "changing from within" approach. Our IT shop probably isn't as big as others. We are treating our lab as an incubator. We are introducing the labs concepts and seeding new ideas. We are allowing the teams that come through the lab to choose what works best for them. It is a bit of a "throw stuff at the wall and see what sticks" approach. At the same time we are very opinionated about how we work while the teams are in the lab. Our goal is to give them the full labs experience and we hope they will take it with them. We also know they need to make it work for them when they leave the lab.
About the AuthorMore Content by Michael Coté