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.
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
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
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
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
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
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.
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?