Transcript of a sponsored discussion on the latest trends around DevOps and how it's translating into new types of IT infrastructure.

1. 451’s Berkholz on How DevOps, Automation and
Orchestration Combine for Continuous Delivery
and Composable Infrastructure
Transcript of a sponsored discussion on the latest trends around DevOps and how it's translating
into new types of IT infrastructure.
Listen to the podcast. Find it on iTunes. Get the mobile app. Sponsor: Hewlett
Packard Enterprise.
Dana Gardner: Hello, and welcome to the next edition of the Hewlett Packard Enterprise
(HPE) Transformation Interview Series.
I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host and
moderator for this ongoing discussion on IT transformation and innovation
-- and how it's making an impact on people's lives.
Our next thought leadership discussion focuses on the burgeoning trends
around DevOps and how that’s translating into new types of IT
infrastructure that both developers and operators can take advantage of.
To learn more about trends and developments in DevOps, micro services, containers, and the
new direction for composable infrastructure, we’re joined by Donnie Berkholz, Research
Director at 451 Research, and he’s based in Minneapolis.
Welcome to BriefingsDirect, Donnie.
Learn More about DevOps
Solutions that Unify Development and Operations
To Accelerate Business
Donnie Berkholz: Thanks for having me.
Gardner: Why are things changing so much for apps deployment infrastructure? Why is
DevOps newly key for software development? And why are we looking for “composable
infrastructure?”
Berkholz: It’s a good question. There are a couple of big drivers behind it. One of them is cloud,
probably the biggest one, because of the scale and transience that we have to deal with now, with
virtual machines (VMs) appearing and disappearing on such a rapid basis.
We have to have software, processes, and cultures that support that kind of new approach, and
IT is getting more-and-more demands for scale and to do more from the line of business. They're
Gardner

2. not getting more money or people and they have to figure out what’s the right approach to deal
with this? How can we scale and how can we do more and how can we be
more agile?
DevOps is the approach that’s been settled on. One of the big reasons
behind that is the automation. That’s one of what I think of as the three
pillars of DevOps, which are culture, automation, and measurement.
Automation is what lets you move from this metaphor of cattle versus pets,
moving from the pet side of it, where you carefully name and handcraft
each server, to a cattle mindset, where you're thinking about fleets of
servers and about services rather than individual servers, VMs, containers, or what have you.
You can have sys admins maintaining 10,000 VMs, rather than 100 or 150 servers by hand.
That’s what automation gets you.
More with less
So you're doing more with less. Then, as I said, they're also getting demands from the business
to be more agile and deliver it faster, because the businesses all want to compete with companies
like Netflix or Zenefits, the Teslas of the world, the software-defined organizations. How can
they be more agile, how can they become competitive, if they're a big insurance company or a
big bank?
DevOps is one of the key approaches behind that. You get the automation, not just on the server
side, but on the application-delivery pipeline, which is really a critical aspect of it. You're moving
toward this continuous delivery approach, and being able to move a step beyond agile to bring
agile all the way through to production and to deploy software, maybe even on every comment,
which is the far end of DevOps. There are a lot of organizations that aren’t there yet, but they're
taking steps toward that, toward moving from deployments every three months or six months to
every few weeks.
Gardner: So the vision of having that constant iterative process, continuous development,
continuous test, continuous deployment -- at the same time being able to take advantage of these
new cloud models -- it’s still kind of a tricky equation for people to work out.
What is it that we need to put in place that allows us to be agile as a development organization
and to be automated and orchestrated as an operations organization? How can we make that
happen practically?
Berkholz: It always goes back to three things -- people, process, and technology. From the
people perspective, what I have run into is that there are a lot of organizations that have either
development or operational groups, where some of them just can't make this transition.
Berkholz

3. They can't start thinking about the business impacts of what they're doing. They're focused on
keeping the lights on, maintaining the servers, writing the code, and being able to make that
transition to focusing on what the business needs. How am I helping the company, is the critical
step from an individual level, but also from an organizational level.
IT is going through this kind of existential crisis of moving from being a cost center to fighting
shadow IT, fighting bring your own device (BYOD), trying to figure out how to bring that all
into the fold. How they do so is this transition toward IT as a service is the way we think about it.
IT becoming more like a service provider in their own right, pulling in all these external services
and providing a better experience in house.
If you think about shadow IT, for example, you think about developers using a credit card to
sign-up for some public cloud or another. That’s all well and good, but wouldn’t it be even nicer
if they didn’t have to worry about the billing, the expensing, the payments, and all that stuff,
because IT already provided that for them. That’s where things are going, because that’s the IT-
as-a-service provider model.
Gardner: People, process, technology, and existential issues. The vendors are also facing
existential issues, things and changing so fast, and they provide technology, the people and the
process which is up to the enterprise to figure out. What's happening on the technology side, and
how are the vendors reacting to allow enterprises to then employ the people and put in place the
processes that will bring us to this better DevOps automated reality? What can we put in place
technically to make this possible?
Two approaches
Berkholz: It goes back to two approaches -- one coming in from the development side and one
coming in from the operational side.
From a development side, we're talking about things like continuous-delivery pipelines -- what
does the application delivery process look like? Typically, you'd start with something like
continuous integration.
Just moving toward an automated testing environment, every commit you make, you're testing
the code base against it one way or another. This is a big transition for people to make, especially
as you think about moving the next step to continuous delivery, which is not just testing the code
base, but testing the full environment and being ready to deploy that to production with every
commit, or perhaps on a daily basis.
So that's a continuous-integration, continuous-delivery approach using CI servers. There's a
pretty well-known open-source one called Jenkins. There are many other examples of as-a-
service options around the prime options. That tends to be step one, if you're coming in from the
development side.

4. Now, on the operational side, automation is much more about infrastructure as code. It's really
the core tenet, and this is embodied by configuration management software like Puppet, Chef,
Ansible, Salt, maybe CFEngine, and the approaches defining server configuration and code and
maintaining it in version control, just like you would maintain the software that you're building
in version control. You can scale it easily because you know exactly how a server is created.
You can ask if that's one mail server or is it 20? It doesn’t really matter. I'm just running the same
code again to deploy a new VM or to deploy onto a bare-metal environment or to deploy a new
container. It’s all about that infrastructure-as-code approach using configuration-management
tools. When you bring those two things together, that’s what enables you to really do continuous
delivery.
You’ve got the automated application delivery pipeline on the top and you've got the automated
server environment on the bottom. Then, in the middle, you’ve got things like service
virtualization, data virtualization, and continuous-integration servers all letting you have an
extremely reliable and reproducible and scalable environment that is the same all the way from
development to production.
Learn More about DevOps
Solutions that Unify Development and Operations
To Accelerate Business
Gardner: And when we go to infrastructure as code, when we go to software-based everything.
There's a challenge getting there, but there are also some major paybacks. When you feed-up to
analyze your software, when you can replicate things rapidly, when you can deploy to a cloud
model that works for your economic or security requirements, you get lot of benefits.
Are we seeing those yet, Donnie?
Berkholz: One of the challenges is that we know there are benefits, but they're very challenging
to quantify. When you talk about the benefit of delivering a solution to market faster than your
competitors, the benefit is that you're still in business. The benefit is that you’re Netflix and
you're not Blockbuster. The benefit is that you’re Tesla and you’re not one of the big-three car
manufacturers. Tesla, for example, can ship an update to its cars that let them self-drive on-the-
fly for people who already purchased the car.
You can't really quantify the value of that easily. What you can quantify is natural selection and
action. There's no mandatory requirement that any company survive or that any company can
make the transition to software-defined. But, if you want to survive, you’re going to have to take
this DevOps mindset so that you can be more agile, not just as a software group, but as a
business.
Gardner: Perhaps one of the ways we can measure this is that we used to look at IT spend as a
percentage of capital spend for an enterprise. Many organizations, over the past 20 or 30, years
found themselves spending 50 percent or more of their capital expenditures on IT.

5. I think they'd like to ratchet back. If we go to IT as a service, if we pay for things at an operations
level, if we only pay for what we use, shouldn't we start to see a fairly significant decrease in the
total IT spend, versus revenue or profit for most organizations?
Berkholz: The one underlying factor is how important software is to your company. If that
importance is growing, you're probably going to spend more as a percentage. But you're going to
be generating more margin as a result of that. That's one of the big transitions that are happening,
the move from IT as a cost center to IT as a collaborator with the business.
The move is away from your traditional old CIO view of we're going to keep the lights on. A lot
of companies are bringing in Chief Digital Officers, for example, because the CIO wasn't taking
this collaborative business view. They're either making the transition or they're getting left
behind.
Spending increase
Ithink we'll see IT spend increase as a percentage, because companies are all realizing that, in
actuality, they're software companies or they're becoming software companies. But as I said, they
are going to be generating a lot more value on top of that spend.
To your point about OPEX and buying things for the service, the piece of advice I always give to
companies is the saying, "How many of these things that you're doing are significant
differentiators for your company?" Is it really a differentiator for your company to be an expert at
automating a delivery pipeline, to be an expert at automating your servers, to be an expert at
setting up file sharing, to be an expert at setting up an internal chat server? None of those, right?
Why not outsource them to people who are experts and to people who do generate that as their
core differentiator and their core value creator and focus on the things that your business cares
about.
Gardner: Let's get back to this infrastructure equation. We're hearing about composable
infrastructure, software-defined data center (SDDC), micro services, containers and, of course,
hybrid cloud or hybrid computing. If I'm looking to improve my business agility where do I look
to in terms of understanding my future infrastructure partners? Is my IT organization just a
broker and are they going to work with other brokers? Are we looking at a hierarchy of brokering
with some sort of a baseline commoditized set of services underneath?
So, where do we go in terms of knowing who the preferred vendors are. I guess we're sort of
looking at a time when no one got fired for from buying IBM, for example. Everyone is saying
Amazon is going to take over the world, but I've heard that about other vendors in the past, and it
didn't pan out. This is a roundabout way of saying when you want to compose infrastructure,
how do you keep choice, how to keep from getting locked in, how do you find a way to be in a
market at all times?

6. Berkholz: Composability is really key. We see a lot of IT organizations. As you said, they used
to just buy Big Blue, for example, at their IBM shops. That's no longer a thing in the way that it
used to be. There's a lot more fragmentation in terms of technology, programming languages,
hardware, JavaScript toolkits, and databases.
Everything is becoming polyglot or heterogeneous, and the only way to cope with that is to
really focus on composability. Focus on multi-vendor solutions, focus on openness, opening
APIs, and open-source as well, are incredibly important in this composable world, because
everything has to be able to piece together.
But the problem is that when you give traditional enterprises a bunch of pieces, it's like having
kids just create a huge mess on the floor. Where do you even get started? That's one of the
challenges they need to have. The way I always think about it is what are enterprises looking for?
They're looking for a Lego castle, right? They don’t want the Lego pieces, and they don't want
like that scene in The Lego Movie where the father glues all the blocks together. They don't want
to be stuck. That's the old monolithic world.
The new composable world is where you get that castle and you can take off the tower and put
on a new tower if you want to. But you're not given just the pieces; you're given not just
something that is composable, but something that is pre-composed for you, for your use. case. So
that generates value and looks like what we used to think about reference architectures, for
example, being something sitting on a PowerPoint slides with kind of a fancy diagram.
It’s moving more toward referenced architectures in the form of code, where it’s saying, "Here's
a piece of code that’s ready to deploy and that’s enabled through things like infrastructure as
code.
Gardner: Or a set of APIs.
Ready to go
Berkholz: Exactly. It’s enabled by having all of that stuff ready to go, ready to build in a way
that wasn’t possible before. The best-case scenario before was, "Here’s a virtual appliance; have
fun with that." Now, you can distribute the code and they can roll that up, customize it, take a
piece out, put a piece in, however they want to.
Gardner: Before we close out, Donnie, any words of advice for organizations back to that
cultural issue -- probably the more difficult one really? You have a lot of choices of technology,
but how you actually change the way people think and behave among each other is always
difficult. DevOps, leading to composable infrastructure, leading to this sort of services brokering
economy, for lack of a better word, or marketplace perhaps.
What are you telling people about how to make that cultural shift? How do organizations change
while still keeping the airplane flying so to speak?

7. Berkholz: You can’t do it as a big bang. That's absolutely the worst possible way to go about it.
If you think about change management, it’s a pretty well-studied discipline at this point. There's
an approach I prefer from a guy named John Kotter who has written books about change
management. He lays out an eight- or nine-step process of how to make these changes happen.
The funny thing about it is that actually doing the change is one of the last steps.
So much of it is about building buy-in, about generating small wins, about starting with an
independent team and saying, "We're going to take the mobile apps team and we're going to try a
continuous delivery over there. We're not going to stop doing everything for six months as we are
trying to roll this out across the organization, because the business isn’t going to stand for that."
They're going to say, "What are you doing over there? You're not even shipping anything. What
are you messing around with?" So, you’ve got to go piece by piece. Let’s say, start by rolling out
continuous integration and slowly adding more and more automated tests to it, while keeping the
manual testers alongside, so that you're not dropping all of the quality that you had before. You're
actually adding more quality by adding the automation and slowly converting those manual
testers over to the engineers on test.
That’s the key to it. Generate small wins, start small, and then gradually work your way up as
you are able to prove the value to the organization. Make sure while you're doing so that you
have executive buy-in. The tool side of things you can start at a pretty small level, but thinking
about reorganization and cultural change, if you don’t have executive buy-in, is never going to
fly.
Learn More about DevOps
Solutions that Unify Development and Operations
To Accelerate Business
Gardner: And perhaps that executive buy-in includes thinking of yourself as a software
organization.
Berkholz: Absolutely.
Gardner: We've been exploring the new ways that DevOps, automation, and orchestration are
coming together for continuous delivery and composable infrastructure with Donnie Berkholz,
Research Director at 451 Research, and he is based in Minneapolis. Thanks so much, Donnie.
Berkholz: Thank you.
Gardner: And a big thank you to our audience as well for joining us for this Hewlett Packard
Enterprise Transformation and Innovation Interview.
I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of
HPE-sponsored discussions. Thanks again for listening, and come back next time.

8. Listen to the podcast. Find it on iTunes. Get the mobile app. Sponsor: Hewlett
Packard Enterprise.
Transcript of a sponsored discussion on the latest trends around DevOps and how it's translating
into new types of IT infrastructure. Copyright Interarbor Solutions, LLC, 2005-2016. All rights
reserved.
You may also be interested in:
• Big data enables top user experiences and extreme personalization for Intuit TurboTax
• Feedback loops: The confluence of DevOps and big data
• Spirent leverages big data to keep user experience quality a winning factor for telcos
• Powerful reporting from YP's data warehouse helps SMBs deliver the best ad campaigns
• IoT brings on development demands that DevOps manages best, say experts
• Big data generates new insights into what’s happening in the world's tropical ecosystems
• DevOps and security, a match made in heaven
• How Sprint employs orchestration and automation to bring IT into DevOps readiness
• How fast analytics changes the game and expands the market for big data value
• How HTC centralizes storage management to gain visibility and IT disaster avoidance
• Big data, risk, and predictive analysis drive use of cloud-based ITSM, says panel
• Rolta AdvizeX experts on hastening big data analytics in healthcare and retail
• The future of business intelligence as a service with GoodData and HP Vertica
• Enterprises opting for converged infrastructure as stepping stone to hybrid cloud