This article summarises insights shared at the GeekWire Cloud Tech Summit (originally reported by GeekWire, 2017). Speakers included Nell Shamrell-Harrington (Chef), Avi Cavale (Shippable), Mitchell Hashimoto (HashiCorp), and Nathan Pierce (F5 Networks).
The Old World: Siloed Dev and Ops Teams
For much of the history of enterprise software, development teams and operations teams lived almost entirely separate lives. Developers wrote code and threw it over the proverbial wall; operations teams caught it, complained about it, and somehow kept it running. Cross-team communication was the exception, not the rule.
That model collapsed under pressure. As business expectations shifted toward faster release cycles, tighter feedback loops, and always-on services, the old hand-off model became a liability. Something had to change.
What DevOps Actually Means
DevOps is, as HashiCorp co-founder Mitchell Hashimoto has noted, somewhat in the eye of the beholder. At its core, it is a collection of cultural practices, organisational patterns, and engineering strategies aimed at increasing the velocity of software delivery without sacrificing reliability or quality.
Common pillars of a DevOps approach include:
- Collaboration: Development and operations share responsibility for the full software lifecycle, from design through production.
- Automation: Repetitive manual tasks — builds, tests, deployments, configuration management — are automated so humans focus on higher-value work.
- Continuous feedback: Monitoring, alerting, and observability tools return production signals to the team quickly so problems are caught and fixed fast.
- Incremental delivery: Small, frequent changes are safer and easier to debug than large, infrequent releases.
The History and Evolution of DevOps Thinking
Nell Shamrell-Harrington, then a senior software development engineer at Chef, opened the GeekWire panel by walking through how DevOps thinking evolved. The movement grew out of frustrations with waterfall development and the recognition that Agile, while improving development cadence, still left a gap between code completion and production deployment. Practitioners began borrowing from lean manufacturing and systems thinking to close that gap.
Key milestones in that evolution include the popularisation of infrastructure-as-code (treating server configuration the same way you treat application code), the rise of configuration management tools, and the eventual normalisation of continuous integration and continuous delivery pipelines.
Continuous Integration and Continuous Delivery: The Assembly Line Model
Avi Cavale, then CEO of Shippable, built on that foundation by focusing on how CI/CD makes DevOps tangible in day-to-day engineering work.
Continuous Integration (CI) means every code change is automatically built and tested against the existing codebase. Developers merge frequently — sometimes many times per day — so integration bugs surface immediately rather than accumulating for weeks.
Continuous Delivery (CD) extends CI by ensuring that every change that passes tests is in a deployable state. Continuous Deployment goes one step further: qualifying changes are automatically pushed to production without manual intervention.
Cavale’s assembly-line analogy is useful: just as a car factory works on sub-assemblies in parallel before joining them into a finished vehicle, a CI/CD pipeline lets teams work on independent features simultaneously, integrating and validating them automatically on the way to release.
Practical steps to establish a CI/CD pipeline:
- Commit all code — including infrastructure and configuration — to version control.
- Define an automated build that runs on every push or pull request.
- Write a meaningful test suite (unit, integration, smoke tests) that runs as part of the build.
- Fail the build loudly and early when tests do not pass.
- Automate deployment to a staging environment for every green build.
- Gate production promotion with automated checks and, where required, a human approval step.
DevOps and the Networking Layer
Nathan Pierce of F5 Networks addressed a dimension of DevOps that application developers often overlook: the physical and logical networking layer. Load balancers, firewalls, DNS, and application delivery controllers all sit between code and users. When these components are managed manually and independently of the application release process, they become a bottleneck and a source of configuration drift.
Applying DevOps principles to networking — sometimes called NetOps or network automation — means treating network configuration as code, versioning it, and including network changes in the same pipeline used for application changes. This reduces the risk of a deployment being held up because a firewall rule or load-balancer policy hasn’t been updated to match the new application version.
Security Cannot Be an Afterthought: DevSecOps
The fastest CI/CD pipeline in the world is a liability if it ships vulnerable software at high velocity. Mitchell Hashimoto addressed this directly, arguing that security hygiene must be embedded into DevOps practices rather than bolted on at the end of the cycle.
The pressure to ship fast — whether driven by business deadlines or executive impatience — creates conditions where security checks get skipped or deferred. The antidote is automation: when security scanning, secrets management, and compliance checks are integrated into the pipeline, they cannot easily be bypassed under schedule pressure.
Approaches to embedding security into DevOps (often called DevSecOps):
- Static analysis (SAST): Run code-level security scans automatically on every build.
- Dependency scanning: Check third-party libraries for known vulnerabilities as part of the build process.
- Secrets management: Never hard-code credentials. Use a dedicated secrets store (such as HashiCorp Vault) and inject secrets at runtime.
- Infrastructure hardening: Encode security baselines as policy-as-code and validate them in the pipeline before any infrastructure is provisioned.
- Dynamic analysis (DAST): Run automated penetration tests against staging environments before promoting to production.
Key Takeaways for Engineering Teams
Across all four speakers, a consistent theme emerged: DevOps is not a product you buy or a title you give someone. It is a sustained organisational and engineering discipline. Getting it right requires:
- Breaking down the cultural wall between development and operations before worrying about tooling.
- Starting with version control and automated testing — these are non-negotiable foundations.
- Treating infrastructure, configuration, and network policy as code, not as manual processes.
- Integrating security scanning into the pipeline from day one, not as a release gate added later.
- Measuring outcomes (deployment frequency, lead time, mean time to recovery) to prove the approach is working and to identify where to improve.
DevOps done right does not mean moving faster at the expense of stability. It means building systems and practices that let you move faster because reliability is built in.