Ditch Chef, Puppet, Splunk and snyk for GitLab? That's the pitch from your new wannabe one-stop DevOps shop "We want GitLab monitoring to be a complete replacement for DataDog," GitLab's director of product, Eric Brinkman, said yesterday. And he didn't stop there, referring to a whole swathe of "tools that GitLab can replace" at the firm's Commit event in London. Around 300 or so developers attended the day at an 18th-century …
[Sijbrandij:] "It is not so much that applications get moved, because that's super costly. But you could say all new applications will be on a different cloud from now."
And thus it was acknowledged that IT shops must encompass the skill sets to indefinitely drag the baggage of applications developed for what previous generations thought was to be the one and only platform, each with its own quirks and foibles, never actually migrating to a single underpinning, forever dealing with integrations reliant on tenuous agreements and bits of string,
Just like their ancestors, victims of management decrees. "All new systems will be built in PL/I." "All new systems will be built with a client/server architecture." "All new systems will target OS/2 as the client." "All new systems will be web based." "All new systems will be cloud based." "All new systems will target AWS." And so on and so forth, ad infinitum, from now until the end of time, world without end, forever and ever.
All they need to do is provide something that works without the horrific complexity of using the current options which are traditionally open source in having to edit multiple text files or even having.to learn to program in Ruby to use!
Just look at Microsoft's Dev Ops and configuration management tools for a better way for instance.
But sometimes things are only complicated because nobody has tidied them up.
Software can end up like a matryoshka doll with layer built upon layer built upon layer. Each layer is constrained by the one below it, probably includes convoluted hacks to work around the limitations of the lower layers, and introduces quirks and deficiencies of its own. Removing some of intermediate layers can often reduce complexity, improve performance and eliminate bugs.
Likewise, when you end up with a ragtag bag of libraries and tools they often have a lot of overlap that can be deduplicated. You don't have to go all SystemD to realise even giving them a consistent interface can make things simpler. (I just removed a bug where two libraries were using two subtly different coordinate systems and nobody had noticed.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
