AWS Quietly Scales Back Some DevOps Services

AWS has quietly halted new customer onboarding for several of its services, including the once-touted CodeCommit source code repository and Cloud9 cloud IDE, signaling a potential retreat from its comprehensive DevOps offering.

The stealth deprecation, discovered by users encountering unexpected errors, has sent ripples through the AWS community, with many expressing frustration over the lack of formal announcements and the continued presence of outdated documentation. AWS VP Jeff Barr belatedly confirmed the decision on social media, listing affected services such as S3 Select, CloudSearch, SimpleDB, Forecast, and Data Pipeline.

It was a stupid idea to begin with. No wonder.

[Anonymous Coward]

DevOps is just a dream by managers that they can get the developers roped into operations, fire the sysadmins, and keep the coders on the hook for weekend and after hours work, saving a penny or two. In reality it just misses the mark because of severe skills gaps, the propensity of "devops" shops to underpay, and the burnout it causes. My radar always goes up when I hear someone claiming to be technical use the term. Their stock goes down in a hurry and I figure they are gunning for a management job.

Re: It was a stupid idea to begin with. No wonder.

[reanjr]

I don't know if this is voice typing failure or an eggcorn, but the word you are looking for is "cum", not "come".

Re:

[Local ID10T]

So many people don't understand plain Latin anymore....
/Sir Humphrey Appleby

End of prior generation's management party

[will4]

The cloud is at the post-disillusionment phase of the tech hype cycle, where enough large companies have burned through all of the CIO and upper manager 'vision projects' (AKA self promotion projects) and now have to live with the resulting systems.

CIOs and upper managers have a much harder time getting promoted now by just moving to the cloud, that is the last decade's advertisement.

Predict: Microsoft, AWS to quietly, by a thousand cuts, end support for many dozens of cloud technologies before 2030 with no

Re: End of prior generation's management party

[reanjr]

"What is a non sequitur"

*Jeopardy music plays*

Re:It was a stupid idea to begin with. No wonder.

[Seven Spirals]

I fired a guy like you. He went to work at Comcast and is always evangelizing DevOps. He worked there a couple years and they got tired of poor results from his bullshit philosophy and constant flavor-of-the-month shifting from one configuration management tool to the next. They fired his dumb ass, too. First he was stoked about Puppet, then Chef, then Ansible, then Salt, then something else. He was a lying lazy asshole and I consider him the quintessential "DevOps" con artist.

The way he got fired was popping off about how great all his garbageware would make our operations after two years of no results or bad results. I asked in a presentation of his if anyone had a copy of his development requirements. The build team, DBAs, network guys, and sysadmins all gave me copies. I told our COO that I could finish the 45 or so modules he was tasked with in under a week in shell script and I said "This guys is useless and is taking up valuable space and mindshare. I'll finish his work in under 40 hours and when I do, I expect you to fire him or fire me, because I'm tired of his excuses, lies, and time wasting." I was fed up and the COO could tell and simply brought the liar into the office and said "This guy says he can do everything you've promised to do for the last two years in a week. I'm inclined to let him and If he succeeds, that's not going to be a good look for you." The guy in question was like, "Okay, no problem, there is no way he can do that. Let him try. I'll check is work on Monday after he supposedly finishes."

So, just to make it easy to understand, I wrote a master management script which was basically a glorified for-loop running each shell-script I'd written to address one thing or another (make sure the backup agents were installed, make sure it's running monitoring, make sure the monitoring is configured correctly, make sure HP machines have HP Proliant Support Pack and Dell has it's OpenManage suite installed, install Oracle OEM for Oracle RDBMS systems, stuff like that). On Thursday, I was done and showed it to the COO (didn't even have to work late) and he he fired the grifter the next day (taking advantage of the Friday). This guy was totally shocked and demanded to see my work. The COO simply told him "I reviewed it and it works great. All you need to do is get your desk cleaned out."

The company still uses that script collection and one of my old buddies still there says it grew to about 100 scripts and all the sysadmins loved ditching Ansible and the rest of the configuration management garbageware toolkits.

Nix variants don't need "DevOps". Sysadmins should be able to code already without taking on some flavor of the month failed IT dead-end from 10 years ago (DevOps). The AC's radar is spot on. I don't doubt you've made out like a bandit though, that's what happens when you have no morals and are willing to tell management what they like to hear. You get a big consulting fee then move on and let the staff unwind your bullshit over a few years as management gets fired and slowly figures out the shitware you left them with.

Re:

[iAmWaySmarterThanYou]

I'm pretty sure we've all that that guy, sometimes more than once.

I always told the senior tech ops folks, "You can use any tools you want (puppet, chef, etc), but we're using one tool for everything, everyone uses it and we're not arbitrarily changing out of it every 6 months so pick wisely".

End result? Used all the different major tools eventually but at different places. No real difference at the end of the day if they knew how to use them.

Re: It was a stupid idea to begin with. No wonder.

[tatroc]

I have been in these exact same arguments. Unfortunately the boss believed the new guy, I just moved to a new company. I heard a few weeks ago he was fired because he talked too much , always pushing for new tools like you mentioned.

Re:

[Seven Spirals]

Tool junkies, man. SMH. These weaklings need to at least be able to write shell script before they come along and tell us all how fucked up we've been doing things for almost 50 years. These tool addicts are always doing this, they promise the management "great things" if they'll just convert to the flavor of the week, then after a big investment and a lot more talking (then some more planning & talking followed by more talking) folks realize they had a better system all along, they just weren't putting

Re:

[theshowmecanuck]

I did this at a company. Wrote a python script that picked up numbered shell/python/boto scripts from a directory and ran them in the order of the numbers like sysV. You can do a lot with that. Used to deploy in house and to AWS no problem. A lot simpler to understand that much of the other 'stuff' that is out there. You could add a bit of configuration to tailor which scripts ran on which server. Used boto to make the connections and run remote.

Re:

[Seven Spirals]

Nice. Yeah, the cool thing about this approach was that people could write scripts in any language that the target system supported. So, there was Lua, Python, Ruby, etc... One of the few rules was you owned the script and if it broke or caused problems, you owned it or it got removed. The script names were really descriptive and I did the same as you did, I just numbered them and skipped 10 between every new script just in case. The names came to things like "100_insure_NetBackup_agent_is_set_to_start.sh",

Re:

[TaliesinWI]

OK, good, I'm not the only one who hates SELinux. Cool.

Re:

[Seven Spirals]

Oh, it's wonderful if you want your system broken in 10 different ways that'll all require you to write new asinine "rules" for a non-NSA operation but feels like you're in NSA-handcuffs. I'm not saying it's insurmountable about or woe-is-me-I-cant-write-the-exceptions, I'm saying it's value does not exceed it's hassle factor in 99% of cases. If you work for the NSA, well first of all fuck you, but second of all, SElinux is your problem, MLS bitches.

Re: It was a stupid idea to begin with. No wonder.

[ToasterMonkey]

When I first picked up Puppet (pre-devops) it was a direct upgrade to the classic ssh/for loop system you described, or that's how it was pitched, and how I used it. Still plenty of custom idempotent scripts and glue with exec resources where rubber meets the road, but it brought order to managing which systems get what, that and facter is a no-brainer. Making a new module was just a mkdir on the server back then. It was version controlled in the simplest way possible with no branches.

Then it got stupid. Th

Re:

[Seven Spirals]

Right on, bro. You aren't alone. I have pretty much the exact same opinion of "The New Puppet" and the exact same set of experiences. Excellent post, too, enjoyed knowing that I'm not alone either.

Re:

[theshowmecanuck]

Sounds like you are someone else who doesn't understand the benefit of GIT, and just sees added complexity while solving nothing and adding little or no benefit. All it does most times is add another level of merging. i.e. let's make things more complex, and bureaucratic. I don't see any added benefit over SVN.

Re:

[Seven Spirals]

GIT merges better, no doubt. If that's not a your problem, I'd advise moving the focus off VCS. Yes, I've seen SVM butcher merges and CVS as a close second. However, when it comes to configuration control you're usually simply operating in the wrong domain. Systems-level configuration management does not significantly benefit from VCS swaps. In general, that's an argument for programmers, not systems admins. However, I'll admit the whole "DevOps" discussion blurs the lines and one can be forgiven for trying

Re:

[rastos1]

I fired a guy like you. ... He worked there a couple years and they got tired of poor results from his bullshit philosophy and constant flavor-of-the-month shifting from one configuration management tool to the next. ...

Just today I suggested to move from signtool.exe from 2005 to something more recent. I also suggest (and fail to convince the management) to move away from CVS and for over 5 years I'm trying to push for moving to Visual Studio 2017. From Visual Studio 2008. Should I be worried and stop c

Re:

[mrthoughtful]

It brings me back to a conversation I had in 1997 with senior management of a large insurance company that it was costing them millions a year to carry on using their punch-card operated mainframe. They discussed it while I was present, and decided that they would upgrade once they had paid off the mortgage on the existing system (bought about 30 years earlier). The fact that they were paying a premium to find staff to run and maintain the behemoth (all of whom wore white coats) which itself sat in a gigan

Budget Issues

[The Cat]

Gotta free up some more cash for that shitty TV series with the scowling elf.

Re:

[iAmWaySmarterThanYou]

Took me a moment then lol.

SLOW

[Dan East]

My gosh CodeCommit was slow. It took several seconds to fetch, get, push, etc, compared to other services like bitbucket or github which are practically instantaneous. Fortunately we've already switched away from CodeCommit.

Re:

[ctilsie242]

Digressing, these days, IMHO, I don't see why any company would use anything other than GitHub Enterprise. BitBucket, IMHO, has lagged behind. GitLab seems to be keeping up, but GHE offers a lot of nice features like issues, runners, and many other items, so one doesn't need a ticket system like Jira for the developers. Plus, GHE's appliance install is very easy to work with on-prem, for the most part, and they fix bugs quickly.

Of course for smaller firms, Gitea isn't bad either.

Re:

[theshowmecanuck]

Just use what is good enough. Don't need to chase the silver bullets. Constant change is the enemy of getting things done. It also kills companies by wasting time on stuff that doesn't actually make money because of the law of diminishing returns.

Ironic that...

[ctilsie242]

A while back (before I got my current job), I had an interview where the CTO told me, "Backups have no ROI. If it isn't in CodeCommit, it doesn't exist." Needless to say, I noped out of that one.

My question is, what is a replacement? Creating a VPC, throwing a GitHub Enterprise appliance onto an EC2 instance, and going that route? Or just trusting GitHub and their cloud service?

Re:

[gweihir]

There is no replacement for backups. And they need to be multi-generation, offline or WORM, regularly tested, including a restore-test and independent of your primary storage mechanism.

Talk about business people that have no survival skills. They belong in the pool of the unemployed or low-skill workers. That somebody like that is a CTO just makes this even more obvious.

Re:

[unrtst]

... continuing your backup rant ... a backup isn't a backup until a restore is made and verified (and that should be done periodically, even if you don't need it!)

Regarding ctilsie242's question:

My question is, what is a replacement? Creating a VPC, throwing a GitHub Enterprise appliance onto an EC2 instance, and going that route? Or just trusting GitHub and their cloud service?

That depends heavily on your needs. IMO, plain old git on a server you can reach via ssh (and assuming that server is backed up) is often more than enough. Do you need the extra features that some web interface introduces? What part of CodeCommit are you trying to replace?

Re:

[ctilsie242]

Makes sense. I am curious what companies are migrating to from CodeCommit. In my experience, GitHub Enterprise and GitLab are the way to go, as well as Gitea.

Re:

[unrtst]

CTO told me, "Backups have no ROI. If it isn't in CodeCommit, it doesn't exist." Needless to say, I noped out of that one.

Makes sense. I am curious what companies are migrating to from CodeCommit. In my experience, GitHub Enterprise and GitLab are the way to go, as well as Gitea.

Whatever you end up doing, I think it's worth noting that, should one go with another software-as-a-service provider as opposed to rolling+supporting your own, you must keep in mind that they may pull the rug out from under you at any time. That could be some simply change or shift, or completely discontinuing their service, or not allowing new projects to be added (as is the case here). Regardless, you MUST take that into account as part of the cost of doing things that way, just as much as there is a nota

Re:

[ctilsie242]

As for needs, IMHO, one of the critical things I always look for are signed commits. Having this in a dev environment can go a long way in prevent supply chain attacks, especially if the keys are generates on HSMs like YubiKeys.

Re:

[volcan0]

1. CodePipeline integration
2. Avoid another 3rd party with its own fees
3. Data locality issues
4. IAM / SSO and short lived credentials support

Re:

[iAmWaySmarterThanYou]

At one of my earlier jobs while interviewing with the CTO he asked me what is the first thing I'd be looking into if this was my first day at work.

I immediately said "are the backups any good".

He smiled and said he's going to make me an offer before I go as long as I don't say anything too stupid the rest of the day.

Not all CTO are made from the same cloth, thankfully.

Re:

[iAmWaySmarterThanYou]

Yeah I didn't get the sysadmin job I was there for.

I got manager of the team. Thanks for showing concern but no need.

How's it at your fast food job? You must enjoy working next to yermom every day.

Re:

[Seven Spirals]

The alternative is much better backups. If they want to overpay someone to do it for them, use Tarsnap or something similar. However, if they simply cannot be bothered because they can rebuild from some code repo, ask them to do it as a demonstration. When they fail miserably, make a lot of noise about it, then demand they do the right thing. If they won't, run screaming away and toss a few email grenades throwing the CTO under the bus on the way out.

Re:

[iAmWaySmarterThanYou]

Quit or don't take the job, yes, but walking away quietly is the professional thing to do.

The email bombs won't do a thing, their problems are not your responsibility or problem, and you don't know who will remember you years later and cut you out behind the scenes you never knew about. Just go. The company will live or die on its own. Not your concern.

The cloud. Where services vanish without warning

[gweihir]

Great business model! Anybody that trusts this gets exactly what they deserve.

Re:

[VampireByte]

Richard Stallman tried to warn people about this sixteen years ago https://www.theguardian.com/te... [theguardian.com]

Re:

[gweihir]

Indeed. And others did warn too. Looks like almost nobody listened. The usual crap with the human race.

Re:

[barryvoeten]

Good point.
Note the vision of of the Oracle in that Guardian article, Larry Ellison, who also despises the cloud. "... Fashion". Well see how that worked out Larry

Re:

[theshowmecanuck]

I prefer the cloud for it's single point of failure potential.

Re:

[volcan0]

If you use Google or Microsoft, sure. But AWS used to have a reputation for having stable products. The discontinued one of the very first services/instance type only recently. Companies with serious needs pay a premium for that stability. They basically just lost the only edge they had on the market.

Re:

[gweihir]

Looks like a case of "save a million, lose a billion" for AWS.

Re:

[volcan0]

Absolutely. The writing was on the wall as soon as they announced the new CEO.
This sums it up pretty well: https://x.com/raphaelc/status/... [x.com]

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:

[volcan0]

I highly doubt it. I expect to see Amplify, Elastic Beanstalk and a lot of other low-use product to go next. The main question is: will they botch the communication again ?