Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

391–400 of 435 posts

Re: The sad state of sysadmin in the age of containers (2015)

#391

Earlier quoted context omitted.

A good sysadmin would not look like they are doing much work (everything is humming along and can self-heal minus physical problems), but a good devops person is constantly busy.

I sort of agree but a good sysadmin was never idle on the inside. I'm seeing good devops people getting worked well beyond what I'd consider reasonable expectations i.e. "Oh, look, you can do everything! Here's everything!". They're being perverted into a role having a full load of pure operations with shit for processes (and, often, systems) and an expectation that you have time to automate and shore up all the shit…

This is exactly my sentiment and why I moved away from SRE and back to SWE. I felt busy all the time doing development of tools and infrastructure while at the same time aggregating the role of operations.

Never having the time to properly finish a project that I was proud of delivering, turning those into services so we could leverage self-servicing was a dream that most of the time never happened, we were left with half-done systems requiring tons of manual intervention (lots of toil) while having to move fast to the next thing...

Re: The sad state of sysadmin in the age of containers (2015)

#393
post #302

Earlier quoted context omitted.

I like ansible with vagrant as well - it makes for a nice clean way of deploying to development environments while also been nicely 'self' documenting and not limiting (you can drop back to shell), it's a lovely tool for the most part. Edit: The thing I really like about Ansible is how unsexy it is, it's just a nice sane way of doing largely what you could do yourself with ssh and bash but in a language that doesn't…

It would be even nicer if people weren't advocating it as a configuration management system, only as what it is: a deployment system.

I think I achieved my perfect balance of tooling for current systems with Ansible and Docker.

Ansible automates even provisioning in AWS. I never really liked CloudFormation's way of creating stacks, so I began to use Ansible to document the application's stack, have used it to deploy systems running in EC2 with RDS, ElastiCache, SQS, SNS, DynamoDB, etc.

After provisioning/configuring I'd end up with an instance in EC2 with Docker installed and from there our CI/CD would just trigger the deployment playbook that simply would do a `docker pull` of the version tagged for release and start the container.

Ansible helped to also install our Splunk forwarders as running it from Docker was a hassle still not so long ago, so we would have the best of both worlds: configurability of the host machine completely with Ansible and packaging and predictability of deployment through Docker.

I advocate this stack as simple enough to learn and use with widely used tools without their fancy (and often broken) features. Even though they can be still a bit immature, they are production-ready enough.

Re: The sad state of sysadmin in the age of containers (2015)

#395
post #305

Earlier quoted context omitted.

Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file. Nothing to do with ansible really, except that ansible allows to prevent that easily.

> Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file. Wrong. Teach your sysadmin not to overload a single service with different functions (debugging channel, user-facing shell service, running remote commands, file upload, and config distribution channel), especially not the one that should not be used in batch mode, without human supervision. When you write a…

Are you advocating running multiple sshd instances in this case?

Re: The sad state of sysadmin in the age of containers (2015)

#396
post #276

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

> Modern devops, with its million tools that break backward compatibility every month sometimes becomes the running joke at lunch. Ironically, modern devops and its million broken tools are a primary source of revenue for cloud providers, helping pay for your lunch in the first place.

You might be on the point, efficient designs are bad for cloud providers. On the other hand, shitty designs that get hacked are bad PR for them.

Thing is, none of it matters. Bottom line matters.

They care to attract company decision makers. Decision makers are engineers in small to medium businesses, and managers in big ones. Sadly, its the big ones that matter for bottom line. So target is mid management, flashy power point presentations and 'conferences' that allow for justified travel and stay.

Good mid management, with tech background, exists, but is a minority.

Not all is lost, truth is out there (c) Mulder :))

Re: The sad state of sysadmin in the age of containers (2015)

#397
post #23

The clearest explanation of why this happens is at the end: Before, admins would try hard to prevent security holes, now they call themselves “devops” and happily introduce them to the network themselves! 1) The merging of devs into the sysadmin role was a product of: the work of sysadmins (particularly systems change control and security compliance) not being valued in our culture. 2) Devs delighted to be free of th…

> shackles placed upon them by sysadmins Well, potentially unpopular opinion here, but an awful lot of sysadmins brought their looming obsolesence on themselves. I'm an app (as in "a program that runs on a computer", not an iOS add-on) developer, always have been. I get requirements from the business types, code it up in vi or Eclipse or whatever, get it working, and then they (the business) want to deploy the workin…

> e-mail asking you what steps are needed to deploy an app into production since it's not documented anywhere

Two points, immediately:

1) Can I autoscale the app, as in what is the data/files persistence model?

2) Did you write Readme.md with a) build steps b) networking requirements c) data sources d) authentication model e) database ACID requirements ?

Re: The sad state of sysadmin in the age of containers (2015)

#398

Earlier quoted context omitted.

I know our SREs once screwed the config for sshd, and considered themselves very lucky that they had puppet on the machines and could push a fixed configuration (if they had used exclusively ansible, that'd be the end of it - no way to connect or to deploy new configuration) [edit] To clarify - ansible is great, and we use it. Just saying that, as everything, it still has (sometimes subtle) downsides in various scena…

Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file. Nothing to do with ansible really, except that ansible allows to prevent that easily.

Yes, because everybody knows that testing eliminates all bugs.

(it's not that testing is useless - far from it; but I thought the HN crowd knows better than to respond to issues with "that's because you didn't do enough testing!")

Re: The sad state of sysadmin in the age of containers (2015)

#399

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

I am genuinely curious, how much ops is hand written in just plain old bash or simple scripts?

The Bash scripts are now contained in Docker files. Much better :)

Re: The sad state of sysadmin in the age of containers (2015)

#400

Earlier quoted context omitted.

> Ansible is great. Used that for management hundreds of machines at multiple jobs. It's been bought by RedHat, it's well maintained and I think it will have the brightest long term future. A lot of folks I know have been bitten by Ansible's performance (Ansible has a central master that runs recipes on each node, rather than having nodes "pull" from a central master).

Ansible has a very, very low barrier to entry. You go from 0 to 100 in a very short time. It makes a lot of sense to use it when you just begin building your infrastructure. Later on you can run Ansible Tower, deploy Ansible agents everywhere, and basically use Ansible under the same client/server model like all the other tools. Salt is eerily similar to Ansible, it's just geared towards client/server. Being experien…

You can also get Tower's functionality with the free version called AWX, although not as polished. https://github.com/ansible/awx
Post reply on HN