Rob Hruska is an Engineering Director for Hudl in Lincoln, Nebraska. He will be giving a presentation, “A Microservices Architecture that Emphasizes Rapid Development,” at this year’s Heartland Developers Conference (Sept. 7-9). SPN caught up with Hruska at Hudl’s offices in downtown Omaha.
SPN: How’s Hudl doing?
RH: We’re doing pretty well. We’re expanding our global reach this year and pushing more into basketball and soccer, especially in the U.K.
SPN: Is there a specific engineering challenge to that?
RH: There is and there isn’t. We’ve had to put an emphasis lately on internationalizing and localizing our applications, getting them in the languages that are familiar to our customers. It’s really hard to sell a product in the U.K. when it’s blasting American football content at them. The other thing is that video files are large. Transferring files from England to the U.S. or Australia to the U.S.—there’s physics in the way of making that a fast experience. Getting servers set up in those locations has its own set of challenges.
SPN: When did you come on at Hudl and what made you want to join the team?
RH: I joined in May of 2012, so I’ve been here around four and half years. I had been in a company for about eight years before that, my first job out of college. I had a friend from high school that worked at Hudl, and he broached the idea. It was so compelling of an experience—the benefits, the challenges we face. It was super compelling.
SPN: What’s the best part about working at Hudl?
RH: So many good things. Every day is challenge, and it’s always a different challenge. You can’t be complacent here. Every new problem that comes along is an interesting one. That coupled with getting to work with people who are brilliant. We have very talented people here who also really care about what they do. Everybody cares about helping our users and building a good product.
SPN: What’s been the biggest change at Hudl since you’ve been here?
RH: Just the growth of the company, honestly. I think a lot of people would say that. When I started I was somewhere around employee 60. It was still a pretty tight knit group. Everybody knew everybody. Now we’re a larger company attacking a larger market. It’s hard to keep track of everything that’s going on. Communication becomes a challenge.
SPN: Hudl has acquired several companies in recent years. Has that integration been a challenge for your team?
PH: Yeah, they haven’t been easy for sure. It takes a long time to fully integrate. More recently Sportstec has been challenging because they are based in Australia. There’s a huge time difference. Acquisitions aren’t easy, but the benefits have been good.
SPN: Next week you’re going to be speaking on microservices at HDC. For the lay person, explain a bit about the difference between monoliths and microservices.
PH: A few years ago, when someone would load a page on hudl.com, every single thing they did came out of one application. Everyone at Hudl worked on the same code base. All of our servers ran that exact same copy of the code. What that means is that if somebody pushed a bug in that code, it took down the entire site. It meant that code base grew really, really large as we grew.
Back in the day when we had 20-30 people working on that, it was manageable. Now we have 200 people working on that code base. They run into each other a lot if they are all working on the same code. That organizational problem was probably the most compelling problem for us. So instead of the site being one application, we broke up the site into pieces. So now our basketball product is an application of it’s own, and the people working on it are only working on that code base and deploy only that application.
SPN: Talk a little bit about Hudl’s approach to microservices.
PH: Microservices have become kind of a buzzword of recent. Everybody has their own ideas about what microservices should be. You hear the prefix “micro-” and people think very small. A lot of people do embrace that. They break everything up into very small chunks, and they prescribe that everything should do no more than one thing and do it well.
What’s worked for us is to not be as prescriptive about the size of those services. We have some services that are very small, but our basketball product grew quite large. The reason that worked out for us is that when you split things up it’s harder to make a change across them. It actually slows you down. If you can make those changes on the same code base, it makes it faster.
There’s a power that comes with being able to develop on a monolith. That worked really well for us for the first, say, seven years of Hudl’s existence. That pattern of being able to hack on the same code base actually still works in a microservices environment, you just separate it out.
The key is that the architecture we have follows the organizational structure we put on top of it. We put one basketball squad in charge of building that basketball product microservice. Once we split that squad into smaller squads, they started to create new microservices.
One of the big points of my talk is that for us what works well is that we have an architecture that fits well with shifts in our organization structure and doesn’t create tension between the two.
SPN: Do you see a mismatch between organizational structure and software architecture as a big problem for companies?
RH: It’s very contextual. Everyone has their own problems that microservices can solve. For us, it’s development. It’s a way of moving fast, to get our features out to help our players and coaches win. Financial institutions may need microservices for compliance reasons, to segment off their data from the rest of the system. The demands of the company should play a strong role in deciding to move to microservices or not. It shouldn’t be microservices for the sake of microservices.
Register now for Heartland Developers Conference on September 7-9 in La Vista, Nebraska.
HDC and Silicon Prairie News are a service of AIM.