Is developer relations forgetting the people who run software in production?


Mark Lavi and Luke Kilpatrick

Mark Lavi and Luke Kilpatrick

Is developer relations forgetting the people who run software in production?

In a world of “you wrote it, you run it” and where devops people are writing more code to automate business, it’s important to question whether your developer relations programme is catering to both the developers and the operators of software.

Join Luke and Mark from Nutanix as they describe how they’ve incorporated operators into their strategy.



Luke: My name is Luke Kilpatrick. Thanks for the nice intro there. And we’ve got an interesting talk. This came to us actually at a Future Developer Summit put on by SlashData in Menlo Park in September. And we’ve been talking a lot about developers and talking to devs and getting developers on your platform, but we’ve kind of forgotten somebody.

It’s great if you have a developer, but what happens if your code never gets to production? And we found that more and more folks, it is not easy for these folks because being an infrastructure company at Nutanix, we found that operators are actually the people that are most familiar with our stuff and trying to reach developers as an infrastructure company has some challenges.

What is an operator?

So, what’s an operator? Let’s just quickly define what this is. An operator is someone that’s managing servers, hardware infrastructure, and actually getting applications running and operating productions. These are site reliability engineers, your IT admins, basically, anybody that’s not writing code day in and day out that’s in an IT organization is usually responsible for running your stuff.

So, and who’s heard of this before? “You build it, you run it.” Okay. We’ve got a couple of hands out there. Back in 2006, this basically became a manifesto at Amazon. If you’re a developer team, if you build something, you have to run it.

And that totally changed the world of the enterprise world on its head because before that developer would make an application, you’d run it on your test server, and then you just throw it over and now it’s an Ops problem. And that’s with the cloud and with the way that Amazon’s worked, this is totally changing and it’s changing more.

So, we got a couple of stories here for you today. I’m going to tell you a story about how we screwed up at Atlassian. And then we’re going to tell a story about how we screwed up at Nutanix. Because you know, it’s more fun watching the car wrecks than it is hearing about how great success we have. And then we’re going to talk a little about why we’ve transitioned from being a developer marketing team to a DevOps marketing team and why that’s been really important for us because our whole world is transitioning to DevOps, and we’ll go into a little bit more about how this is going to change probably everybody’s program in the long run.

No matter if you’re selling a developer tool or building an API or doing a marketplace, operations is going to become tighter and tighter into your developer community so you should be thinking about them. So, I’m going to do a quick little overview. You know, as-a-service is basically sometimes, in many places, a four-letter word or you have infrastructure servers, platform-as-a-service, and these build out in different ways.

So, the old school way is on-prem, everybody on the operation team owns it completely and you know, it’s all your IT’s problem. To SaaS, where you may not even have an IT organization and your development team is completely charged with running everything as-a-service. And most companies are going to have a mix of these things depending on what they’re doing. So, if you’re building a serverless app in a PaaS platform like Heroku or Amazon.

If you’re infrastructure-as-a-service, sometimes that’s like AWS, where they’ve taken everything from the virtual machine on up is your problem, virtual machine on down is their problem. So, there’s just different operational ways. So, when you’re going to this system, there’s a lot of problems. There’s a lot of different things.

Atlassian’s journey to the cloud

So, I worked for a little company called Atlassian. Who here’s familiar with Atlassian? Yay. Okay. We got lots of hands. See. Their marketing works.

Who’s sworn at Jira ticket before? They came up with this lovely idea of being, you know, Jira and Confluence are big Java monolithic server products that worked really well. People would download them and install them and buy them. It was great. But you know what? A lot of startups and a lot of smaller companies, they don’t have an infrastructure or an Ops person to start up a server.

So, they thought, well, and the whole world’s going to cloud, so let’s go release Jira and Confluence as a SaaS product in the cloud. And this is great because now you can pay 10 bucks and get your teams there and you’ve got Jira and Confluence working for you. The problem is that almost something like 80% of our Jira installs have a plugin installed or something that modifies the core Jira experience to be more customized for that business.

In about 2014, we had about 500 different, we call them plugins in our marketplace, and the plugin was great because you just downloaded it and you installed it in your server and you’re ready to rock and roll. You took care of the upgrades, you know, all your customer’s problem. The developer that developed the plugin developed it once, hosted it on Atlassian’s servers marketplace, customers downloaded, all good.

And then we did cloud. Now, the problem with cloud is who here wants a third-party installing stuff in a cloud SaaS platform? Not secure and doesn’t work well… And as a stopgap to kind of make this happen, Atlassian actually took the 20 most popular plugins and installed them into everybody’s cloud instance, whether you needed them or not.

And it kind of made it work, sort of, but they were multi-tenant and there was a lot of problems. So, to make it actually work long-term, we came out with a product called Atlassian Connect, which was a REST API that allowed you to run a server somewhere connecting back to your Jira thing. And, of course, when we released this API, it was well-documented, had full coverage, and was perfect in every way, shape, and form.

Yeah, no. If you believe that, I’m going to tell you how easy it is to leave the European Union. So, we had a lot of problems. We didn’t have functionality. It just was really tough. And we had a whole bunch of developers that built products that didn’t have any idea how to do operations because when you have a SaaS product, now you’re doing a SaaS plugin, and now you have to set up a server, you have to set it up to be multi-tenanted, you have to do all your own releases.

So, everybody is constantly upgrading on your own system. And you have a relationship back and forth with a customer rather than just throwing it over the wall. So, how did we solve this? It was painful. This took almost three years to five years to solve where we actually started doing what we originally called Connect Weeks, where we brought all our ops people and our developers from Sydney.

Most of our plugin people were in Europe, so we all got together in a hotel, about 100 of us in Amsterdam and we basically spent a week working together teaching our developers how to do Ops and them teaching us how to actually do an API that they could use. And it really created the sense of empathy that let us really build a community. And these Connect Week app weeks were so successful that we actually started doing them once a quarter.

And doing them small, but 100 people is our max and we do them around the world to try and couple up most of the vendors, but a lot of it was teaching our developers how to do operations. And it’s a trend that’s happening more and more in the industry. And so, give a little more detail on app week and what happened with Atlassian. Actually, I’ve got a chapter on it in the Developer Essentials Marketing Guide.

Who here has seen this book before? Okay. A couple. SlashData put it out, they’re on the second edition. We also have a second chapter that’s about what we’ve been up to the last year at starting up a developer relations org from scratch at Nutanix. But I’m going to let Mark tell you a little bit about what we’ve been doing there. Okay.

Bringing DevRel to Nutanix

Mark: Great. So, thank you, Luke. So, Luke detailed the journey that Atlassian took to become a SaaS company. How their developers became DevOps. And now, let’s talk about how I got to be in front of you right now. As Steve told us at the early thing, we try to look a little professional.

I’ve been doing this since DevOps and excuse me…developer relations is more than 20 years old. We go back to Apple and Guy Kawasaki, right? So, Netscape very much where I landed as a technology evangelist for JavaScript and LDAP really picked up from where Apple and Sun and Oracle technology networks and other things had done at that point in IBM, incredible developer programs, but never connected to the web until that time.

And everything that we take for just complete convenience today, you know, Quora, Reddit, and such Stack Overflow, we helped pioneer a lot of these things back in those days, but now we have a global audience, global advocacy on the skill that is instant and that is just wonderful today.

So, what we did basically was drive forward a lot of the web practices at Netscape and I left DevRel after that to go back to become an operations manager and engineering manager for a number of startups in Silicon Valley. Phil, our predecessor on stage, I actually competed with him as the operations manager for Kaazing against Pusher.

So, lots of interesting things, but ultimately, I ended up at a startup after being a DevOps manager, a startup that tried to advance DevOps modeling applications and their operations together. The infrastructure operations and application topology called Calm, Cloud Application Lifecycle Management. And in 2016, Nutanix acquired us.

And Nutanix, if you’re not familiar with it is over a billion-dollar revenue cloud infrastructure company today. So, what happened in 2016 when Calm became part of this larger organization, when a DevOps team became a DevOps product team became part of an infrastructure team? And the truth is their primary audience at Nutanix was those data center operators, those IT teams, and not the developers, but there was a lot of interest in that audience for how to do automation, how to get the developers closer to the servers, how to get these SaaS and PaaS-like experiences going on for all of these traditional IT folks.

And all of Nutanix was very excited as well and said, “Let’s just add DevOps to everything.” But for our customers and for Nutanix itself, our sales and our marketing, you can’t just add DevOps. We failed a lot. There was a lot of DevOps hype, a lot of mistakes, a lot of frustration, quite frankly, because you can’t sell DevOps.

It’s really a cultural outcome of trying to bring people together to help deliver value to your customers as quickly as possible, whether that’s purely technology or whether that’s purely relationships or whether that’s a mix of everything. That’s the cultural definition of DevOps that is relevant to each and every customer’s experience. Everybody does it differently.

So, just as we define DevRel differently from company to company, same thing with DevOps. So, what we ultimately found out is that we needed to go through our DevOps journey at Nutanix to understand these personas. And these personas meant talking to developers, understanding the QA teams, understanding the management, understanding their problems and growing empathetic for them so that we can bring the right solutions to them to make the pain go out of their day.

Have their weekends back and such. So, that was the beginning of an investment. And really in 2018, Luke was hired to create developer marketing. So, in 2018, what we found out was that we didn’t have a great destination for developers to come and learn about the platform.

So, the first thing was make a valuable destination for the developers to begin onboarding, and start creating labs and taking those out on the road and start doing hackathons. And Luke, you want to tell us about hackathons?

Hackathons don’t work for everyone

Luke: So, who here has done hackathons? Hackathons are the marketing solution to talk to developers, right? We just, “Hey, we need to talk to developers. Let’s just go do a hackathon.” And it will work. We learned that infrastructure developers are not really good at hackathons. Having Alexa talk to your data center looks great on stage saying, “Alexa, make a VM.” It’s great, but that never actually goes into production because all you need is one guy saying the wrong thing and you know, now you have an outage and you know, you’re back down to 1/9 rather than 5, and it’s a mess.

Hackathons are really good I have found for internal. In your own company, it’s great to get innovation to do stuff, but an external hackathon, you have to have a very, very narrow set of really good parameters to get value out of it because so little of code that’s built in hackathons actually gets there. And we found that our customers, the ones that participate, while they had fun, they didn’t get enough value out of it.

Plus, our API…who here’s API’s perfect? Okay, good. No hands on that. Our API has some pretty big gaps in it and the hackathon just kind of shined a big spotlight on it on our largest conference, user conference, of the year. So, just as general advice, hackathons, make sure you really, really know the exact use case that a hackathon is going to be used for rather than just using that as the general, “Hey, we need developers, let’s go let them code and work for free.”

So, that’s my little rant on hackathons.

Bringing DevOps people into the DevRel picture

Mark: So, we were starting this journey and I can’t say we were fully successful or fully failed, it was a mix of all these things. It was experience, gaining experience, and trying to bring that feedback back into the organization so that we can improve. That’s all we can do. Make improvements every day. So, let’s fast forward a little bit more. Nutanix as a whole was experienced huge change in the industry as well, right?

The public cloud was the most important and the traditional on-prem infrastructure company, which Nutanix is not, but firmly was routed in that market was facing challenges because all of our customers, now we wanted not only automation but we wanted to go to the public cloud.

So, we had to help do that. And not only that, we had customers that had public cloud sticker shock, and were trying to come back. And worst of all, they were only lifting and shifting. And if you’re not familiar with this term, it’s really moved your disks, your VM disk from on-prem to the public cloud, find it too expensive and lift and shift it back. The truth is you never have managed how to run your business properly, all you’ve done is move binaries back and forth.

And this is not the way you get a cloud operational experience. And again, remember, we’re trying to help imbue operations into development. So, IT operators will just lift and shift and avoid working with the developers to synthesize their workloads and manage the business properly. This is a huge DevOps gap, a DevOps need. So, what we found is that the Nutanix platform also had grown very much so that we could reach developers and DBAs and start to go up the stack to give you PaaS-like experiences not just IaaS-like experiences on this platform.

And it did not matter whether it was delivered on prem or off prem. We helped people go to multiple clouds and we helped them go hybrid as well. So, there’s a very unique value proposition that finally happened because speaking to developers wasn’t the right thing. What happened in this past year, I joined the team as our marketing management finally invested to grow this team and refocus it on what is our strength working with operators?

What is the real value that we can add to the entire industry is building the DevOps bridge to developers because we weren’t so great with pure developers although we were finally getting to them and making them successful. But now, as a core value, we’d found what our sweet spot was. And this is what we want to convey to all of you.

Really, we expanded Nutanix, and recast it as to reach developers and DevOps audiences. We changed those hackathons to .DEV Day and started to engage the audience a lot more wherever they were on their journey, wherever they were in their domain of expertise inside the organization, we started to help bring them forward and understand the development side of the world and build these DevOps bridges.

But ultimately, we started working very hard to help bring this new mindset and became a content delivery organization for how to do DevOps, and we’re trying to drive the industry forward right now. So, who’s seen this picture before, the infinite DevOps loop? I still have not found the origin of this.

So, if anybody knows, please let me know. Nobody else can tell me where it is and I keep asking on Twitter, crickets. So, but nevertheless, this is very true. The point of this is that it’s continuous feedback, continuous development, continuous integration, continuous testing, and continuous operations is how we drive the feedback into what’s the next set of development features that we need.

Operator experience

How do we bring operator ergometrics into the developer experience, the operator experience? How do we drive our business experience forward? DevOps really becomes the umbrella for how we do software lifecycle management. So, to that end, I’m going to share a little bit of the DevOps enablement we do with Nutanix sales, Nutanix partners, Nutanix customers.

Over here on the right-hand side, that’s the first customer pitch slide deck, the public cloud has reset all expectations, right? We want fractional consumption. We want one-click everything. You know, when we talk about IT in the enterprise, it’s not one click to do development SAP HANA instances, is it? With Nutanix, it is now.

But that’s not the experience typically people have. And we’re trying to make home experiences on your tablets and on your phones the same thing in the enterprise. So, all of these demands and expectations have moved the industry forward and Nutanix is helping drive this onto our platform to all of our customers as well. So, we’re trying to make the enterprise like consumer experiences.

Ultimately, and the way we’re driving this forward is under the DevOps moniker, umbrella, culture, and technologies all together working. Because in IT, while it may only take 30 seconds to spin up a VM in Amazon or Azure or in VMware or on Nutanix Cloud, a lot of our customers have six weeks of governance in addition to that before they can hand over that VM.

Can you imagine the developers waiting six weeks to get something done? This is why we have shadow cloud. This is why we have shadow IT. This is why we need to drive things forward.

Luke: Our last presenters said, you know, you have the Sarbanes-Oxley, you have all this different checks to get everything. We had a gentleman just join our team. He worked for 3M and he said, it took six months sometimes to get a VM out to actually start to do his work. So, anybody here have developers working in your team, if they’re going to be idle for six months, what the heck are they doing?

Mark: Causing trouble.

Luke Yeah. So, this is something that by engaging the operators and trying to get them on board with your DevRel platform, you can hopefully help them make that speed.

Mark: Right. So, this is the digital transformation challenge that we’re seeing with all customers, no matter what their size, no matter what their age is in the entire world. So, truthfully, IT is not changing rapidly enough. And not only that, their complexity is getting worse, worse. The business is expecting these cloud-like outcomes right now, right?

That’s the fact. So, there is no way IT can meet this gap without automation, without becoming developers themselves without driving these new cloud-like experiences of automation, simplicity, and incredible efficiency. And these are really the keywords of what the Nutanix platform does for our customers. But don’t take my word for it.

We have a DevOps State of the DevOps Report, and I’ll just tell you the 2017 summary where they surveyed about 3,000 folks. And they ranked people from basically early in their journey to DevOps to more advanced practitioners. And the more advanced practitioners, ultimately, they deliver more. They do hundreds of deployments each day of their developer’s software, not six weeks waiting around, it’s six seconds to production, potentially.

I won’t say that’s all the case, but nevertheless, you get an idea of what can be accomplished. Not only do they deploy more, but they have no problems with downtime because a repair is just revert back to the latest deployment. So, that’s not a problem. That’s six seconds to fix things, any outage. And all these efficiencies are a virtuous cycle that feed back on themselves so that they automate more because there’s always more to do.

The business will come with new initiatives, the developers have new problems, so let’s solve those problems. So, the advanced practitioners of DevOps are accelerating away from even the early adopters of DevOps and really the majority of the world isn’t even there. So, this is what we see, and the HP LaserJet Firmware team adopted DevOps, and over three years, their developers increased by 700% more productivity.

Imagine every developer becoming seven, we need this at Nutanix engineering ultimately, right? Every company does. So, if you don’t think your developers aren’t interested in figuring out how to become a force multiplier, how to not wait six weeks around, there’s plenty of frustration and plenty of problems out there to solve.

Your community is thinking about DevOps

Luke: So, back to me. So, I know we’ve been going on a little bit about DevOps and why it’s important and how we have some solutions. The market’s large. I know there’s people here from all kinds of solutions, but at the core, this DevOps, this transition to DevOps, it’s a culture change. It’s not necessarily just a technology change.

And this year’s data from SlashData, again, calling them out, they’re actually one of the sponsors of the conference. This was probably the most interesting slide to me at the Future Developer Summit. These are all the different things that developers are interested in. They interviewed about 13,000 developers. The biggest one is DevOps.

That’s where they are the most interested. So, if your developer relations program isn’t thinking about it, your community is. So, this is where everybody is doing. If you’re deploying to a server in some way, shape, or form as a developer, you’re doing DevOps. If you’re an operations person and you’re writing a script, you’re doing DevOps. So, this is a big key and we’re hopefully trying to get out ahead of it so that you’re getting your programs ready for the shift because operators are coming into your programs and developers are coming in…

you’re going to be getting one team. It’s ideally, you’re going to have your development and test people and your operations people. They’re going to be talking more. And if you’re not providing content for those people, you know, they’re going to get frustrated and you’re going to lose them out.

And when you lose people out of your community, or at a company, you know, you lose developers. So, to close up, there’s a few things that we’ve found that work well to get this. Now, I’m going to say, do as I say, not as I do because we’re still working on getting all of this on our platform for, but it’s really changing the software development lifecycle to software delivery.

You know, really at the end of the day, getting stuff developed, doesn’t matter, it’s getting stuff delivered to be used. And when you have the operations team, the developer team actually talking to each other and ideally bringing in your security and your test team, you’re going to get that just that much quicker. Other things that you want to be doing is providing more information on how to do upgrades and patches. Also, the more automation scripts, you know, say you could write some automation scripts or some sample scripts to be part of your dev portal that the operators can go grab and start using right away just to spin up a dev server or a test server, that’s going to make your platform’s adoption much quicker.

Security, who’s here worrying about security? Everybody’s worrying about security.

Mark: Every developer should be.

Luke: And having a security portal area on your dev site, I think is going to become more and more common so that you’re getting there. Benchmarking and performance. You know, if the performance sucks or it needs two billion gigs of RAM or whatever, think about that in your platform and take a look at what’s actually needed, document those requirements, and make sure that those are easy to find and do that if it links to support the site or just content right there, really important.

And the more metrics, monitors, and feedback you can give back to your developer, back to your operator, back to everybody it’s going to be a much better experience and this really is, you know, expanding our community and diversifying it from just being focused purely on developers to going to focus on developers, operators, security, and testing, and everybody there.

So, thank you very much.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.