Cloud automation can pay dividends. But it’s not a no-brainer. Who doesn’t secretly wish yesterday’s automation successes would reach the speed of light tomorrow? Why can’t we escape hands-on cloud operations work to unlock software development nirvana (aka frictionless, faster development and deployment processes)?
Change. It’s the other constant.
Let’s take a closer look at what it takes to successfully overcome the unknown costs of a change in your cloud stack. Two concepts have recently come into vogue in reducing friction between developers and their cloud infrastructure: NoOps and ZeroOps.
Spoiler alert: neither describes a perfect ultimate outcome.
Instant perfection is the enemy of useful automation
Automation for streamlining operations has long driven the goal of quashing imperfect “human middleware” in software change management. Who doesn’t love the idea of letting machines handle such tasks instead? An environment where there’s virtually no hands-on operations work can deliver a faster, more frictionless development and deployment experience. The ideal result? Shorter, more predictable lead time for changes.
Ergo: DevOps, the magic that works through transparent cross-functional collaboration…except when it doesn’t.
Is “the” new answer to DevOps now 'ZeroOps' or 'NoOps'? Well, no. The two terms are quite similar. And both have a theoretical limit. That said, they both set forth a useful goal, even if that theoretical limit is never reached (credit Zeno’s paradox).
- NoOps is a concept that aims to completely automate an environment when deploying, monitoring, and improving software operations.
- ZeroOps is a set of practices that result in developers focusing solely on coding and creating, with 0% of their time spent on operations or infrastructure.
Look quite similar? ZeroOps is potentially a practical path toward a NoOps philosophy. Neither is the secret ingredient that developers need to include to achieve robust, change-proof DevOps. Let’s face it: developers are as human as the rest of us. It can be hard to admit that
- (a) no code is always written correctly the first time
- (b) there is no such thing as code isthat is 100% change-proof.
Instead, think of ZeroOps is a diet reduce the infrastructure and operations expertise required of developers. The goal is to shift key burdens off of your dev team so they can focus solely on writing and improving code that delivers winning results from your product and services. Then, focus on putting in more processes and resources to improve the product, infrastructure, management, security, and everything tied to platform operations.
How DevOps fits
DevOps is not going away any time, nor should it. Rather, what ZeroOps practices bring to faster, more reliable cloud software development is the emphasis on a better developer experience for writing and improving code unique to the product and the business it supports.
Put another way: you could make your software stack serve both specific business needs and general-purpose platform tooling. It does not mean that every software engineer should shoulder the burden of mastering everything everywhere all at once.
The secret to creating a virtuous cycle between development and operations? Establishing more robust processes with more unambiguous management of resources.
This is what the founders of DevOps envisioned. Neither ZeroOps nor NoOps should be thought of as separate from DevOps. It takes a clearer division of labor build up virtuous cycle of feedback and improvement. Incremental progress, with a clear cadence and managed feedback, is the best way to build momentum.
How do NoOps and DevOps improve the developer experience? If you are ready for that next level, it means rethinking how developers participate in the system lifecycle, from development to deployment, end to end. Ideally, this is achieved in two ways:
- through automation that removes repetitive toil;
- and improved methodologies that reduce ambiguity and the likelihood of unforced errors.
The core benefit of tools positioned as NoOps or ZeroOps is the focus on increased automation in infrastructure provisioning and CI/CD. This is not the same as touchless, seamless operations.
Don’t expect magical automation that eliminates the continuous discovery and learning needed to resolve problems and troubleshoot. No tool can achieve and maintain perpetually unbreakable perfect full-stack software. (We’re talking to you, ChatGPT.)
Much of this is not new. It’s been around in offerings like Platform as a Service (PaaS) and Function as a Service (FaaS, aka ‘serverless’). For what it’s worth, they all achieve automation at the cost of imposing limitations on flexibility and customization. As we’ll see in a moment, among the most important limitations to overcome is improving the feedback loop at various levels of abstraction.
To DevOps and beyond: always be upgrading
The secret to creating a virtuous cycle between development and operations? Establishing more robust processes with more unambiguous management of resources. Seen holistically, converging these “(Whatever)Ops” approaches means focusing on three frontiers of automation:
- infrastructure management
- operational runtime management
- troubleshooting for feedback
Addressing the “three frontiers of automation” from both a process and tools perspective is your best bet for the secure, cost-effective automation required can make your product or business workloads more successful.
Process perspective
Such a platform strategy must include the following process-driven practices
- Effective, consistent and secure infrastructure, provisioned automatically, with all the best practices for cost visibility applied
- CI/CD with all the necessary quality gates like static code analysis for better tech debt management and vulnerability checks, plus automated release process;
- Unified operational runtime for containerized workloads with built-in runtime protection, backed by log aggregation and application observability
- Infrastructure and operational runtime monitoring with automated standard operating procedures and incident remediation via automatable runbooks
- The aim is not instant perfection. Rather, it’s in adopting an approach that reduces friction in learning. It’s real-world learning from operations that holds the key, and learning enables a mindset of “always-be-upgrading”.
Tooling Perspective
Key tools can complement but will not replace real human learning in your “always-be-upgrading” technical practices.
- Automated tools for initial readiness/risk assessment
- Workload migration and containerization tools
- Centralized access control, audit, and cost management
- Landing zones to set up a secure, multi-account environment based on best practices
- Single-sign-on to securely connect workforce identities and manage access centrally based on job roles
- Transparent access to new learnings driven by real-world operations
Odds are you already have several, if not all, of these. But without process anchors that drive feedback and learning, your Ops challenges will escalate in the wrong direction away from zero.
From practices to outcomes
How will you know this approach is actually working? And how will you convince your collaborators that these practices translate into a better way to work? Here are the benefits you want to head for.
- Optimized software development throughput. As environments and delivery cycles are increasingly automated, it can reduce mismatches between developers and infrastructure.
- True cloud elasticity: Dynamic serverless and cloud resources under the hood are driven by automated ops monitoring and maintenance.
- No manual intervention: As more standard operations are automated, and less human intervention is required, it eliminates room for human error.
- Shorter time to market, with more time focused on development, with features and improvements that improve customer loyalty
- More schedule flexibility, leaving more time to create other revenue-generating opportunities.
When a platform relies heavily on auto-scaling and rebalancing, allowing dynamic resource adjustments, you pay only for what you consume. Unit Economics begin and end with cloud elasticity and the consumption-based cost model. Resource sizing self-adjusts over time, ultimately solving over and under-provisioning problems.
Be skeptical of anyone who says they will get all these right the first time.
Mind the gap
Not every infrastructure or workload is ready to embark on the DevOps and ZeroOps journey on Day One. There are many reasons.
- (1) Not every application can be easily containerized. Application modernization (which can include, but is not limited to, refactoring, code transitioning, and more) is likely an inevitable first step, especially when you need to address an application stack that has one or more of the following characteristics:
- a multi-process and/or monolithic application
- Is stateful
- Has hard dependencies on resources such as local storage
- (2) Operations will not vanish to “Zero”. Sustaining competitive advantage for your product/platform depends on your ability to manage and adapt changing constraints across:
- infrastructure requirements
- metadata about services and who uses them
- related costs and changes in resource consumption over time
Conclusion
What’s the best way to discuss this division of labor with your engineering leadership team beyond just shopping for more DevOps tools? (There is an endless variety of tools to choose from and even more vendors eager for you to do so).
Before putting more tools into your shopping basket, bear in mind that:
- Compliance cannot be outsourced, as varying regulations apply wherever the cloud that runs your applications resides
- Your Ops team needs to oversee end-to-end security, privileges, and cyber threat prevention, at every step, from pull to production and back
- Don’t neglect the nuts and bolts: built-in runtime monitoring, fine-grained RBAC/ABAC, privileged access audit, and patch management.
Yes, you need a skilled and experienced operations team, and you likely always will. Don’t settle for assigning 1-2 people to be DevOps engineers. Buy or build an operations team that knows how to drive automation in practice, not just in theory. (It does not matter whether ZeroOps is right around the corner or a distant aspiration.) Your developers will thank you for giving them the focus and flow for true coding productivity. After all, your dev team is the one that holds the keys to your product and business to next-level success.
