Season 4 — Episode 2

User research shows that a huge number of our customers were using ServiceNow alongside Puppet Enterprise. It only made sense to teach the tools how to integrate with each other so that users didn't have to switch between them. Molly and Milad join us from Puppet's Integrations team to tell us how they put user experience front and center when building the new extensions.

How can businesses better support DevOps? Don't miss our DevOps Evolution Guide:

DOWNLOAD GUIDE

 

Learn more: 

Transcript

Ben FordHello, everybody, and welcome to today's episode of Pulling the Strings podcast, as always, powered by Puppet. My name is Ben Ford. I'm the ecosystem product manager here at Puppet and I'm pretty active in the community as @benford2k.   We may have talked in the past. Today, we're talking with Molly Erdle and Milard Ghoreishi about a new project that we've got coming out. You may have seen it already. It's the ServiceNow plugin for Puppet, the extension for Puppet, I should probably say. And it's a little bit unlike any of the things that we've built before. So we're going to talk about some of those paradigm shifts. It's really pretty cool. So Molly's been with Puppet for about a year now, and she's led the integrations team through some deployments with ServiceNow and Splunk to do other things. One thing that I know about her is that she's really enjoying working at the kind of company where product management gets to sort of touch that whole process. The whole go to market process where she can influence all the way out to that, where the customer is living. And kind of a personal note about about Molly is that she coaches a lacrosse team and she always like regales us with these stories about how their team is doing and some of the things that they've been up to. And I heard that you had a pretty big win recently, Molly. Do you want to tell us about your team?

Molly ErdleYeah, sure. So happy to be joining the Pulling the Strings podcast today. Yeah. As mentioned, I do coach lacrosse, so I coach both a high school team and then also a club team for high schoolers. So when we're not in the spring, which is the high school season, we'll be playing club lacrosse and we have both gotten some good success in the high school field. I coach Lassiter High School and then our club team, Atlanta Storm. They recently just got the highest ranking in the state of Georgia, which hasn't happened in quite some time for the club that we coach for. So they're getting lots of successes, hoping to place some girls into college, and hopefully they'll be able to then turn around and also coach lacrosse. So it's a fun side hobby.

Ben FordThat's really cool. That sounds like it kind of reinforces the community. Let's people grow from there.

Molly ErdleAbsolutely. That is the goal.

Ben FordSo Milad is a software engineer here. He's been with Puppet for about nine months or so. And an interesting thing about him is that he came from a different background from a lot of our existing software engineers. He didn't really know a lot about Puppet. He came with a different paradigm. And we'll talk about that in a little bit, too. But he's worked with a lot of ServiceNow customers with, like all of the different acronyms, and he's done all kinds of customer engagement to software development and training and everything. And like one of the things about this guy is that he's very, very focused on solving problems for customers. And I think that especially on a small team that is focused on building a solution for our actual customers, solving a problem for our customers, I think that that kind of approach is something that is really, really beneficial. And it's really like, I have to admit, I'm kind of jealous about this because this is a thing that I've always wanted to do. But he's a certified scuba diver, and he told me the other day that he had got a baby leopard shark once, and I'm really curious to hear the rest of that story,

Milad GhoreishiHi, Ben. Thanks for having me. I'm happy to be joining this podcast. Yeah, I actually caught a baby shark once. But it wasn't while scuba diving, I caught that one while wireless fishing by the ocean. But that was really fun. That shark actually bit my shirt while I was letting it go. So it was really fun. And yes, as you said, I'm really passionate about solving a customer's problems. I really like to listen to what they need and understand their desire and translate it to the software. So that's my goal here.

Ben FordThat's such a critical skill to have too. I think it's because the things that people ask for aren't always the things that they need, and getting to understand like what problem they're actually solving so that you can solve that problem and not just the words that they're saying. I think that that's a super important skill to have.

Milad GhoreishiYes, I actually learned this while working with so many customers that actually understanding their needs can be really hard sometimes, but it's really important to understand what exactly they need. And make a product that's user friendly and does what they need it to do. It's really important.

Ben FordRight on. Maybe, Molly, maybe you could tell us how we decided that ServiceNow was a priority. How did we decide that that was the thing that was going to solve our customer problems?

Molly ErdleYeah. So really, it originated with our customer feedback. Obviously at Puppet, we're customer driven, and there's no use in producing products if they're not driven by what customers are looking for. So we got plenty of feedback from customers saying "we already work with ServiceNow," "we already work with Puppet." How do we start to bridge the gap there? And looking at Puppet's user base, we found that roughly 80 percent of Puppet's users also have ServiceNow.

Ben FordOh wow, that's really high.

Molly ErdleSo from that alone, it became really a no brainer as to why we needed to have this integration. And that, in fact, not only did we need to have it, but it needed to happen soon. We saw many customers building their own custom applications that were trying to do exactly the same thing that we've just produced in the two applications we've gone live with. So I'd say just understanding that customer need, we realized very, very quickly that ServiceNow is going to be playing in the ITSM/ITOM space here for a while and Puppet needed to be able to work with that so that our customers have a much easier closed cycle as far as it relates to DevOps and ITSM.

Ben FordI remember before doing some of the roles that I've done now, my first job, here at Puppet, was professional services. And I remember that some of my first engagements was literally building like baby's first ServiceNow attempt, where it was kind of like that single pane of glass where you could point and click and type some values, and then Puppet would go do the things to sort of abstract away the complexity. So I totally see that as a desire. That's pretty cool.

Molly ErdleYeah, absolutely. We saw more and more of our customers were starting to play with what those integrations could look like from a customized solution. So we thought, you know what? ServiceNow obviously has a large market share. We've got that overlap. Why don't we make life a little bit easier for our customers so they don't have to do it themselves? Oh, absolutely.

Ben FordBut I'll admit that I'm not an expert on ServiceNow, but from what I know about it, it focuses on work that's very different from Puppet. Could you sort of explain how that works and how that interacts with Puppet and how you like approach solving a problem with the whole integrated two products?

Molly ErdleYes, absolutely. So yeah, we do live in separate spaces that we see it complementing each other. And previously, there were two, what we would say, siloed operations happening, and that's sort of the action-oriented side versus process-oriented. We see Puppet being able to fill that action space while ServiceNow is really an expert in the process-oriented space. So basically, how we bring that barrier down and then how we tee-up Puppet basically to be that back end piece that's being used to execute the tasks that are embedded in that process-oriented piece. From just a company mission standpoint, I would say those are some of the two biggest differences. I'll pass it to Milard to get into some of where we found the terminology differentiated just from Puppet to ServiceNow and what maybe some of our engineers were used to in that space because we found some differences there, too.

Milad GhoreishiYes, sure. So for ServiceNow and Puppet have different terminologies on some stuff. For example, we have nodes and agents in Puppet, which is CI and assets in ServiceNow. Like change management means something else in Puppet. Catalog means something else in ServiceNow, it means something else in Puppet. So we had to actually get used to this terminology here to be on the same page while creating this application.

Ben FordWhat does CI stand for?

Milad GhoreishiIt's a configuration item.

Ben FordOkay, so a configuration item isn't necessarily limited to just one single node, right? It might encompass several?

Milad GhoreishiIt can be a server, it can be a switch, it can be a router, it can be many things.

Ben FordAnd it can encompass like all the changes that go into making, like deploying one sort of thing? It's a little bit like a pull request on GitHub. You might touch different files or you might only be on one file, but it's all related to that one single thing that you're trying to change or improve. So I mean, translating between these different paradigms has got to be a challenge. I know that even just thinking about it as a user, thining about what my end result is going to be and what code do I need? What sort of challenges are there? From a technical standpoint, what did you run into?

Milad GhoreishiYeah, there were some technical challenges here, too. Like I'm coming from a ServiceNow background, and I had to work back and forth with the team here so we can get into the same page of understanding what we need to do technically for our application. And for example, Puppet groups stuff by no classification, but ServiceNow Group's it by access. So it's all access control in ServiceNow. Now it's all about what users have access to versus what the nodes can do. And also ServiceNow uses an internal code workflow called Update Set and they don't use GitHub or Git in ServiceNow, and that was one of the challenges we had to go into because we use Git and GitHub here at Puppet all the time, and we had to go away from it with this specific applications we were making because it was easier to do with updates in ServiceNow.

Ben FordWhen you say, I think you said the phrase it groups by access instead of by nodes and talking about like what users have access to, do you mean like, maybe somebody who is managing the website might have access to the web server configuration and content on all the nodes, but nothing else on all, all the servers or?

Milad GhoreishiYes, that can be it. ServiceNow access control can be really detailed. You can say this person needs to see only these specific CIs, and it needs to see only these informations about CIs so that we can meet that detailed about the access.

Ben FordSo rather than individuals having like access to an entire server top to bottom. You can have something like a security team that could could lay out a firewall and just control it, etcetera, kind of access rules for all of your nodes. But they don't get to touch all of your applications and then different application teams could have access to the application parts to go on to the nodes that they're running on. But nobody has access top to bottom.

Milad GhoreishiAdmin does.

Ben FordThat's a really interesting model. That's something we've struggled with quite a bit when deploying Puppet infrastructures, like, how do we share that access and how do we interact with different teams so that they can all manage the things that they need to without stomping on each other? We have some things that we're working on and that will be coming out in the near future. But right now, that's something that's real hard to do with Puppet. So I'm glad to hear how this is interacting with ServiceNow, I think that's a big deal with us. And I'm sorry. I think I interrupted what we were talking about, the challenges you working on.

Milad GhoreishiYeah. No worries. Yeah, I can continue with that. The other challenge we had was, so ServiceNow is actually a framework that has a JavaScript on top of it, and it's that the coding arc is different. So as an example, ServiceNow uses some unique global classes. The user can use Google objects of those classes and run methods off of that. So this is very specific to ServiceNow. So our team who are really comfortable with all different languages, we didn't know about this stuff. So they had some learning to do with these new ways that things can be done in ServiceNow.

Ben FordIs that something like how we have global fact? When you're writing Puppet code, you have global facts that anybody can access?

Milad GhoreishiYes, it is. It is the same thing.

Ben FordYeah, OK, I'm following now.

Milad GhoreishiYeah. And also ServiceNow has its own internal packaging tools, and so we have in ServiceNow we have global versus scoped application packaging, which are different, so like some functions or methods work in global, but don't work in scoped application, you have to find some workaround for that, there were some challenges related to those, too, that we have to go through. And I think that was kind of it.

Ben FordI like that idea of having like scoped access. One of the things that happens with Puppet because the Puppet language itself compiles out to a flat catalog, is that even when you're working with scoped objects, they end up being global because they get put into that very flat namespace. And it totally makes sense. Because if one person says Service Apache Running and the other person says Service Apache Stopped like, you can't have both of those states. So it sort of has to go out to that global state. But it does make it real easy for people to stomp on each other.

Milad GhoreishiYes. Yes, exactly. In ServiceNow, the application we built is a scoped application. If we want people to interact with the application from a different scope, we have to actually set that in the application.

Ben FordAnd you can put like a boundary there and you say, like, hey, this is my application and you can't interact with that from another space. So when did we first identify these differences and how did we know that we needed to bring somebody who understood this onto the team?

Molly ErdleYeah, so when we recognized that there was the appetite for the ServiceNow modules, we did start with the Puppet to ServiceNow solutions. So creating modules for the Forge and these modules still exist. They've been successful. We're working to get them to supported and still maintaining those modules. But we started to realize that really the appetite was coming from the ServiceNow store and the ease of use as far as installation and execution via the ServiceNow store was something we wanted to lend ourselves to. Obviously, there are different process and workflow changes that we needed to understand from the ServiceNow side and knew that Milad's expertise in ServiceNow in having consulted with the product before, was something that we needed if we wanted to become even more amicable to ServiceNow and how we want to interact with their interface. So we knew that we needed that familiarity and that while we understood what the product was and we're coming from a Puppet focused perspective, I'd say on what these integrations needed to look like. It was a breath of fresh air to have Milad's perspective on how customers actually have used ServiceNow in the past, how we can create our products to be easily digestible by customers. So we needed some of that. We needed that understanding of how it's actually being used in the field and how we meet that standard and then also exceed it.

Ben FordYeah, the kind of the subject matter expertise and not even just like the book knowledge, but like the field knowledge of actually doing it, is invaluable. I'm curious to know what it felt like coming on board. Milad, did you come here and go, Oh my God, what are we all doing here? This is like totally different.

Milad GhoreishiI actually joined the team and within the second week we started working on the applications and they were actually doing pretty good. But there was some stuff that they needed to know about ServiceNow. Otherwise, like when you go through that ServiceNow certification process, you will have issues if you don't do it the best practice way. So I had to bring those on the table and our team was doing pretty good, but we actually built this application together and we're really happy it's out there for customers to use.

Ben FordYeah, one of the things that I often say about DevOps, like the entire DevOps industry or practice or whatnot, is it's not really about the tools or the processes themselves, but it's more about like having that shared language so that we can all interact and work together and push changes through regardless of who's doing which part of the changes. And it sounds like that's a lot of what you did is sort of like translate some of that language and get us so that we came up with this shared way of of interacting.

Milad GhoreishiYou're absolutely right. I was their translator.

Ben FordMaybe we can sort of step back a little. We've been sort of talking about things at kind of a theoretical standpoint here, like we get to do scoped things, there's global objects, etcetera, but what are some of the concrete things that the ServiceNow integration allows us to do now, that that were difficult with Puppet before? Like how how does this extend in concrete ways the capabilities of Puppet?

Molly ErdleYeah, I'll take this from a high level and then also pass it to Milad if he has anything to add. But really, what it does is it allows for Puppet data to be more accessible and then makes Puppet as as a platform also more accessible. So where I spoke earlier about us wanting to position Puppet as that action engine, really what this does is it allows more and more people to use Puppet as that action engine because you don't actually need to know Puppet code, you have to be familiar with Puppet on that deep level, instead of you are proficient in ServiceNow and have an understanding of how to utilize Puppet, we've been able to do so via the ServiceNow interface, with the spoke specifically here able to trigger those tasks from ServiceNow. And then with the service graph connector, you can just map your data. A one time mapping and then all of your data has now populated into the CMDB. So we see it's mutually beneficial between the two, that you then have a fully populated database and then you're actually able to take action on top of that data, which we see taking action on on bad data as useless. So that's why we wanted to ship both of these in pretty close proximity as far as timelines go so that they're both able to be used in conjunction.

Ben FordNow some of our audience might be in that 20 percent that's using Puppet, but not using ServiceNow. So there are a couple of words in there that maybe weren't familiar, like what's the what's the spoke and what's the service graph?

Milad GhoreishiYeah, I can actually explain that. So we actually ship two applications so far on the ServiceNow store and one is service graph connector for Puppet and the other one is Puppet spoke. These two applications are doing different things, but they're really good to use together. Service Graph Connector imports all the facts related to your data from your Puppet Enterprise to ServiceNow CMDB. And then it can bring even all your custom facts so you can have reached data in CMDB and you can exactly see what you need to do in order to prevent outages and so on. So you have better data in CMDB with Service Graph Connector that you can definitely specify what facts you need to bring in. I'm not going into details into that, but there are so many things you can do with Service Graph Connector. You can say I really want to bring in Windows facts, like Windows machines facts and so on.

Ben FordIt sounds like what the Service Graph Connector is doing is kind of taking all of the insights of Puppet has into your infrastructure, new different nodes and sort of just sharing that with ServiceNow, which also now has all those insights that you can make decisions on.

Milad GhoreishiYes, that's true. And and that's really valuable because when you have more data, you can make better decisions, right? And for Puppet Spoke, what Puppet Spoke does is like we realize there's a gap here. So let me explain to you what ServiceNow user without having this as a Puppet Spoke application specifically needs to do to resolve the issue, right? So let's say a patch needs to be installed on a server, right? Then in ServiceNow, they create a ticket and the ticket will give get assigned to someone and that person needs to create a sub ticket, probably, assign it to a Puppet admin. So Puppet admins can go login to Puppet Enterprise installed that patch using Puppet and then come back to ServiceNow, manually add the result to the subtasks, close it and then the agent can close the main task.

Ben FordThat sounds absolutely miserable. And also, I've seen that process in so many different workflows not just ServiceNow, but everywhere.

Milad GhoreishiBelieve it or not, this is how it works nowadays. I work with so many customers and this is the way they do stuff. That's why as soon as I saw this opportunity, I was like, yes, we should definitely make something to make customer's life a lot easier. Now if they have Puppet Spoke, if they have a ticket created for, let's say, doing the same thing, like installing a patch on a server, they can easily go to ServiceNow portal and submit a form, which is the form can call to install the patch on a machine, they can select the machine they want to install the patch on and submit it. They don't have to do anything else. What that does is send a request to Puppet Enterprise, it automatically does the work and send the results back to ServiceNow. And that's it. They'll be done. And the thing we tried to do, we tried to actually build a lot of these tasks for them out of the box so they know how it's done. So we ship our application with I believe six or seven tasks that they can use. And if they want to create more tasks, it's really easy. We created one single workload that will work with everything, that they can use that with any other tasks and do whatever they want to do. So we try to make it as user friendly as possible. And this will make their lives a lot easier, and it fills the gap that I just mentioned.

Ben FordIt sounds to me like you're saying that configuration management can be a little bit more democratized and like, get it to the people who are actually needing the change rather than having like gated tiers where only like the the Puppet gurus are the ones that get to touch the code or not. So like, if a support tier just needs to get a service like restarted or a mail queue cleared or something like that, they don't need to involve like a whole bunch of experts. They can just like use the tools to make it happen.

Milad GhoreishiExactly. It will be faster. It will use less people to do the work. So it will be cheaper for companies.

Ben FordLike the golden ticket you're talking about here. So working with an external marketplace, I mean, I don't know a whole lot about the ServiceNow marketplace, but it seems like there might be challenges working with different teams and getting things approved and getting it put on to the different marketplaces. And I don't know anything about it so I'm kind of pulling things out of the air here. So what? What was that like?

Molly ErdleYeah, it was a process that we just we learned as we went. And I think there are things that we now know and hindsight's always 20/20 about things that we could have done better, things that went well. I would say that one of the biggest adjustments is as a product manager trying to communicate timelines for something that you're also dependent on an external stakeholder for. So when we wanted to go live with something and try and communicate what that timeline looked like, we had to factor in that you have buffer time that you're working with a large scale company in ServiceNow. They obviously have their plates full on what they're doing with these different programs. And then on top of that, we also had to have beta customers for the Service Graph Connector itself. So it's kind of trying to almost braid these three different threads that were coming in as far as using an external customer for the beta. Working with ServiceNow and then obviously the Puppet component and trying to get those all to align at sometimes with stuff. We've had some great champions, both at where our our beta was conducted and then also with where we had help with ServiceNow. But yeah, I would just say from that timeline perspective that sometimes you're just sitting and waiting and we would fill with other development that our engineers could take a hold of. But it was sometimes just a puzzle of trying to make timelines work for everybody involved.

Ben FordI imagine that there's a lot involved with that. I only saw like some of the things passed by, but it always blew my mind how much like back and forth that there was going on there.

Molly ErdleYes, definitely a lot of back and forth.

Ben FordBut that's cool. I mean, it's like making sure that we're all on the same page and making sure that we get all the right boxes checked and everything. It seems like that leads to a higher quality user experience.

Molly ErdleIt does. Yeah. And then you start to learn a lot more. If you want to create a product for something like ServiceNow, you want to understand their thinking behind what these workflows are. Why certain programs involve a beta, why others don't. What their priorities are. So that's something that we learned as we worked closer and closer with ServiceNow as you start to understand where those priorities are. And we definitely took away some things that, you know, are our best practices in the space that we have started to inject and how we then iterate on our products as far as beta testing goes and things of that nature. So, yeah. While at times it was, you know, twiddling our thumbs a little bit on. All right. Well, we're waiting for feedback or we're waiting for a certification process that was also a great time to reflect on what we want to do as far as our testing and go to market and some of those that we then had the opportunity to dive a little more deeply into.

Ben FordI like that a lot. And I think that probably is a really good note to close on. It sounds like the common thread that I'm hearing through all the things that we're talking about here today is that solving customer problems and then sort of focusing on that user experience and user experience of what it's like to use your tools, that has to be the primary focus. That has to be the thing that we're delivering, regardless of what we do on the backend, regardless of what tool we're building or how it works. And I think that sounds like that's what this whole team has been focusing on what these tools do.

Milad GhoreishiAbsolutely. Our main focus was to make this application as user friendly as possible and also easy to configure. Users can download either spoke and graph connector, and they don't need to do much. We built already everything for them they need. You just need to make connections, aliases and they're good to go. They can just use the application. So that was our main goal because I know how frustrating it is to want to use something and have to go through a lot of set up configuration and stuff to make it work. So our main focus was to make it as easy as possible to be focused.

Ben FordYeah, I know any time I'm going through a read me, it's like each configuration step on its own is not that big of a deal, but it's almost like exponential of like my my stress level of whether I'm doing it right. Definitely. So how do people actually get to the tools so they can try it out?

Milad GhoreishiThey can log into store.servicenow.com and look for Puppet. And those two applications will show up, service graph connectors for Puppet and Puppet spoke. These applications are free if customers have Puppet Enterprise and also a ServiceNow. For spoke, they just need to have ITSN licensing. For graph connector, they need to have ITOM, so that's the only thing other than that it's free to use.

Ben FordAnd do they need any like supporting Puppet modules from the Forge or anything?

Milad GhoreishiThey don't mean anything.

Ben FordThey don't just click it in, install and go. I love it. OK, so what if people have ideas for your feedback or ways that it can be improved in the future? How should they get in touch or share these ideas with you?

Milad GhoreishiYes, we have actually our email address attached to the application in the store. They can definitely send us email and let us know what they need to see in the next version of the application. And we have we have our lists of requests. We can definitely get them. We have actually a lot of things added to the applications. Spoke 1.1 version will be out really soon and we have added so many things to it. So yeah, they can ask for anything they want to use and we can definitely work on it.

Molly ErdleAnd I'll also add there, too, reviews can be left via the ServiceNow store. So that's one forum also to get us feedback in that way. And then additionally, we also use Product Board and have a public portal there to gather not even just ServiceNow related feedback, any feedback as far as what integrations folks like to see with Puppet, so that we have that link as well.

Ben FordSo are either of you active in the community, Slack or social media or if people just want to like bounce ideas off you personally? Are you available?

Molly ErdleAbsolutely. We've done that with a few customers in the past will continue to do so.

Ben FordAnd that, I think, is a wrap for today. Some great information and a great new paradigm and an amazing way to think about Puppet and more user-centric workflows. And honestly, I hope that this is something that we explore more in the future. So once again, thanks for being here on our show and thank you all for listening. Here we are Pulling the Strings podcast, powered by Puppet, and we hope to see you next time.