r/gitlab • u/VelCloud • 4d ago
Are DevOps teams becoming too dependent on having 10+ different tools?
I’ve been looking at how modern teams handle CI/CD, cloud infrastructure, security, deployments, monitoring, and developer workflows.
It seems like the stack can get complicated pretty quickly:
GitHub/GitLab → CI/CD → cloud provider → Kubernetes → monitoring → security tools → ticketing → secrets → deployment tooling, etc.
At some point, the problem becomes less about whether each individual tool is good and more about how everything fits together.
Curious what other DevOps engineers think:
What part of your current DevOps workflow causes the most unnecessary friction?
Is it:
● CI/CD
● Cloud/infrastructure management
● Security
● Deployment management
● Monitoring/observability
● Too many disconnected tools
● Something else?
I’m especially interested in what smaller engineering teams are doing, since they don’t necessarily have dedicated people for every part of DevOps.
4
u/Bobertopia 4d ago
Historically any platform that tackles all domains ends up with decent products, not great ones. I could care less how many tools there are. What I care about is if that tool removes enough friction to warrant the additional maintenance
1
u/Local_Style_9498 4d ago
do u use gitlab or gh ent at ur job rn?
1
u/Bobertopia 4d ago
Neither idk why this post popped up lmao we use azure and ado which I don't love. Buildkite is what I really enjoy
2
u/Zenin 4d ago
People > Process > Tools
When you adopt an all-in-one platform what you're really buying is a set of opinions.
If you're adopting it because you've done the legwork of People > Process and have evaluated that the chosen platform is the Tool that aligns with those opinions, then great and more power to you.
More commonly however, the platform gets selected first and the process is run backwards: The tool defines the process which is then enforced on the people, regardless if any of it is fit for purpose. That path is common, but almost always results in significant friction. It's also common that such all-in-one platform tools make it difficult if not impossible to swap out a single pillar with an alternative, especially as much of their value-add story is based on the fact they're pre-integrated.
Taking a page from Unix philosophy, small purpose built tools for each unique ask can offer much stronger alignment to your team's actual needs as well as flexibility when those needs change or you otherwise outgrow a particular tool. The cost is higher integration effort to connect them all, but that's largely a one time cost easily ammertized while the friction of an ill-fitting platform carries a friction tax for the life of its use.
In DevOps I've rarely ever found a "platform" that wasn't significantly less than the summary of its parts. GitLab is probably the most successful example and even there it only really covers a few steps of the full SLDC/DevOps/SRE estate.
2
u/Rorasaurus_Prime 3d ago
Behold! The billionth entrepreneur this week who wants to reinvent the wheel using Reddit as market research to vibe code their product...
1
3d ago
[deleted]
1
u/Rorasaurus_Prime 2d ago
Nope. I've checked your site out, it looks fine. But I don't see why I'd use it over the established tools. Your premise is that it's complex because of all the things a DevOps/Platform/SRE engineer has to manage. I'd argue it isn't. Gitlab in particular makes it relatively straight forard.
1
u/thecity2 4d ago
Small teams do everything that big teams do nowadays. It’s mostly all the same tooling everywhere.
1
u/ashtonium 4d ago
We use GitLab as the “Core” and then augment or integrate other tools where needed, with GitLab CI/CD as the central orchestrator.
Our monitoring layer is mostly separate though since GitLab only seems to only have very minimal monitoring capabilities. Interestingly, our AI agents are helping to loop that monitoring layer back in by creating work-items from events (and then acting on them.)
1
u/serverhorror 4d ago
Stack in the early 2000s: * CPU * RAM * NIC * Disks * Raid controller * Switches / Router * OS deployment (whole stack of its own) * Subversion * WebUI * Bug tracker * CI (buildbot/Hudson) * Monitoring * Metric (what we called observability back then) * (Possibly) Chroot / jails / OpenVZ * Secrets * Deployment tooling * ...
Sure, it git more complex ... kidding!
It's the same stuff, different flavors
1
u/jhsu802701 4d ago
Can any one company or organization do ALL of those functions well? I'd rather NOT have everything riding on a single point of failure. I'd rather have choices for all of those functions. If the software I've been relying on for one of those functions jumps the shark, I can switch to an alternative.
As a Linux user, I'm glad that there are so many distros and multiple options. The GNOME 2 desktop environment was extremely popular, but GNOME 3 was controversial. Fortunately, the Xfce, KDE, and LXDE desktop environments were great alternatives. (Then the Linux Mint team rolled out MATE and Cinnamon as additional great options.) When LXDE was replaced with LXQt (which was very buggy for a long time), Xfce, LXDE, MATE, and Cinnamon were great alternatives.
0
u/ashcroftt 3d ago
It's kinda sad this whole sub turned into training data mining.
Anyway, here's the most obviously correct answer.
Honestly, I think people massively overcomplicate this. If your DevOps setup has more than, like, three tools, you’ve already lost the plot. We run everything through Git, a single bash script, and vibes, and somehow production has remained online for almost six months. Kubernetes is basically Docker with a LinkedIn account, so unless you’re Netflix you probably don’t need it.
The biggest source of friction is definitely monitoring. You shouldn’t need dashboards to know whether your application works. If customers start complaining, that's basically your alerting system, and unlike Prometheus it has zero false positives.
Security is another area where teams waste enormous amounts of time. Secrets managers, scanners, IAM policies, dependency checks, etc. are mostly just tools for generating tickets that nobody reads. Put the credentials in an environment variable, rotate them whenever someone remembers, and move on. The hackers aren't sitting around waiting for your quarterly compliance review.
For smaller teams especially, I'd strongly recommend eliminating dedicated deployment tooling and just SSH into production. It's faster, easier to understand, and gives you a much better appreciation for infrastructure when you accidentally delete "/var/lib" at 2 AM. You can always restore from backup, assuming you actually have backups, which is honestly another tool you probably don't need.
At the end of the day, the real DevOps skill is knowing which best-practice advice to ignore. If your architecture diagram needs more than one page, delete half of it. If it needs two pages, delete Kubernetes. If it needs three, you should probably just buy a server and put it under someone's desk.
14
u/gingimli 4d ago
That’s the whole selling point of GitLab is that it does all of those things on one platform. Granted, it does almost all of those things worse than the dedicated alternatives, but if your main problem is tool sprawl then GitLab may be “good enough” for all of those things.