The document discusses different approaches to implementing DevOps. It describes providing a platform where operations provides a runtime environment and applications are developed to run on that platform. It also describes integrated full-stack development teams where developers work across the entire development process. It emphasizes that there is no single right approach and organizations need to determine what works best for their context based on factors like organizational structure and software used. The goal of any approach should be quantifiable benefits like faster development and reduced costs.

1. Deliver Software Faster
Without Rebuilding Everything
February 25, 2015

2. 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”

3. 3 Copyright 2015. Confidential – Distribution prohibited without permission
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?

4. 4 Copyright 2015. Confidential – Distribution prohibited without permission
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

5. 5 Copyright 2015. Confidential – Distribution prohibited without permission
Us! Us! Us!
▪ We build software to support DevOps and Continuous Delivery at scale

6. 6 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform

7. 7 Copyright 2015. Confidential – Distribution prohibited without permission
“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

8. 8 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform
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

9. 9 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform
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”

10. 10 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform
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

11. 11 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform

12. 12 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform

13. 13 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform

14. 14 Copyright 2015. Confidential – Distribution prohibited without permission
“DevOps:” providing a platform

15. 15 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?

16. 16 Copyright 2015. Confidential – Distribution prohibited without permission
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

17. 17 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?
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

18. 18 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?
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!

19. 19 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?
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”

20. 20 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?
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”

21. 21 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?

22. 22 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?

23. 23 Copyright 2015. Confidential – Distribution prohibited without permission
1 + 1 = 3:What does “Devops” look like?

24. 24 Copyright 2015. Confidential – Distribution prohibited without permission
Finding the approach that’s right for you

25. 25 Copyright 2015. Confidential – Distribution prohibited without permission
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?

26. 26 Copyright 2015. Confidential – Distribution prohibited without permission
Finding the approach that’s right for you
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!

27. 27 Copyright 2015. Confidential – Distribution prohibited without permission
Finding the approach that’s right for you
Important:
▪ It’s OK to come up with different answers for different teams, departments,
business units etc.

28. 28 Copyright 2015. Confidential – Distribution prohibited without permission
Finding the approach that’s right for you

29. 29 Copyright 2015. Confidential – Distribution prohibited without permission
So much for “how”…but why?

30. 30 Copyright 2015. Confidential – Distribution prohibited without permission
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

31. 31 Copyright 2015. Confidential – Distribution prohibited without permission
So much for “how”…but why?
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.

32. 32 Copyright 2015. Confidential – Distribution prohibited without permission
So much for “how”…but why?
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.

33. 33 Copyright 2015. Confidential – Distribution prohibited without permission
So much for “how”…but why?
Choose business-relevant goals. Example (GE Capital):
▪ “Blackboard to production time”
▪ “Failed customer interactions”
▪ “Reduced audit effort”

34. 34 Copyright 2015. Confidential – Distribution prohibited without permission
So much for “how”…but why?

35. 35 Copyright 2015. Confidential – Distribution prohibited without permission
Where do I go from here?
The XebiaLabs booth, naturally! Except that the booths are already done ;-)

36. 36 Copyright 2015. Confidential – Distribution prohibited without permission
Where do I go from here?
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

37. 37 Copyright 2015. Confidential – Distribution prohibited without permission
Where do I go from here?
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

38. 38 Copyright 2015. Confidential – Distribution prohibited without permission
More Info
▪ Get started today!
www.xebialabs.com
www.xebialabs.com/products
▪ Stay informed:
blog.xebialabs.com
@XebiaLabs
youtube.com/xebialabs

39. Thank You!