It's a tad annoying for us kinda-sys-admins that run full stacks in AWS (or other cloud services) and have to maintain not only domain knowledge for the code we're writing to run on the stack, but the server architecture and services of the OS we choose. My time is limited, and Upstart scripts have been written and run wonderfully.
Ubuntu smooths out many things, which is why I (and I guess many others) choose it for my main server OS. I'm glad to hear 14.04 LTS will still have Upstart support, but this means I have to put "move to systemd" as a medium-range ticket, which is sadly more time wasted.
Go progress! But comon, progress! Stop making more work for me. :)
On the other hand, you'd be feeling quite differently if your AWS stacks currently consisted of RedHat or CentOS (as they oftentimes do for larger/enterprise environments).
I agree, you drew the short stick on this particular transition, but overall, this is a win for sysadmins in the long run, as it seems like all the major distros[0] are moving towards systemd.
Systemd isn't that much more to get used to if you already know sysvinit, and this way your scripts will be more portable to other distros, not less.
[0] IMHO, Gentoo isn't a distro so much as a meta-distro - "create your own distribution".
Not sure about the first part of your comment as neither RHEL nor CentOS use systemd right now (in fact RHEL 6/CentOS 6 uses upstart).
RHEL 7 will be systemd based, but it isn't ready (yet), and in my experience people tend to stay in the major release they're in instead of upgrading. So it will be a long time before systemd is really widespread between RHEL/CentOS users.
RHEL6 was released in 2010. That's why they are "still" using Upstart, because systemd didn't exist when RHEL6 was being qualified. Fedora (which is upstream/testing for RHEL/CentOS) switched to systemd years ago. 3 releases ago at least. RHEL is the equivalent of what Fedora was a few years ago, plus testing and bugfixing by people that get paid from the billions in support contract money that Red Hat pulls in every year. RHEL7 betas and rcs have been available to server admins under contract for a while, they are likely figuring out upgrade issues currently, and when it comes out they probably will switch over a lot of their machines. All those people have support contracts with Red Hat, the packages are qualified and if something goes wrong they get to call up and complain. If you are coming from the Ubuntu world RHEL is Long Term Stable, and upgrading to a new LTS might be work for your admins but the OS should be solid already.
You host most of your stuff on a public cloud which means you don't do a lot of what most sysadmins do. Do yourself a favor and embrace it. Learning new tech and (more importantly) being able to know from experience which is more fit for a specific task is part of the career field you've chosen.
I've professionally managed thousands of RHEL/CentOS/Fedora/Gentoo/Ubuntu/Debian servers in production (and that is just linux!) and not had any real issues learning the variations. Sure you learn different package managers, /etc/sysconfig vs /etc/default, different init scripts, but it is just semantics. That is why sysadmins get paid, to be experts that know the differences.
It is a good thing to know both, embrace the new tech.
EDIT: Oh and I gave you an upvote, this isn't mean to be a snark.
I don't see any difference in volume and complexity between sysadmin work on physical iron and public cloud systems.
Everything you are describing applies to VPS systems.
There are differences, but those have more to do with optimal use of resources, and in that aspect managing cloud systems is actually more complicated. At least the behavior of your own physical systems is consistent and predictable.
Besides touching physical machines, what is it you think a sysadmin for cloud systems doesn't do?
The overwhelming majority of layer 1 monitoring and / or troubleshooting. Using a cloud provider, by design, outsources all of the layer 1 monitoring and troubleshooting to the cloud service provider. If you're not familar with the OSI Layer Model[1], layer 1 == the physical layer ie: hardware.
How often do you need to monitor your EC2 instance for failed physical disks or bad sticks of memory... never :)
Additionally, it depends on how much you outsource to your cloud hosting provider. Many people trust ELB to do the right thing. It is a pretty reasonable product, but having used keepalived + the default builtin LVS[2] that is in every distro kernel out there for more than 10 years, why trust Amazon to do it better? Why use Amazon Dynamodb when there is Riak[3] or Amazon Elastic Cache when groupcache[4] is so awesome?
Using cloud services == outsourcing some/all of the traditional sysadmin work. Many people who consider themselves devops people are smart developers with very little real sysadmin experience. Please don't fall into the trap of considering them exactly the same. It is an interesting hybrid role, but is distinctly different.
> Learning new tech and (more importantly) being able to know from experience which is more fit for a specific task is part of the career field you've chosen.
Yes, but that doesn't mean that any particular instance of having to learn new tech is something ve should celebrate. The opportunity cost of learning this might be that ve doesn't learn something else useful.
Yes with Upstart! Now if only AWS can come up with scheduled starts and stops, the most asked feature (but why stop server why you can keep making money off idle resources?). Then my life is complete.
Thanks, shirke. My current setup is using a AWS EC2 Micro-instance (that I set up on free tier) as a scheduler to start and stop my other instances. Ylastic looks cool but I make it a point to never pay for SaaS, Others who are interested can google the term 'Boto AWS scheduled start stop.'
Ubuntu smooths out many things, which is why I (and I guess many others) choose it for my main server OS. I'm glad to hear 14.04 LTS will still have Upstart support, but this means I have to put "move to systemd" as a medium-range ticket, which is sadly more time wasted.
Go progress! But comon, progress! Stop making more work for me. :)