With the cloud (it doesn't matter which cloud vendor), truly all infrastructure and application management is software-based now. Consequently, most organizations manage their cloud footprint through code. Some organizations are further along that path, but most strive to achieve 100% infrastructure as code. Additionally, application infrastructure and releases are also managed as code.
Having written code to manage cloud infrastructure, application infrastructure, and application build and release pipelines for years now; I frequently experience deja-vu. That is, I feel that I'm solving the same problem over and over again. Sometimes with different technologies or cloud vendors, but really repeating the same patterns over and over again.
It's time we start thinking of infrastructure code and the various forms of CI/CD pipelines in terms of software design patterns. Patterns that are repeatable and don't need to be "re-invented" for every application, every cloud vendor, or every enterprise.
What is a Software Design Pattern?
This concept was invented and published in 1994 in a book entitled Design Patterns: Elements of Reusable Object-Oriented Software. The book was written by four authors usually referred to as the "Gang of Four" (GOF). While the book originally targeted object-oriented software languages, the "pattern" concept was incredibly successful and has gone on to be applied to many other types of technologies.
Software design patterns usually have the following components:
- Problem Statement -- a description of the problem being solved
- An Example -- a real-world example to help explain the reason the pattern exists
- Applicability Statement -- a description of when this pattern should be considered
- Structure -- a description of the pattern in clear enough terms that somebody could implement it
- Consequences -- Listing of the advantages and disadvantages of using the pattern. This section also includes any limitations
What are the Design Patterns for Cloud Management and DevSecOps?
I'm currently dividing patterns into these categories:
- Build Patterns
- Application Release Patterns
- Infrastructure Patterns
Build Patterns describe how source code is compiled, packaged, and made available for release. Additionally, many organizations apply automated testing as well as gather quality metrics. Build patterns currently identified are:
- Packaging --- Includes any needed compilation. The output is something that can be included in a software release.
- Automated Testing -- Includes any unit and/or integration testing needed to validate packaged software.
- Metric Analysis -- Includes and static code analysis that analyzes code quality and complexity.
Application Release Patterns are patterns used to safely deploy packaged software produced by a build pattern. Application release patterns currently identified are:
- All at Once (Spray and Pray) -- Pattern to deploy software without concern for an outage
- Rolling Deployment -- Pattern to deploy software incrementally to minimize user outage time.
- Blue / Green -- Pattern to utilize cloud technologies to minimize user outage time and provide easy back-out.
- Canary -- Variant of Blue/Green that incrementally directs users to a new version of software to minimize the impact of deployments with defects.
- Infrastructure Maintenance -- Includes network, security, monitoring, logging, infrastructure and much more
- Image Production -- Create hardened virtual machine images often used by multiple applications or business units.
- Mutable Infrastructure Maintenance -- Managing configuration updates for virtual machines that can't easily be destroyed and re-created at will.
Next Steps
Over the coming weeks, I'll document the patterns identified in this post. I'm always interested in patterns I might have missed. Please feel free to contact me with questions, comments, and suggestions. Thanks for reading.