Webinar Highlights for Developer Success

Understand developers’ needs to rapidly build, test, and deploy applications. Get insight into key research findings with webinar highlights featuring Chris Gardner, senior analyst at Forrester Consulting.

Transcript

So we did some custom research for Intel around the experience that developers have around the hybrid cloud. Obviously a lot of folks have been moving systems to the public cloud, some of them are moving back. There's a conversation right now going on about the edge and where exactly that is. And we did some research about what is the best developer experience when it comes to these kind of things, what are they looking for, what are decision leaders making decisions around to make sure developers have the experience that they need.

So we're going to go over some findings during this presentation. Some of them are going to be things that are fairly commonplace, or obvious, and some of them are not going to be so obvious and that's exactly why we do research the way we do.

So let's start with the findings themselves from the research that we did. So hybrid is all about using the right platform for the job. We typically have conversations with our clients about workload management and movements. And what traditionally happens is that there's a cost analysis that's done upfront that says, OK, I would like to move these particular workloads to a particular location to save money. And what we tend to find is that that is a short sighted approach.

Ultimately what you want to do is not necessarily save money, although that's a benefit typically from moving workloads around, but you want to move workloads to the right location so you can move your run rate to grow. So when we asked folks how do you expect your hybrid cloud usage to grow and expand, a significant number are still migrating core applications to cloud platforms, which is expected, and also building new applications, which is also expected.

What we're starting to see growth in, and I'm glad to see it, is the adoption of containers. Containers were a thing that some of the unicorns had been using for years and they had done so quite successfully. But most enterprises had just been experimenting with them. The more that we talked to our clients and the more that we have these conversations, the more we find that folks are now using them for production level workloads, which is a good sign because they're often tied into micro services as well. And that's the 28% here. As folks move towards microservices, infrastructures code benefits from living in a hybrid cloud.

So all these numbers are kind of what we expected. What I was glad to see is that there is an emphasis on building out infrastructure that developers can use. It's adopting containers in dev and test, it's going to get microservices, which is what most application writers are wanting to do at this stage versus writing a monolithic application.

Let's take it a little bit deeper. When we ask folks why are you using clouds, and let me be clear that very few people nowadays use a single cloud. Most of our data proves that at the very least, people are using two or more cloud providers, and these can be everything from the mega clouds like Amazon and Azure to things like private cloud offerings from IBM to international offerings like Alibaba in addition to private clouds that are being run on premises. But when we ask folks why do this? The number one response was to offer developers a broader range of environments tools and services, which is really good to see.

Up until recently, I think there's been a bit of a tension between development communities and the operations folks that manage infrastructure, and that includes cloud environments. And what we're finally seeing is a reconciliation as we move towards DevOps and as these groups start to combine, there's a recognition that folks on the operations side need to provide environments that developers are happy to use and give them choice. And developers are in the process of learning some of the lessons around reliability and scalability that they may have not previously considered.

Obviously there's some other reasons why people use multiple clouds. Typically, it's a combination of moving things that are cloud native into the proper locations for them versus running them on premises in a lot of cases, to speed up the software development testing, which is awesome. Up until recently a lot of that was done through using spin up environments and just basically testing out environments in the cloud without actually doing it on premises. Now we're finding that folks are doing tests typically on premises and then moving things into the public cloud as needed for burst and for higher compute. And some apps are particularly centered around one or multiple environments, whether it's on premise or cloud.

So what I'm happy to see here is this emphasis on using the right tool for the job and being able to give developers options versus mandating that they use particular environments. As we move down this road, infrastructures code enables consistent configurations no matter what cloud it lives in. So the world of having the trials of moving something from dev into UAT into production seems to be diminishing.

Going a little further into this, I was a little surprised to see this in some ways because that's not something that I would have thought is on people's minds as much as it should be. I'm glad to see this, but basically we're saying what are the top benefits that you perceive from using multiple clouds. And turns out within the top is higher developer satisfaction, which is really awesome. I mean, some of these things I would have expected to see regardless. Reachability to innovate, improved app and infrastructure performance, that makes sense, right? You move the workloads to where they belong and you will get these benefits.

But there's a realization that even though we're a business, even though we're trying to get things and feature some products out, even though we're obviously trying to generate new revenue opportunities, there is a developer satisfaction element to that. I've often considered developments and infrastructure operations to be the unstoppable shield versus be an unstoppable force or the unbreakable shield versus the unstoppable force. It's two groups and in the past have been kind of tense with one another. And we're finally seeing is a recognition that if you're not building out environments that are developer friendly, you're not doing your job.

So there's the fact that this is so high up, that developer satisfaction is such a keen metric that folks are targeting for in their infrastructure and operations workflows is a really great sign. And going further when we look at what are the top sided benefits of hyper cloud in general, there is a consensus that improved security and compliance is one of the most critical benefits of this. And at first glance, it seems like it would be counter-intuitive to think that if I'm putting my data into multiple clouds, or in workloads as well, that I would run into better security compliance. But there's a couple things going into it.

One is the architecture work that I was referring to around change management, which traditional change management processes and compliance, quite frankly, was a very manual effort that involved as many people as could be feasibly be on a phone. I've had personal experiences where I've gotten on change management calls and you get that little notification that how many people are on the line before you pronounce your name, it said something like there's 78 people on this call. And I was sitting there thinking I'm not sure how we could possibly accomplish anything with 78 people talking at once.

What we're finding is that as people move towards increasingly hybrid environments, that they're having to and wanting to build out infrastructures code models that work on all of them. And when you do that you make life a lot easier from a security compliance perspective because you can mandate up front that particular configurations are set in a particular way. And it also frees up a lot of effort in terms of change management because you can start to classify things that were previously potentially considered high risk and requiring a significant amount of oversight to not be. And as an example, something I've seen is configuration of services that are going to be reaching users. If there's a particular port that gets opened every time no matter what cloud it lives on, chances are you don't need to convene the change management board with that and you can have an automatic process that doesn't just do it indiscriminately open that port, but does it in a way that there's an audit trail and it recognizes over time that that is a common configuration.

[DELL MUSIC PLAYING]