An Interview with Peter Gengler

Principal Software Engineer, Peter Gengler, has been with JumpCloud since the early days. He has essentially helped build the product from the ground up, and has seen the evolution firsthand. So, given his rich history with JumpCloud, I couldn’t pass up the opportunity to sit down with Peter and ask him about what it has been like building a cloud directory service. Below, Peter shares insights on this and more.

First, can you tell us how long have you been a software engineer, and how long have you been at JumpCloud?

Peter: I’ve been a software engineer since 2004. Before that, I was a hardware engineer. You could say I started tinkering around with software when I was about 5 or 6 years old. So, I’ve been involved with software for a long time, but I’ve been a proper engineer for the last 14 years or so. The last 4 of those years have been with JumpCloud.

What insights have you gained about IT admins as you’ve built this core piece of IT infrastructure over the past 4 years?

Peter: As engineers, we invariably create building blocks that we put together to make interesting solutions. However, it’s really interesting to see how an IT admin ends up using JumpCloud.

Often, I’ll get customer reports, and I’ll be really surprised at how someone ended up using the product. For example, some of our customers use the command runner to carry out really interesting tasks in ways we hadn’t really anticipated.

We haven’t prevented their unique uses, but we hadn’t anticipated them either. So it’s cool to see how creative IT admins can get with JumpCloud.

Another aspect I found surprising, well maybe not so surprising in retrospect, was what IT admins actually want to spend their time working on. Back in the day, there was this barrier where most of their work was “moving rocks” so to speak. It was the kind of work that was really mundane, but it had to get done. It’s not all that surprising, but most of them don’t want to spend a majority of their working week on these “moving rocks” type of tasks. Instead, they want to be building with the rocks.

I thought this was really cool because the beautiful thing about JumpCloud is that it takes on the burden of a lot of those mundane tasks, and allows IT admins to spend more time on the work they’re fascinated by.

For example, they can actually have the time to figure out how to make better case management systems, so their employees can get solutions faster, or more time for the work that is on the engineering or creation side as opposed to the mundane “shoveling rocks” side.

So, how do you keep the IT admin in mind as you develop software for one of their core IT management tools?

Peter: Well, I think developing for an IT admin is unique in that they are generally more skilled than a lot of end users that software companies develop for, and it ends up affecting the way we build information. For instance, they’re more interested in the status of stuff. A less technical user might want to know how to change their password whereas an IT admin wants to know things like has the password synced to the places it’s supposed to? Were there errors? If so, what were those errors? etc. IT admins also tend to be savvier around API usage, so we often design the product from the API first, and then our own portals and user interface (UI) are a layer on top of that.

I think the other aspect that is really interesting about building for a sysadmin is the fact that it is their job to essentially be mostly invisible to their employees, customers, and their company.

This really speaks to the uptime requirements, and certain parts of our products have different uptime needs. If an employee can’t immediately change their password it’s not great, but it’s tolerable. If they can’t login to WiFi, that’s a big problem. As a result, we try to isolate the different components of JumpCloud, so we can precisely control the robustness, the resilience and the uptime on those endpoints. Those are the things that IT admins deal with daily and are really concerned about.

What’s been one of the most challenging features to work on, and why was it important?

Peter: I was involved with a project that involved moving away from Tags to Groups. JumpCloud, like a lot of startups, had a number of features that started their life as proof-of-concepts or MVPs (Minimally Viable Product).  Sometimes the feature wanted to do X and another feature wanted to do Y, and there wasn’t always a ton of cohesion or overall thinking about how X and Y were and weren’t related. I don’t think any part of the product made that more clear than Tags.

Tags were how we tried to group people and identities together, and then, put them on applications, systems, networks and such. It started as just systems and users, and it was very focused on that. Then it became rather disparate when it was reused for all of these other components because it was used in slightly different ways with slightly different caveats. For example, you added a RADIUS server to a Tag, but you also added a Tag to an application. Tags had a lot of weird oddities like this. We also learned that IT admins didn’t really think in terms of tagging. They thought in terms of hierarchical groups of members that had relationships with other groups. For example, they might have a group of DevOps engineers that has access to a group of production systems. It was really all the more reason to replace Tags with this Groups concept.

This time around, though, we really didn’t want special cases, and we didn’t want weird behavior. So we used this concept we call an IT Graph that consisted of objects and groups of objects. It maps how your IT resources are connected to each other. This way, if you had a user or a user group, you can connect them to the graph in common patterns, and the same rules will apply. For example, take a group of users. If that group of users is connected to certain applications, adding a user to that group will automatically grant the user access to those applications. If that user is removed from the group and there’s no other path through the graph to the applications, they will no longer have access. That kind of governs all of the behavior with Groups, and that’s the idea of what we wanted to accomplish by moving away from Tags.

Well, the code that was involved permeated a lot of our legacy systems, and it was built across a long duration of time with each part of the code created a tad differently.

But we wanted to stop using Tags and move into this Group’s world; that required us to do things differently.

There were a lot of common things we had to do and few gotchas here and there. For example, making user groups and system groups involved one set of parameters while making groups of RADIUS servers involved another set of elements. They all kind of had different pieces, and because it was so core, there was a lot risk.

This meant we also had to take a different approach in releasing it. We ended up beta testing it more extensively than previous features, and then rolling it out very slowly. When we rolled it out to people, we did it in three different stages where we rolled it out to some of our paid customers. Then we migrated non-paying customers, and then, we just slowly moved everyone over to it. Overall, it was like a 6-month to a year migration. So the long migration coupled with all of the legacy components made this one of the biggest and most difficult projects to work on.

Now, the graph concept in particular is the heart of our directory, and it’s ubiquitous amongst all the things we do.

In addition to all the work you put into the Groups feature, how have you helped bring directory services to the 21st century?

Peter: I think answering that starts with looking at what directory services mean to people, and I think in the heyday of Active Directory (AD), they were sort of a necessary evil. Like, you needed them if you got big enough just from a logistical side of things, but there was a price you paid: you either bought an expensive consultant or you hired specialists who knew about AD.

I think bringing directory services into the 21st century involves making them easier to use, and making them cloud-based—a transformation that has already happened to a lot of technology.

Software companies have taken on the parts of email, for instance, that are complicated and not super relevant to a business’ core mission, and in return, they deliver a solution that’s a lot easier to use. When it comes to IT infrastructure, most organizations don’t care about running an LDAP server and they don’t care about running RADIUS servers and the challenges that come with that—they just care about the end result. A 21st century directory service will take on the burden of configuring, maintaining, and securing directory service components like LDAP and RADIUS infrastructure, so that IT organizations no longer have to. They will have to set up the WiFi or the LDAP resources, but it will be easy to do so.

I think that the other piece of modernizing directory services is bringing this technology up to speed with how work is accomplished now. In the past, the directory service bound a homogenous network that was physically defined in terms of offices. That’s not really the case anymore. These days, a lot of people work remotely, and they have devices and web-based applications they have to access from wherever. Essentially, identity and how that extends has changed a lot. So, to support this new landscape, directory services not only need to support common patterns of what people are used to connecting to, like on-prem file servers, but also the newer IT resources they need to manage access to. I think that’s a big part of what JumpCloud is doing.

It is helping redefine identity so that it isn’t locked down to this narrow definition and then also making directory services easier and ubiquitous for everyone to use.

The last question I have for you is, do you have any advice for IT admins regarding how they can effectively communicate with their software engineers?

Peter: Something to keep in mind is that engineers are about taking a set of inputs and generating predictable results, so we tend to view things as very black and white. For example, here’s what you did, here’s what happened, it worked or it didn’t. That’s what programming is about at the end of the day, and so specificity is key. When someone comes to us and says, “things don’t work”, that’s not a helpful situation. Since IT admins have this technical background, they actually have an opportunity to give more specific information and more specific details around what doesn’t work, what the problems are, what solution they want to see, etc.

In particular, it’s especially helpful if an IT admin just states the problem as opposed to presenting a specific solution they want to see happen. Instead of saying something like, “I want this particular widget,” phrase it like this: “I need a way to do this with my users” or “I need this general thing because…” This makes it easier for software engineers to take that information and say, “Here’s what they really want to solve, and here’s some solutions.” It may be a solution the IT admin thought of, maybe not, but the solution is not nearly as important as the problem that needs to be solved.

If you’ve enjoyed reading insights from one of JumpCloud’s software engineers, consider reading an interview we did with one of our investors, Seth Levine from Foundry Group. Interested in joining Peter in building a cloud-based directory service? Check out our Careers Page for all of the latest positions we’re hiring for. Of course, if you’re more interested in learning how to implement a 21st century directory service, you have a couple of options. Drop us a note, and we’ll promptly get back to you to find out how we can help. Or, register for our weekly introductory webinar to find out more on how JumpCloud Directory-as-a-Service can Make Work Happen^® for everyone in your organization.

Get started with JumpCloud today.