I remember a board meeting back in 2018 for one of my early angel investments. The CTO was presenting, and he had this incredibly complex slide showing their CI/CD pipeline. It looked like a Tokyo subway map. He was so proud of it. He said it could handle a thousand builds a day. I asked him, "That's great, but how long does it take for a single line of code to go from a developer's laptop to production?" He didn't have an answer. That company is no longer around.
That experience has stuck with me. As an investor in over 200 companies, including some foundational AI players like Anthropic and Scale AI, and having built and sold two of my own, I've seen what works and what doesn't. Technology for its own sake is a death trap. In DevOps, the only thing that matters is speed—not the speed of your builds, but the speed of your business.
As we look towards 2026, the DevOps world is splitting. There are the trends that are actually accelerating businesses, and then there are the legacy ideas and buzzwords that are just holding people back. Here’s my take on what’s hot and what’s not.
What's Hot: The Real Accelerators
1. Platform Engineering as the New DevOps
For years, we told developers, "You build it, you run it." It sounded great in theory. In practice, we turned our best product engineers into amateur cloud architects. They were spending half their time wrestling with Terraform, Kubernetes YAML, and AWS IAM policies. It was a disaster for productivity.
This is why Platform Engineering is on fire right now. The smart move isn't to give every developer a blank check on AWS. It's to build a paved road—an internal developer platform (IDP) that makes doing the right thing the easy thing. This platform provides self-service infrastructure, deployment pipelines, and observability tools that are already configured and secured.
At RemoteTeam, before we were acquired by Gusto, we started moving in this direction. We created standardized templates for new services. The impact was immediate. Our developers could spin up a new microservice in minutes, not weeks. They could focus on writing code, not configuring infrastructure. This is the future. Your developers are your customers. Build a platform that serves them.
2. GitOps: Your Single Source of Truth
I can't stand it when I see teams making changes to their infrastructure directly through a cloud console. It's untraceable, unreproducible, and a recipe for disaster. GitOps solves this. It’s a simple but powerful idea: your Git repository is the single source of truth for your entire system. If you want to change something, you make a pull request.
This isn't just about infrastructure as code. It's about having a complete, auditable history of every change that has ever been made to your production environment. When something breaks at 3 AM—and it will—you can look at the Git history and see exactly what changed. You can revert the change with a single command.
One of my portfolio companies, a fintech startup, was struggling with compliance audits. They had to spend weeks manually gathering evidence of their infrastructure changes. After they adopted GitOps, their audits became a non-event. They could just point the auditors to their Git repository. It was all there. This is the kind of operational excellence that separates the winners from the losers.
3. AIOps is Finally Real
For a long time, AIOps was just a buzzword. It was vendors selling snake oil. But with the explosion in large language models, AIOps is finally starting to deliver on its promise. I'm not just talking about using AI to write code. I'm talking about using AI to operate your systems.
Think about it. The amount of data generated by a modern cloud-native application is staggering. No human can possibly make sense of all the logs, metrics, and traces. But an AI can. It can detect anomalies that a human would miss. It can correlate events across different systems to find the root cause of a problem in seconds. It can even predict failures before they happen.
We're seeing this with some of the more advanced companies I've invested in. They're using AI to automate their incident response. When an alert fires, the AI doesn't just notify the on-call engineer. It starts investigating the problem, gathering data, and suggesting potential solutions. This is a huge leap forward. It means engineers can spend less time firefighting and more time building.
What's Not: The Things You Need to Stop Doing
1. Overly Complex CI/CD Pipelines
Remember that CTO with the subway map pipeline? He was optimizing for the wrong thing. The goal of CI/CD is not to have a thousand steps. The goal is to ship code to customers quickly and safely. If your pipeline is so complex that no one understands it, you've failed.
I've seen teams spend months building the "perfect" pipeline. They add dozens of stages, integrations, and manual approvals. By the time they're done, the pipeline is so slow and brittle that developers are afraid to use it. They start finding workarounds, and you're back to square one.
Keep it simple. Start with a basic pipeline that builds, tests, and deploys your code. As you mature, you can add more steps, but only if they're providing real value. And for God's sake, don't build your own CI/CD tool. There are plenty of great managed services out there. Use them.
2. The "Not Invented Here" Syndrome
I get it. Engineers love to build things. But you have to be ruthless about what you build and what you buy. Building your own database, your own message queue, or your own container orchestrator is almost always a mistake. You're not a database company. You're a company that's trying to solve a problem for your customers.
Every line of code you write is a liability. You have to maintain it, you have to secure it, and you have to operate it. When you use a managed service, you're offloading all of that work to someone else. You're freeing up your engineers to focus on what they do best: building your product.
When I was building MovieLaLa, which was later acquired by Gfycat, we made this mistake. We tried to build our own recommendation engine from scratch. We spent months on it, and it was never as good as the off-the-shelf solutions. We eventually threw it away and used a third-party service. We could have saved ourselves a lot of time and money if we had just done that from the beginning.
3. Security as an Afterthought
If you're still talking about "DevSecOps," you're already behind. Security isn't something you bolt on at the end of the development process. It has to be baked in from the very beginning. Every engineer is responsible for security.
This means shifting security left. It means scanning your code for vulnerabilities as you write it. It means building security controls into your internal developer platform. It means making security a part of your culture.
I know a company that had a major security breach because a developer accidentally checked a secret into a public Git repository. The breach cost them millions of dollars in fines and lost customers. This could have been easily prevented with a simple pre-commit hook that scans for secrets. It's not rocket science. It's just basic hygiene.
My Final Take
Looking to 2026, the message is clear: stop chasing complexity. The hottest trends in DevOps are all about simplification, automation, and developer experience. It's about building platforms that empower your engineers to move fast without breaking things. It's about using AI to manage the complexity of modern systems so that humans don't have to.
If you're a founder or an engineering leader, my advice is this: take a hard look at your DevOps practices. Are they helping you move faster, or are they slowing you down? Be honest with yourself. And don't be afraid to throw away the things that aren't working. The future belongs to the companies that can adapt the quickest. Don't get left behind.
Frequently Asked Questions
Can I switch later if I make the wrong choice?
In most cases, yes. The switching cost is usually lower than people fear. The bigger risk is analysis paralysis, spending months evaluating options instead of picking one and learning from real usage.
What factors matter most in this comparison?
For most founders, the three factors that matter most are: total cost of ownership, ease of implementation, and how well it integrates with your existing workflow. Features are important but often overweighted in decision-making.
Which option is best for startups?
It depends on your stage, budget, and specific needs. Early-stage startups should prioritize flexibility and low cost. Growth-stage companies can afford to optimize for performance and scalability. There's no universal answer.
How often should I re-evaluate this decision?
I recommend revisiting major tool and strategy decisions every 6-12 months. The landscape changes fast, and what was the best choice a year ago might not be today. But don't switch for the sake of switching.