Book Image

DevOps Culture and Practice with OpenShift

By : Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria
Book Image

DevOps Culture and Practice with OpenShift

By: Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria

Overview of this book

DevOps Culture and Practice with OpenShift features many different real-world practices - some people-related, some process-related, some technology-related - to facilitate successful DevOps, and in turn OpenShift, adoption within your organization. It introduces many DevOps concepts and tools to connect culture and practice through a continuous loop of discovery, pivots, and delivery underpinned by a foundation of collaboration and software engineering. Containers and container-centric application lifecycle management are now an industry standard, and OpenShift has a leading position in a flourishing market of enterprise Kubernetes-based product offerings. DevOps Culture and Practice with OpenShift provides a roadmap for building empowered product teams within your organization. This guide brings together lean, agile, design thinking, DevOps, culture, facilitation, and hands-on technical enablement all in one book. Through a combination of real-world stories, a practical case study, facilitation guides, and technical implementation details, DevOps Culture and Practice with OpenShift provides tools and techniques to build a DevOps culture within your organization on Red Hat's OpenShift Container Platform.
Table of Contents (30 chapters)
Free Chapter
2
Section 1: Practices Make Perfect
6
Section 2: Establishing the Foundation
11
Section 3: Discover It
15
Section 4: Prioritize It
17
Section 5: Deliver It
20
Section 6: Build It, Run It, Own It
24
Section 7: Improve It, Sustain It
27
Index
Appendix B – Additional Learning Resources

Emerging Architecture

Hope is not a design method.6

How do we know our architecture is good? What does good mean? Is good architecture measurable? Have you ever had to operate, support, or fix a system that is poorly architected?

It may be easier to identify some characteristics of what a poor architecture looks like:

  • An unstable and unreliable system that fails regularly in unknown and unexpected ways.
  • The system is slow from a user's point of view.
  • It does not scale well with increased users or loads.
  • It is hard to upgrade because one small change requires everything to be re-deployed, which is slow and costly.
  • It is dependent on clients or other systems and cannot be easily modified or changed without changing the other systems as well.
  • It has a lot of complex business functions that are buried in the database, that may involve triggers, and cannot be easily changed due to a complex database schema with unknown side effects when modified...