Creating software for sysops | Hacker News Reader

Creating software for sysops

plumbr.eu

24 pointstheotown17 comments

Damn straight. Having been on the other side of the fence - having a budget and a few thousand servers - a vendor that wants a hundred grand and can't even be bothered making an rpm has a lot to do to make up for it.

Your agent isn't any more special than the hundred other pieces of software on the same box.

And what if your boss wants you to deal with them not providing any RPMs, because the stuff has already been paid for?

Good question. If I wasn't in the position of having a budget, I'd:

a) first approach the company asking me to send a link to their packages, making sure their support staff know the company expects packaged software.

b) I'd package it myself, letting my boss know my time was spent doing work the vendor should have.

Sure, but I can turn that argument around too. If the software has to support 20 platforms, then your one platform that happens to use RPM is not any more special than the other 19. If they make RPMs they can charge your boss extra. Maybe your boss has a tight budget and chose to push the integration step to his/her own people.

- Windows MSI

- RHEL/CentOS rpm

- Ubuntu/Debian dpkg

The practical amount of BSD, SmartOS and Arch users in medium and large businesses is close to 0%.

(Just interested from an academic perspective) What are the decision making criteria for your boss? Which parameters trump "Do my guys want to use that stuff"?

Not the parent, but sometimes there are cross platform monitoring / auditing applications pushed from Security, where either the Linux or Windows version is clearly a second class citizen.

ssh -X is the usual approach.

Wouldn't it be better to make your own RPMs from their installer, using something like CheckInstall? Or is it too unreliable?

checkinstall has worked okay for me in the past.

However, "Enterprise Software Vendors" often stipulate that if you do not install their software, using their method, on their approved platforms, you will get no support whatsoever.

This is very true, particularly when dealing with large vendors. Unlike smaller companies, enterprise software vendors have large independent organizations. Support department often does not have direct access to developers and have to rely on published docs, etc. Support people also get measured according to their "performance" closing tickets.

As a result, if you don't use standard methods to install the software, etc. they often have no clue and quick to wash their hands off the problem even when the problem is clearly nothing to do with how you installed the software.

Never mind that you're probably paying significant amounts every year (15-25%) for support and maintenance ...

I've been on both sides of that (or all three sides if you count the vendor, too).

Boss: use it to leverage either a better deal, or extra support hours, or make them package it. (Unless it is Oracle. Then you just bend over).

Tech: Tell the boss exactly how much it sucks, and how you wonder if this vendor actually knows what "operate at scale" means. Take the extra support hours and get them to write an installation package.

Vendor: Oh, shit. Another thing to add to my list of 1000 things to do. Is this or feature X more likely to be useful? Damn, let's just offer extra support hours.

This is a constant tension in software, when the people who sign the cheques don't use it themselves and so never feel any of the pain (just pick up a sweet bonus for saving so much money on the support contract).

Someday for example I'd like to visit SAP in Germany and see how they book their vacations and submit their expenses. It can't be with their own product. I'll wager they still use paper.

Sorry, I downvoted you by mistake.

As a developer and amateur sysadmin, I'm moving our own whole system to native packages. Dealing with ad-hoc installation mechanisms is just too painful.

This is a refreshing change - contrast with the MongoDB guys who sell it as "you don't need DBAs" then the devs chuck it over the fence into production and wonder why everyone now hates them.

Fantastic list of things sysops wants, no, needs, no, requires out of "good" software. Kudos to Plumbr for understanding and working towards that goal.

although not exactly for the Java world (but not necessarily so), even since i attended PyData recently, i've been capturing requirements/ideas for a "Python [c]Profile data visualizer web application spec":

https://docs.google.com/document/d/1tPhW2FLjHG47rS6xJGzP6R30...

and this article was a good read.

Reply on news.ycombinator.com