As the number of services, APIs and projects used within the average enterprise grows, the challenge for the developer and operational staffs of managing all of the above increases right along with it. How should enterprise SREs and DevOps staff tackle the problem of the DevOps experience gap?

This was a RedMonk video, sponsored by Transposit.

Rather listen to this conversation as a podcast?

 

Transcript

Stephen O’Grady: Good morning. Good afternoon. Good evening. I am Stephen O’Grady with RedMonk and I’m joined today by Divanny. Would you like to introduce yourself?

Divanny Lamas: Hi, my name is Divanny Lamas. I’m the CEO of Transposit.

Steve: Awesome. And we’re here today to talk about well — talk about a number of things — but among them is a very changing landscape. Certainly, one of the things that we’ve seen over the past couple of years, frankly, five or ten, is a number of big things arrive on the scene — thinking way back when to open source and later on, software as a service, cloud — has obviously had a huge impact in and of itself. And what that’s led to is this crowded, complicated, fragmented landscape. So before we get into the actual questions, is that a fair summation from your standpoint? Is that something that you’re seeing as well?

Divanny: Yeah, you know, I think a lot of people thought that moving to the cloud was going to simplify their lives, and it certainly had a lot of benefits for organizations. You know, I remember the days where, before you started any project, you had to wait for six, twelve, eighteen months to get the hardware going before you could get started. But, you know, it’s also come with its challenges around integrating that landscape, making sense of that landscape, automating that landscape. And so we’re finding that a lot of organizations, especially some bigger companies that are starting to really make that push into a cloud centric kind of environment are struggling.

Steve: Yeah. No, I think it’s interesting to see the organizations themselves have to shift and adapt, but I think that the wider implication, at least from from our perspective at RedMonk, is this this idea we call the developer experience gap. And the basic idea is very simple, right? Which is that you take this fragmented landscape that we talked about, with all sorts of new services and primitives and APIs and so on available, which on the one hand is great, right? Because there’s a — whatever you need to do, right? There’s a project, a service that will do that for you or help you do that. But on the flip side it just becomes very, very difficult to manage all these individual moving pieces. How do I A) select them just on the most basic level, but then B) integrate them and operate that on a going forward basis? You know, again, is that your experience when you’re talking to your customers? Is that something that you see them struggling with?

Divanny: Totally. I think that there’s kind of this belief that we’ve got all these cloud tools and they’ve all got APIs, right? And so there, we solved it! You can just integrate them yourselves. And everyone seems to discount the fact that there’s still a lot of challenges in that, that you end up with teams that spend a lot of time writing glue code, organizations that are sitting there and they’ve got five different consoles to manage different environments. And at the end of the day, just getting a single view into all of that and understanding of how everything is working together is almost impossible for organizations, especially the ones that are trying to move towards more of like an agile oriented DevOps or platform engineer kind of team structure.

Steve: Yeah. And it’s something that we see interestingly, organizations of all shapes and sizes struggle with, right, in just different ways. So when you talk to customers, obviously, you see different approaches taken. So what’s the solution? Like when you go out and talk to them about, all right, you know, you have all these different tools available, the landscape is fragmented, you have way too many things to sort of essentially integrate, operate and sustain moving forward. How do they fix that? What is your — when you talk to them — what’s your advice?

Divanny: You know, I think that it’s really different for every organization. But the one universal thing that I find is that it doesn’t matter if it’s a small cloud native organization or if it’s a larger company that is going through a transition where they’re moving from an on prem heavy approach to more of a cloud centric approach. There’s a really heavy reliance on institutional knowledge, and so a lot of teams are just sitting there and they’ve got one or two people on the team who happen to have an understanding of everything that’s in place in the back of their heads and everyone goes to them for help. So I usually tell people that step one is just getting your arms around what you’ve got and starting to develop some level of — I know documentation can be a dirty word — but some level of documentation of the different systems and processes and workflows. Just as a base case. Because I find that oftentimes organizations have way more stuff than they even recognize that they have deployed across their organization. And, you hear the dirty word, “Shadow IT” sometimes where, you know, someday someone leaves the organization for one reason or another and you find out that massive parts of your infrastructure have actually been held up by systems that were never actually vetted or integrated or built in. So I tell people, you know, step one is like, just understand what the landscape looks like and really start documenting some of them.

Steve: All right. So we have step one. We’ve talked about the sort of process of documenting and trying to get your arms around the systems — basically what’s in place from an IT standpoint. What’s next? Like once you’ve taken that step one, you know, where do you go from there?

Divanny: You know, I think a really natural next step is to start automating some of that process. And I think that choosing the right places to start is really important. I always tell people to focus on things that have that right intersection of: they’re very time sensitive types of processes. They’re critical. They happen on a regular basis, but also they’re repetitive, right? They’ve got elements that can be automated because not everything is a candidate for 100% automation on day one. One of the things that we find a lot of our customers start with is incident automation. Anything from the process of managing those incidents to communicating information about the different services that might be impacted around those incidents internally, and codifying the process for how to communicate out and share information about those incidents. But, you know, I think it really depends on the organization. We’ve talked to teams where onboarding is really critical because they’re just bringing on so many people. And so having automation around that particular process — what are the systems that people need to have access to? What are the first things that they need to understand before they can get going? So it’s really on an organization by organization basis. But wherever your SRE or ITOps or DevOps team is spending inordinate amounts of time spread across lots of different tools, that’s usually a really good place to start.

Steve: Yeah, it sounds like a great place to start for them and a great place to stop for us. So yeah, this is been great. Divanny, I really appreciate you stopping by.

Divanny: Thanks.

Steve: Cheers!