“We’re NoOps—everything is in the cloud and we have no infrastructure to manage.” Before running that victory lap and shifting everyone to the dev side, consider several NoOps risks carefully. I’m really thinking about teams using all-SaaS stacks, especially in martech, edtech and other areas. However, the rise in microservices and serverless means more teams are leaning toward NoOps. At least a few people on your team should always watch for rogue issues on the ops side of the equation.
Locked-in Vendors
Risk: Cloud-based tools in the same category rarely have the same functionality. Once one is selected, you’re committed to its specific features. Moving away from a tool may mean dropping a popular application feature or changing workflow with coding to recreate functionality.
Mitigation: Evaluate unique features and customized data fields carefully before use. Solving data format differences is relatively easy for common fields. Look for tools with well-documented APIs and integrations or connector support for analytics. If there are no integrations out there, that’s a red flag.
Ghosting
Risk: Lock-in becomes a big problem if the vendor ghosts. SaaS startups often meet one of two fates: they are acquired or they crash and burn. A tool critical to your workflow may disappear overnight. In the acquisition scenario, you may have some time and support in migrating from your tool to its successor.
Mitigation: Always have a Plan B for every cloud-based tool in your stack. Competitors are introducing new tools frequently. A trade study done two years ago may be completely obsolete on today’s fast-moving landscape. Proactive migration to newer solutions may reduce vendor risk and improve features.
Limited Observability
Risk: Overheard in a conference recently—Those who develop the code are more motivated to build in useful observability for those in operations if those folks are the same team. In NoOps, that’s not in play. If a cloud-based tool in your stack is down frequently or providing strange results, it may be very difficult to tell what is happening. Observability is often replaced by faith that the SaaS vendor has done its job and you aren’t experiencing a corner case it hasn’t tested.
Mitigation: Observability and monitoring aren’t the same, but when you don’t have observability inside SaaS tools, monitoring helps. Application performance management (APM) tools are emerging with new ways to build instrumentation around microservices. Create test cases with synthetic data to check your functionality—you’ll need these to provide evidence for the vendor in any bug report.
Unoptimized Workloads
Risk: You’re also often at the mercy of the SaaS vendor when it comes to speed of results. It’s a common tripping point to pilot a SaaS workflow with a few users and test cases, and then find out it doesn’t scale when everyone is brought in.
Mitigation: This is one the biggest NoOps risks where ops expertise pays off. Where is the problem, exactly? Application problems may be candidates for workload acceleration—such as running on a GPU (or FPGA) enabled cloud instance. Reporting problems may be better-suited for an analytics tool, which can be run offline with extracted data.
Tangled Analytics
Risk: Every SaaS tool reports different metrics in different ways. Worse, users in a multi-cloud environment face learning and visiting multiple applications to look at data. Different applications report similar facts using different terms. As the tool stack and data sets grow, it takes longer and longer to analyze data.
Mitigation: Dashboards pay off early with one destination for data across the stack. Earlier, I mentioned the need for integrations or connectors—this should be a requirement for tool selection, both in the stack and the analytics tool. Deciding on which KPIs to track in the dashboard also focuses conversation and minimizes digging.
Closing NoOps Risks
There’s also the big topic of multi-cloud security and compliance, probably worth a series of posts by themselves. An Ops team working proactively in tool selection can comprehend many security risks before committing to tools and exposure. More value unfolds over time, as the security posture evolves with discovery of new threats.
The tech pendulum is always swinging. For many organizations, NoOps swings the pendulum a bit too far from DevOps and leaves risks open. A better philosophy is MinOps, where a small team is deployed, watching for and even anticipating problems.
I’d be interested to hear if you’ve tried NoOps and been successful over time, or if you reverted to a MinOps approach.
