In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals—as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost. This is the case with DevOps. On the one hand, many DevOps discussions focus on culture, breaking down silos, making everyone responsible for security, and giving developers operational responsibility for their applications. This is primarily a developer-centric view of DevOps. On the other hand, DevOps (or cloud-native operations if you prefer) can also be approached through the lens of how operations enables developers and relentlessly automates using expert teams--while also managing business risk. In this session, Red Hat Technology Evangelist Gordon Haff will discuss different patterns for creating next-generation software and provide insight into when particular approaches may be more or less suitable. You’ll leave with a better understanding of optimizing the software delivery pipeline in your organization.

1. GENERALISTS AND SPECIALISTS:
DIVERGENT PATTERNS FOR DEVOPS
GORDON HAFF
Technology Evangelist, Red Hat
@ghaff

2. THE GENERALIST TEAM

3. IN THE BEGINNING
Source: Cisco

4. Source: http://www.agilebuddha.com/agile/demystifying-devops/
WIDENING
AGILE
PRINCIPLES
TO CROSS-
FUNCTIONAL
TEAM

5. Source: Michael Coté, flickr/CC
https://www.flickr.com/photos/cote/5559360372
“TWO PIZZA” TEAMS
● Autonomous
● Cross-functional
● Responsible for a well-defined
function/service
● Developing and running

6. CONWAY’S LAW
Any organization that designs a
system (defined broadly) will
produce a design whose structure
is a copy of the organization's
communication structure.

7. ONE OPPOSING VIEW
"I want to change my job because there is this horrible concept of
"pager duty" or "oncall". Where the developer has to be ready for
any issues that may occur. Are most software jobs like this? Is this
a norm? Where can I find software development positions without
such concepts?"
Anonymous Quora user

8. WE ALSO TALK
ABOUT CULTURE A LOT
● Empathy
● Trust
● Learning
● Cooperation
● Responsibility

9. SEPARATING CONCERNS

10. NO OPS? (OR IS IT EVOLVED DEVOPS?)
"We have built tooling that removes many of the
operations tasks completely from the developer,
and which makes the remaining tasks quick and
self service. "
Adrian Cockroft, Netflix, 2012

11. You do not, in fact, want to
communicate with a bank
teller more efficiently
Source: Flickr/cc Ning Ham
https://www.flickr.com/photos/ningham/525770546

12. 12
THE PROCESS
Still involves people and communication
• The most effective processes have
continuous communication - think scrums and
kanban
• Allows for collaboration that can identify
failures before they happen
• Allows for feedback to continuously improve
and cultivate growth
• Provides transparency

13. SEPARATING CONCERNS:
WHAT DEVELOPERS NEED

14. FOCUS ON IMPROVED
APP ARCHITECTURES &
DEVELOPER WORKFLOWS
● Cloud-native app development
● Collaboration
● CI/CD
● Issue tracking
● Source code control
● Code review
● IDE
● xPaaS
Source: Esti Alvarez cc license

15. 15
MICROSERVICES

16. 16
MICROSERVICES ARE NOT SOA. REALLY!
Source: PWC
Lighter-weight communications
protocols
Improved understanding of
functional separation
More open source and
vendor-neutral philosophies
Scale-out infrastructure
standardization and automation

17. 17
SIGNS YOU MIGHT NEED
MICROSERVICES
Source: Daniel Pratts CC/flickr https://flic.kr/p/7RE6yc
● Having trouble coordinating function teams like
DBAs and UI engineers
● Brittle apps. Minor changes cause major
breakage
● Your CICD process is bogged down by big
deployments
● Different teams keep reinventing the wheel (in
gratuitously different ways)
● Hard to experiment

18. 18
DESIRABLE ENTERPRISE CI/CD WORKFLOW
myRepo
Project
Repo
CI
Commit Push
Pass/Fail
Local Test
Build
Repo
CD
Release
Repo
Monitor
Build Test
Review/
Appr
Deliver Deploy
3rd
Party

19. 19
CONTINUOUS BORING
DEPLOYMENTS
● Software (trunk) is always deployable
● Everyone is checking into trunk daily (at
least), not feature branches
● If the build breaks it is fixed in 10 minutes (all
hands on deck)
● Deployment is a low-risk push button affair
● Blue/Green and Canary deployments

20. SEPARATING CONCERNS:
WHAT OPS NEEDS

21. FOCUS ON PROVIDING CORE SERVICES
AND GETTING OUT OF THE WAY
● Deploy a modern scalable container platform
● Enable automated developer workflows
● Mitigate risk and automate security

22. COMPREHENSIVE CLOUD-NATIVE INFRASTRUCTURE

23. OPERATED AT SCALE ACROSS HYBRID CLOUDS
● Different aspects of scale:
○ Large scale workloads
○ Diverse workloads (batch and services)
○ Complex resource management (QoS,
latency sensitivity, etc.)
● Focus on lightweight containerized instances
● Orchestration and resource management

24. 24
THE RIGHT WORKFLOW
Repeatably automate for consistency
● Goal is repeatable automation
● Configuration as code
● Monitoring and alerting strategy
● Initially pipelines may be very
different for traditional vs.
cloud-native
● It’s a journey that evolves

25. 25
LOGGING WITH EFK STACK
● ElasticSearch, Fluentd, Kibana
● Based on log aggregation
● Event system - all events container,
system, kubernetes, captured by
EFK and issues or errors
● Good for ad hoc analytics
● Good for post mortem forensics
because of extensive log information

26. 26
MONITOR AND MEASURE AGAINST METRICS
Metrics tools tend to make more use of APIs than logs.
You need to figure out your organizational needs.
Hawkular is ideal for large scale
central IT teams with lots of apps
Prometheus is ideal for WebScale
DevSecOps

27. MANA
Reuse
AutomationMicroservices Immutability
Pervasive access
Speed
Rapid tech churn
Flexible deploys
Containers
Software-defined
MANAGED RISK
Dev Ops

28. INTEGRATE SECURITY
"Our goal as information security architects must be to
automatically incorporate security controls without manual
configuration throughout this cycle in a way that is as transparent
as possible to DevOps teams and doesn't impede DevOps agility,
but fulfills our legal and regulatory compliance requirements as
well as manages risk. "
DevSecOps: How to Seamlessly Integrate Security Into DevOps
Gartner. DevSecOps: How to Seamlessly Integrate Security Into DevOps. September 2016. G00315283

29. MAKING CONTAINERS SECURE AND TRUSTED
ISOLATION
OF HOSTS
ARE SOURCES
TRUSTED?
WHAT’S INSIDE
CONTAINERS
TRUST IS
TEMPORAL
Host OS + SELinux
maintained by trusted
kernel engineers and
frequently updated.
A validated supply
chain helps ensure use
of tested and patched
software.
Red Hat + Black Duck =
secure, trusted model
for validating
container contents.
New vulnerabilities are
identified daily and
containers become
stale over time.

30. TRACK AND
VALIDATE
THIRD-PARTY
TOOLS
AND
COMPONENTS

31. GETTING STARTED

32. QUESTIONS TO ASK
● What’s the business problem?
● Where am I today?
● How big are my teams?
● What skills do I have (or can hire)?
● On-premise and/or public clouds?

33. THANK YOU
plus.google.com/+RedHat
linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHatNews