Making Enterprise Developers Lives Easier With Cloud Tools: An Interview With Andi Grabner

If you are an enterprise developer reading this you might be saying, "Help! How do I get back to coding?" So many developers I've talked to of late have lamented that their jobs have increasingly taken the actual time they spend coding down to 70% or 30% of the time.

Luckily, we are in the automation era where experts like Dynatrace DevOps Activist Andi Grabner exist. I recently had the chance to chat with Andi at Dynatrace Perform on how we can make enterprise developer's lives easier with cloud tools.

In this in-depth interview, we cover topics including:

• How do developers get back to coding?
• Making enterprise developers lives easier with cloud tools
• NoOps
• Keptn, an open-source enterprise-grade control plane for cloud-native continuous delivery and automated operations
• Dynatrace “customer zero"
• The future of software

How Do Developers Get Back to Coding?

If you look at other organizations, so why do developers spend so much time with other things? Because, as you started to talk with developers having to put in manual monitoring, that's a lot of extra effort that they may not want. They're bringing in another library that they have to learn, and then spending time to figure out how this really works. Then they also have to try and figure out where to send the data to. Then figuring out, "How do I get access to the data? Do I only get access to the data in development or late in production as well?"

These are all things that you don't have to figure out anymore with Dynatrace, because this just comes out of the box. There's no manual code instrumentation, the data gets automatically sent to Dynatrace, it's automatically analyzed, and then we know a lot about that data. We know where this data comes from. We know it came from Blake because he deployed this build through Jenkins at two o'clock in the afternoon into this environment and then into this environment. Let me compare these two builds. Then let me send Blake a Slack message with the results. The situation is now taken care of.

From your perspective, how can cloud tools make developer's lives easier? Increasingly I hear stories of developers spending way more time on tasks not related to coding or spending lots of time on manual monitoring.

We have this movement towards autonomous cloud enablement that means our ACE team is providing all the tooling in the platform that takes away all this pain for developers and provides it back to them as a self-service. 

So that means if a developer is in the artifact that they want to get deployed, they want to get feedback on, they just basically say, "Here's my artifact put it into a container registry." It's then getting picked up, and it's getting deployed through I would call it an opinionated pipeline, opinionated in the way that we are taking it, deploying it, and running tests that are meaningful, which means we know what code is changed, and we only run meaningful tests. 

Next, we are looking at KPIs, so we're looking at SLI (Service Level Indicators) and SLO (Service Level Objectives) validation. So we figure out how good this code is, how it is performing compared to the previous builds, and how it is compared to the previous release. We then give this corrective feedback to the developers via Slack. If there's a clear issue, we're automatically opening up JIRA tickets. And basically, in the ticket, giving them all the data that they need, because all the data is there as we are automatically monitoring.

Internally we use Dynatrace on Dynatrace, so in essence, we use Dynatrace as we want our customers to use Dynatrace. That means instrumenting dev, QA, staging, and production. Not only using it for monitoring, but also for things like the production workloads and applying that workload in our pre-production tests. Because if you run tests, you want to run tests that are as close as possible to production. These are the things we can do.

We can make the data available as self-service. So I always say we have a lot of great data, but the most important thing is if we can give the data to the right people at the right time in their tools of choice so that they can make the next right decision. We can give the data via Slack. We can create JIRA tickets. We can push it into their IDE. There is a lot that we can do for developers.

What we do is through self-service, giving them the data that they need in the tools that they're comfortable working with. This helps them a lot because they don't have to learn another tool. They don't have to configure anything extra. It's not an extra step that they need to do. The data is just there. Most of it happens fully automatically, like monitoring. Also, the analysis of code and the performance characteristics happen automatically.

To continue my story, when I said developers are uploading something to the registry where it gets taken and deployed, and if it's so good, it automatically gets promoted into the next stage where we may do some more performance testing, and then the developer gets feedback, "Hey, this is solid and great code." So, we can then go to production if you want to. It's just a click away. "Okay, let's push it out. Do you want to push it out to everybody, or do you want to push it out to, let's say, a small test group first to get some feedback?"

In the old days deployments happened maybe once a month if you were lucky, and now you hear stories from users like Nestor A. Zapata at Citrix who can do multiple deployments a day using Dynatrace.

Exactly! And the reason why this took so long was because this was also true for our organization when we started with our DevOps transformation. We first did it on our core Dynatrace software platform, but we had a lot of other teams that were building other software. They all built their own stuff and their own pipelines. They all figured out how to do continuous delivery, and they all spent much time in making sure that these tools work, which doesn't make sense because these developers, like you, said they want to build real new features and not dealing with keeping pipelines alive.

So that's when we said we need to provide the platform that we build around Dynatrace. When we deliver the Dynatrace software platform, we need to do the same thing for all the other development teams. So we need to provide them a platform that allows them to become very autonomous to deliver software on our cloud platforms. Everything has to be self-service so that they can actually focus on delivering new features and value.

Many IT managers are struggling to get out of technical debt. They are also trying to minimize downtime and reduce the time it takes to chasing down issues. Cloud tools offer immediate help in this regard.

There is also a customer problem that we solve with Keptn. Thanks to Jenkins, that it was there like 10 to 15 years ago and kind of revolutionized CI, and many people also use it for CD. What I've seen with companies when they started with Jenkins is that they started in some projects, they built their pipelines, and it worked for them. Then the next thing came along and they copied that pipeline and modified it for their needs. Then the next thing came along, and they copied that pipeline and modified it for their needs. So you ended up with 10 to 15 to over 100 different pipelines, and everybody had to maintain it individually.

In these pipelines it's basic. It's the law of logic. It's all the coding in there that you have to keep working. This is also part of the time that is eating away from the developer's passion for writing code. This is the problem that we solve with Keptn: there is no pipeline code anymore. Everything is declarative. It means you don't have to deal with defining it in a script to which stage you want to execute and for which tool to do which job, and what do you do with the output. Keptn is event-driven. It has an opinionated approach to promote artifacts through an opinion in the pipeline by deploy, test, evaluate, and promote. It gives back time to developers to do the stuff that they really like.

How Would You Describe NoOps?

NoOps is a mindset. It's everything we do. In everything we do, we think of what can potentially go wrong, and how can we avoid it through automation. So what can potentially go wrong with my code change or configuration change in production that would typically cause somebody in Ops to fix something? How can I avoid this from the get-go? How can I build in more tests to stop bad code changes? How can I build in automation self-healing capabilities to automatically roll back instead of having somebody do something?

So NoOps is a mindset. The idea is that, as a developer, I just need to think about a couple of things. How can I build resilience into the system? Whether the key metrics tell me if I'm healthy or not? Then based on these metrics, decide on what to do next. Do I scale up or scale down or rollback? In the end, it means that I am reducing the traditional effort in operations. That's why NoOps is a mindset.

There still are people that take care of the infrastructure and operations, but thanks to automation, we are automating most of these things so that issues never end up in production because we are stopping bad code changes early in the process. In case there is a problem that goes into production, we want to automate the remediation of these problems as well as possible.

In the end, I think Thomas Reisenbichler put it very well that NoOps is a mindset, which means everyone in the organization has to think of what can potentially go wrong with the action I'm taking now and how can I automate the remediation of it?

For those not familiar with customer zero, how would you describe it? Is it a mindset?

No, customer zero means we are our own customer. We at Dynatrace use Dynatrace before everybody else. So we are using the latest build to monitor all of our environments before it goes out to our customers. That's why we are customer zero. We are the first ones internally that use the latest build, the latest features, and we give feedback to the product team.

As Thomas Reisenbichler said yesterday, a lot of the features that we now see in the Dynatrace platform, have been inspired and asked for by our Dynatrace ACE team. We're using Dynatrace in the delivery pipeline like we want our customers to use it, but this feature doesn't do its job well, "We need this and this one."

Years ago, they said we need log analytics in the product. Yesterday we were talking about the heap dump capability. These are all the things that they are experiencing as customer zero. We are using our product before our first customers are using it. That's why it is customer zero.

Excellent, and I don't see that with a lot of other companies using that type of approach!

We are obviously in a lucky situation that Dynatrace, the product, is a product that solves many problems in the development process.

It depends, I guess on what type of product, you are delivering as an organization with how you can use this early on. I'm pretty sure that software most companies are building is something that you can try to use internally before you expose it to the customer.

From a trend and future perspective, what are some of the things on the road ahead that excite you for making developer's lives even easier?

If you remember my analogy yesterday in my talk about the picture story. I think the analogies we need to make are that we need to make it as easy as taking a picture, running it through an app that is enhancing the picture, and then deploying it and getting feedback. Delivering software has to become as easy as doing precisely that. Writing some code and then running it through a pipeline that alerts me on bad code that then gives me a recommendation on how to make it better. And then automatically delivering it to my users and them giving me feedback on it. 

It has to be as simple as posting something on Instagram. I think that's the goal for me in the next five years.

So the abstraction layers of software still have to retain a simple mindset?

Yes, and we all know that the world has a shortage of developers. So that means in order for us to onboard more developers, I think we also need to make it easier. You cannot train software architects like we did that have very deep knowledge about everything. We also need to think about how we can help onboard people that may not have a software engineering background to be able to develop software or deliver value in an effortless self-service way, without them however messing up everything. That's why it needs to be easy, but it needs to be fail-safe.