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

http://www.xebialabs.com/

http://www.xebialabs.com/products

http://blog.xebialabs.com/

http://twitter.com/xebialabs

http://youtube.com/xebialabs

Thank You!

moving from infrastructure automation to true devops

Technology

confidential distribution

permission devops

platform teams

permission agendadevops

platform boundary

application version

deployment model

platformenvironment