4 ms·

Many places are rolling this type of sysadmin work up into DevOps. This scares graybeard sysadmins, because they see DevOps automating them out of a job. Nope,

Many places are rolling this type of sysadmin work up into DevOps. This scares graybeard sysadmins, because they see DevOps automating them out of a job. Nope, not really. just wait till you move to a new job, and you inherit a docker/rockit/etc system. You need to patch openssl/glibc/etc however, half the containers are built with an old build system that's been replaced. You've got 15 containers based on fedora20 which is EOL, one of your apps relies on a bug in fedora21 which is also EOL. Oh yeah, its just you, you have no resources, and you're on call to fix it when it fails (yeah devops is a nice way of saying unpaid overtime) Oh and you need to replace two of three physical hosts, but you can't hot migrate containers, and you loose quorum on your cluster if you take one of the hosts down. Looks its as simple as this. I'm a sysadmin, I know I know, you think I can't code, you think I know nothing about programming. This is bollocks. Two things: One I've seen this all before. Containers? yeah thats just fancy batch processing. Two, you know how when ever you log in to a new machine and all your files are there, not only that its faster than your laptop? thats me, making things fast. Its my job. DevOps is a step up Not really, it seems to be a way of getting devs to do out of hours. Or allowing people with no experience of programming doing programming, or no experience of infrastructure doing infrastructure. A decent system admin does all of the "devop" things already. If they don't have a build system, git/svn controlled config management, they they arn't real sysadmins, they are over reaching helpdesk monkies. fucking god awful at configuration management dunno what you've been using, but I can configure 5000 machines inside 15 minutes with 10 lines of code and one ssh command. A few years ago, you would have functional silos Only in certain companies. If you have politics, you'll get silos. Docker/Maven/etc. are the abstraction layer between the teams can't use technology to overcome procedural problems. If your teams arn't talking, your infrastructure is going to be shit. If your teams don't think about others when they produce their products, then things will fall through the cracks. An example, Say you want 10 VMs of x size. If you have a coheesive system, you could email/phone/talk to a guy and you'll have some machines. If your provisioning team had thought ahead they'll have made an API that spins up machines, ties them to your accounting code, and configured them to your environment. That's not technology, that just good practice.

exelius 12y ago
Bad DevOps is bad. But bad DevOps is basically no worse than what people were doing before: you'd just have a bunch of VMs running fedora20 with no way of easily patching all of them at once. Except some of the VMs may be running fedora23 because they were part of an expansion that happened 2 years after the original set and the guy who deployed them couldn't find a fedora20 image. And at least with a container, you can more easily use AWS for spare capacity/redundancy while you migrate servers. DevOps doesn't fix every sysadmin problem, but it gives you a lot more options that can be developed/deployed in a small amount of time. DevOps is bad when you take your worst developer and say "do sysadmin tasks and still write application code". It works much better when you take an experienced sysadmin and embed them into a dev team. Make them do code reviews on deployment scripts with a developer, assign tasks within sprints, etc. Code reviews aren't because you don't know how to code -- IMO the primary benefit of code reviews is the education of the reviewer. Likewise, the sysadmin's struggles become the developers' struggles, and the developers are more likely to write applications that are easy to support if they have some role in supporting them. Every company over a certain size has politics. It's unavoidable. Maybe Google doesn't -- I don't know. But not every company can be Google. You can't use technology to overcome process problems, but you can and should use technology as a part of a redesigned, better process. DevOps gives you more options, and has a positive effect on the culture of a development org. It asks them to think of portability and supportability as a concern.
ossreality 12y ago
Sounds like someone who knows their tools and doesn't know the state of the art. >An example, Say you want 10 VMs of x size. If you have a coheesive system, you could email/phone/talk to a guy and you'll have some machines. If your provisioning team had thought ahead they'll have made an API that spins up machines, ties them to your accounting code, and configured them to your environment. That's not technology, that just good practice. Or you know, I have a fleet of ten thousand machines that I can schedule whatever docker containers I want into. Your nonsense about software being out of date and EOL is absolutely no different than a scenario without docker. At least docker gives you the change to have a declarative way of reconstructing the image. I can't honestly believe that was what you went with to try to make containers look bad. You're just showing your age is all.

exelius 12y ago

Bad DevOps is bad. But bad DevOps is basically no worse than what people were doing before: you'd just have a bunch of VMs running fedora20 with no way of easily patching all of them at once. Except some of the VMs may be running fedora23 because they were part of an expansion that happened 2 years after the original set and the guy who deployed them couldn't find a fedora20 image. And at least with a container, you can more easily use AWS for spare capacity/redundancy while you migrate servers. DevOps doesn't fix every sysadmin problem, but it gives you a lot more options that can be developed/deployed in a small amount of time. DevOps is bad when you take your worst developer and say "do sysadmin tasks and still write application code". It works much better when you take an experienced sysadmin and embed them into a dev team. Make them do code reviews on deployment scripts with a developer, assign tasks within sprints, etc. Code reviews aren't because you don't know how to code -- IMO the primary benefit of code reviews is the education of the reviewer. Likewise, the sysadmin's struggles become the developers' struggles, and the developers are more likely to write applications that are easy to support if they have some role in supporting them. Every company over a certain size has politics. It's unavoidable. Maybe Google doesn't -- I don't know. But not every company can be Google. You can't use technology to overcome process problems, but you can and should use technology as a part of a redesigned, better process. DevOps gives you more options, and has a positive effect on the culture of a development org. It asks them to think of portability and supportability as a concern.

ossreality 12y ago

Sounds like someone who knows their tools and doesn't know the state of the art. >An example, Say you want 10 VMs of x size. If you have a coheesive system, you could email/phone/talk to a guy and you'll have some machines. If your provisioning team had thought ahead they'll have made an API that spins up machines, ties them to your accounting code, and configured them to your environment. That's not technology, that just good practice. Or you know, I have a fleet of ten thousand machines that I can schedule whatever docker containers I want into. Your nonsense about software being out of date and EOL is absolutely no different than a scenario without docker. At least docker gives you the change to have a declarative way of reconstructing the image. I can't honestly believe that was what you went with to try to make containers look bad. You're just showing your age is all.