The Best DevOps is NoOps

How’s the monitoring going on the servers? Do we have a memory leak? Have you installed the latest security patches? Let’s launch another staging server to test out the new release. Hey, you made TechCrunch with that latest press release but haven’t set up automatic scaling. Oh wait, the background workers aren’t running on staging.

This will sound familiar if you’re a startup that has chosen to run its own servers. Whether you’re an early-stage bootstrapped startup that’s looking for product-market fit, or an established startup that’s well on its way to growth, take a moment to consider a new strategy for your early stage startup:

The Best DevOps is NoOps.

What is NoOps you ask? In his blog post “I don’t want DevOps, I want NoOps”, Matt Guiltier of Forrester Research defines NoOps as:

NoOps means that application developers will never have to speak with an operations professional again.

NoOps Criteria

At Buttercloud, we like to think of NoOps as making infrastructure selections that meet the following criteria:

• Scalable and abstracted backends

• Easy & fast deployments

• Minimal or no server administration time.

A few examples of NoOps platforms that fit the above criteria are Heroku, Amazon Lambda, and Google Firebase. More recently, that same philosophy shows up in platforms like Vercel, Railway, Cloudflare Workers, and Supabase — managed compute, deploys, and databases with the same core promise: no server administration time. By adopting these platforms, you’re committing to applications with no or minimal backends, that can scale infinitely.

Cost Considerations

Aren’t services like Heroku and Amazon Lambda more expensive than traditional hosting?

Yes they can be depending on your scale and use-case, but take a second to think about your opportunity cost as a young early stage startup where every minute counts. Every hour you put into setting up servers is an hour of time you could have spent building features, pitching your product, or experimenting with different growth campaigns. These all lead your startup directly to profitability and revenue. Your hosting bill may be $50 — $300+ higher every month, but if you are able to achieve profitability 1 month earlier, you’ve already won.

Outsourcing Like Email Delivery

You Already Outsource Your Email Delivery

Most startups choose not to run their email servers. They use services like Mandrill, Mailchimp, or Sendgrid. This isn’t because startups don’t have the technical capability to run their own email servers. It’s because it can be difficult to get email deliverability and uptime right, the small amount these services charge is well worth it when accounting for deliverability and time savings. I’m suggesting you consider the same setup when it comes to your servers. Think about your ideal DevOps process, then start eliminating parts that can be handed off to managed providers.

NoOps in Different Startup Phases

Startups go through a few different phases throughout their lifecycle. We’ve found that the NoOps approach is a better fit throughout the earlier stages of a startup. The graphic below demonstrates the startup lifecycle and a suggested approach of applying NoOps in a time & cost efficient manner:

If your team doesn’t have a full-time DevOps engineer, managed providers will likely do a better job than you scaling the infrastructure, and your team members can focus on building the best product experience for your customers.

When we build early stage products for startups at Buttercloud, we like to off-load as much as we can of the DevOps process early on. For more mature startups, we’ve chosen to get our hands dirty and run a full blown server infrastructure on Amazon Opsworks. For any in-house products we’re building, especially the newer ones — we’re trying to minimize DevOps related work and focus on building out the product & growth experimentation process.

Case Study: The Tizmos Screenshotter

At Tizmos, an educational platform for teachers to discover and share resources, we’ve adopted a NoOps approach on a specific portion of the application. Tizmos runs a data collection service that crawls educational websites and captures screenshots of those pages. One of the major requirements was to be able to scale the screenshotting service to keep hundreds of thousands of screenshots up-to-date throughout the month.

We ended up architecting an Amazon Lambda backend integrated with Amazon API Gateway. The Ruby on Rails backend makes a request to Amazon API Gateway, which fires off multiple Lambda functions that run the actual data processing. The team at Tizmos previously struggled with keeping their infrastructure up-to-date as it related to using headless browsers and running back-end queues to scale the process and handle failures. They now have an abstracted backend hosted completely in the cloud that can scale to millions of screenshots per month — something that would have taken months to complete and get right with a traditional approach.

It may not work 100% of the time for 100% of companies, but the bulk majority of startups can save time, money, and validate their product early as their competitors burn time on building DevOps infrastructures.

If you’re interested in helping your startup scale, check out our Devops-as-a-Service offering for a fixed, affordable, monthly price.