Moving From Infrastructure Automation To True DevOps

Deliver Software Faster
Without Rebuilding Everything
February 25, 2015

2 Copyright 2015. Confidential – Distribution prohibited without permission
Lightning Recap
Summary of “part 1” of this story:
▪ Operations has become a software-defined endeavour
▪ DevOps = applying “Dev Dev” methodologies, practices and tooling to “Ops Dev”
▪ Having two development teams as a result works perfectly well for many
organizations
▪ Creating end-to-end development teams is an option that promises benefits, but
also challenges
▪ Figuring out which approach works best for you, and implementing that, is
“thinking the way the masters think”

Agenda
▪ “DevOps:” providing a platform
▪ 1 + 1 = 3: What does “Devops” look like?
▪ Finding the approach that’s right for you
▪ So much for “how”…but why?
▪ Where do I go from here?

Me! Me! Me!
▪ VP Products for XebiaLabs
▪ Lots of enterprise software development on high-performance
systems
▪ Been on both sides of the “Dev…Ops” fence
▪ Active open source contributor and committer:
jclouds, Akka, Gradle and others
▪ Cloud, PaaS & Scala fan
▪ Regular meetup, conference etc. presenter

Us! Us! Us!
▪ We build software to support DevOps and Continuous Delivery at scale

“DevOps:” providing a platform

Application and platform teams:
▪ Ops/platform team responsible for providing a runtime environment that Just
Works
▪ Application team responsible for developing business logic to run on (a particular
version of the) platform
▪ An easier step to take for many organizations as it aligns with existing org
structure and responsibilities

Application and platform teams:
▪ Easy to sell to developers: “It Just Works”
▪ …as long as they can use whichever languages/frameworks/tools they need
▪ Process to update the platform definition/contract needs to be well-defined and
ongoing – win-win not zero sum!
▪ Providing more than one (version of the) platform is always an option

In practical terms:
▪ Platform boundary sits pretty close to the application code and configuration layer
▪ Usually takes the form of some kind of “package and configuration format”
▪ Application typically handles business logic
▪ Platform takes care of “operational” concerns such as deployment, logging,
monitoring, failover, auto-scaling etc.
▪ Two versioned deliverables: application version and platform/environment
version: “PaaS model”

In practical terms:
▪ Deployment model: “in place update”/application tier is refreshed/updated
▪ Platform takes care of rolling hot deployment, traffic management etc.
▪ Enables very fast, efficient updates, especially in more complex stacks
▪ Platform supports fast determination of whether a problem is an “app” or
“platform” issue, so the responsibilities can be efficiently divided

1 + 1 = 3:What does “Devops” look like?

Integrated “full stack” development team:
▪ Increasing understanding across “Dev Dev" and "Ops Dev" can allow both teams
to work together on optimizations
▪ Sharing knowledge becomes much easier when there is "cultural affinity"
▪ If both groups are actually developers, this becomes much easier

Integrated “full stack” development team:
▪ Two types of shared knowledge: up and down the stack, and left to right (i.e. Dev
to Prod) along the process
▪ Of course, nobody can or will understand the entire stack and process...
▪ …it’s the "knowledge overlap" zones that are important

Emphasize mutual respect:
▪ “Dev Devs" may have a bigger background in coding…
▪ …but the "Ops Devs" will usually have better knowledge of what it takes to
actually get stuff to run
▪ Both should be equally valued in the team, since both are needed to actually get
cool stuff into the hands of your users!

In practical terms:
▪ Shared foundations are pretty far “down” in the stack: using the same hypervisor,
IaaS or similar
▪ The full stack from that point up is a single versioned entity delivered by the
integrated team: “virtual appliance model”

In practical terms:
▪ Deployment model “build clone & reroute traffic”, since updating part of the single
versioned entity doesn’t make sense
▪ Need to ensure time to instantiate a full stack doesn’t become a bottleneck
▪ More flexibility => more responsibility: “you build it, you get the pager”

Finding the approach that’s right for you

There is no One Answer To Rule Them All. It depends on your context
▪ Can you build a rock solid, reliable platform that Just Works…and can you force
your developers to develop to its constraints?
▪ Do you have a lot of off-the-shelf software for which exceptions need to be
made?
▪ Is your organizational structure amenable to the idea of having unified (product-
specific?) dev teams for the entire stack, or does a Dev/Ops boundary work
better?

Important:
▪ You need to have either shared understanding or a crystal-clear, reliable,
automatable contract (“platform”) otherwise
▪ Both doesn’t hurt but neither is a problem!
▪ Don’t feel pressured to implement any particular toolstack or practice just
because some “leading Devops company” does so!

Important:
▪ It’s OK to come up with different answers for different teams, departments,
business units etc.

So much for “how”…but why?

Let’s take a step back
▪ Yes, we all benefit from better runtime platforms, shared learning and
understanding etc.
▪ But: try to phrase that as a quantifiable benefit for your CIO!
▪ Shared focus across all teams: building stuff and getting it running
▪ Getting stuff running more efficiently and better = faster time to market + reduced
cost + higher quality = quantifiable benefit

Common goals
▪ Being DevOps
▪ Faster time to market
− Usually mashed up into “Continuous Delivery is the goal of DevOps” or something like that
▪ Fewer failed end-user transactions
▪ Faster MTTR
▪ Reduced expenditure delivering applications
▪ Reduced expenditure running applications
▪ Etc. etc.

Common goals
▪ “None” (don’t pick this one!)
▪ Faster time to market
− Usually mashed up into “Continuous Delivery is the goal of DevOps” or something like that
▪ Fewer failed end-user transactions
▪ Faster MTTR
▪ Reduced expenditure delivering applications
▪ Reduced expenditure running applications
▪ Etc. etc.

Choose business-relevant goals. Example (GE Capital):
▪ “Blackboard to production time”
▪ “Failed customer interactions”
▪ “Reduced audit effort”

Where do I go from here?
The XebiaLabs booth, naturally! Except that the booths are already done ;-)

Action Plan
1. Identify major goals for the overall initiative and state them in a measurable way
2. Pick one or two “showcase” teams/projects/departments to which these goals
apply. These need to be visible/high-profile enough for improvements to make a
noticeable difference at the decision-maker level
3. Find out which approach (“DevOps” or “Devops”) is most appropriate to the
showcases
4. Run a timeboxed experiment to trial the tools (XebiaLabs tools, naturally! ;-))
and processes you want to implement for the showcases to build confidence,
gain experience and uncover challenges

Action Plan
5. Take a baseline of whatever metrics you are going to use to measure progress
against your goals
6. Apply the chosen toolkit and process from the sandbox to the showcase project
7. Regularly measure progress against the baseline and making those results
highly visible – whether good or not so good. Secrecy does not build trust

More Info
▪ Get started today!
www.xebialabs.com
www.xebialabs.com/products
▪ Stay informed:
blog.xebialabs.com
@XebiaLabs
youtube.com/xebialabs

Moving From Infrastructure Automation To True DevOps

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Moving From Infrastructure Automation To True DevOps

Similar to Moving From Infrastructure Automation To True DevOps (20)

More from XebiaLabs

More from XebiaLabs (20)

Recently uploaded

Recently uploaded (20)

Moving From Infrastructure Automation To True DevOps

Editor's Notes