News for hackers. Stuff that matters.
Re:Serving 39M Requests for $370/Month by mgkimsal on Thursday June 22, 2017 @09:05AM (#14611919)
> Maybe we just have different definitions of "ops works" but it bothers me when people claim that you don't need to have anyone minding AWS because it's serverless. You still need to have people monitoring, managing permissions, optimising to reduce cost, pushing updates, etc

Thank you. Instead of being able to find a server ops guy from a large pool of experienced folks, you now have to find someone specifically with AWS-ops experience - a growing but much smaller pool of people, ime. Getting IAM permissions correct for complex stuff is just not simple, for example, and there's some use cases IAM stuff doesn't (or didn't) cover.

Had a client who couldn't give me EC2 access because - at least at the time - they'd have to give me access to all their EC2 instances, not just the ones I needed. Now... this may have been IAM-inexperience, although, at the time, my digging seemed to indicate it was the correct conclusion.

Re:Serving 39M Requests for $370/Month by vidarh on Thursday June 22, 2017 @09:46AM (#14612168)
I keep recommending people look at places like Hetzner over AWS. People keep wanting to do AWS anyway, and then end up paying 2x-3x as much for the servers and more for the ops work. I shouldn't complain - people who opt for AWS even when it doesn't make sense are what my profit margin is made of.

(I have clients I recommend AWS to as well, but reducing ops time and/or reduced cost are rarely if ever part of those discussions; AWS is the luxury option)

Re:Serving 39M Requests for $370/Month by rtpg on Friday June 23, 2017 @09:26PM (#14623918)
out of curiosity: What makes you recommend AWS in those cases?
Re:Serving 39M Requests for $370/Month by vidarh on Tuesday June 27, 2017 @01:45AM (#14642820)
It would typically be if they have use cases where they either want to do large batch jobs, or have other needs where "add-on" services AWS provides is worthwhile. Often it's a matter of urgency, and AWS will be a good first approximation, and we can start migrating onto a hybrid or fully dedicated environment depending on what's most cost effective down the road when they know more about what they actually need.

Sometimes it's a matter of politics and trst - AWS is trusted, and if their hosting cost doesn't add up to much of their total costs, then that trust is sometimes more worthwhile than squeezing the cost down. E.g. I'm working on a project for a VC now, and their yearly hosting costs are likely to be below what I'm charging them for the initial development of their system, so spending time selling them on a cheaper provider is just not worth it for either them or me.

Re:Serving 39M Requests for $370/Month by kogepathic on Thursday June 22, 2017 @11:16AM (#14612810)
> Instead of being able to find a server ops guy from a large pool of experienced folks, you now have to find someone specifically with AWS-ops experience

Yes, and too many companies don't realize that by moving to AWS, they are not only narrowing the pool of developers/operations people they can hire from, but the salary of these people is higher.

I'm not against AWS, there are absolutely businesses where AWS makes sense (as the article describes). However it's more than just a question of dollars and cents to move to AWS, you also have to factor in the HR consequences of losing access to dime a dozen developers/sysadmins.

For most businesses I have worked with, I would argue losing access to developer/sysadmin talent outweighs their perceived benefits of moving to serverless.

Re:Serving 39M Requests for $370/Month by mgkimsal on Thursday June 22, 2017 @11:59AM (#14613153)
replying to myself - the client at the bottom had a "move to AWS" mandate from management, they moved, then found out that at least some of their use cases weren't supported. As silly as it sounds, research a tool before you commit to it. Some things are certainly not discoverable until midway in to a project - life happens - but moving ops to AWS in ... 2014, 2015, 2016 - there's enough "known" caveats and gotchas already documented that basic things shouldn't be a surprise. The cost of working around those gotchas often surpasses any first year savings from a migration, but as I've learned - "that's someone else's budget" is sometimes a valid excuse (from some perspectives anyway - as a shareholder, I wouldn't want that justification).