> And then the developer says "hey we'll just use AWS because thats what HN all suggest and it's cheap"

Never understood this, except from developers who've never actually had to pay for anything out of their own pocket. AWS is nice, and has a place.

And I do hear it from people, a lot. It's cheap compared to buying your own hardware and dedicated staff, yes. But for a lot of the standard webapp stuff you might want to do starting out, it's not as cheap as just getting a dedicated VPS someplace.

I've been independent/self-employed for a long time, and while I use various AWS services (including EC2 for some projects), it's rarely ever cost which is the driving factor when AWS is chosen. But it's because the $ is coming, directly or indirectly, from me.

Running your own stuff becomes more expensive when you want monitoring, Load Balancers, HA, VPN's into your corporate network and constant database backups. And then making it really robust.

Hiring all the staff for that can be expensive.

Problem is there are lot of developers who think setting up a virtual machine putting a db on it, and then a webserver on another without thinking about all the other stuff that can go wrong.

There's a balance to be had, and there's very likely different periods in a business lifecycle where some environments make more sense than others.

There's a pretty big cost to learning how to manage and get value all the AWS stuff, and in the early days of a project - especially true in the 'startup' world - there are probably more areas where $ can be spent to create more value.

I've seen far too many people spin up multiple AWS and tie themselves to expensive AWS setups when a small linode or other VPS (managed or otherwise) would have been more than adequate for the first year.

There's this weird view people that have it's either 100% AWS or hire full time developers and buy a bunch of bare metal. There's a lot of middle ground which can provide a good amount of value while giving you time to ramp up.

The fact that you're referencing tying VPNs to a corporate network means you're already far more advanced than a lot of the smaller orgs I've run in to tying themselves to AWS when far less expensive alternatives exist.

Again, saying this as someone who uses and likes Amazon stuff, just not exclusively.

It can still be an issue. It would still be a disaster if in the first year, the database got corrupt or hacked?

Lone developers might tempted just to setup database without setting up a backup solution and HA. Amazon has that at click of a button.

For a developer/infrastructure guy probably 1/2/3 days if you know what your doing. If you don't know what your doing for your specific brand of database, you might not set it up right which is a big risk which only shows up once it's failed. There's a reason DBA's can get paid a lot, because there's a lot to know.

I think as a startup, you need to take all the shortcuts you can grab. Getting it out, and time to market is very important. Focusing on price at first can cost more than its worth.

It depends on if you want to pay more for having quick setup and having amazons engineers looking after backups and HA or do you want to pay less, spend more time doing it yourself and getting the skills to make sure its setup correctly.

> Hiring all the staff for that can be expensive.

Competent, experienced staff to run the core of your business has a cost. You can replace ops with managed services no more than I can replace devs with cheap, untrained labor in Asia.

I never said replace, just augment. You may need fewer, but you still need people to monitor, deploy and orchestrate these different services. At the end of the day the extra cost is going toward hiring engineers at the hosters side for managed services but benefiting from their scale.

Either way your going to have to pay for skilled operational engineers.

"when previously you needed just two servers in failover setup, with capacity to spare."

I don't know if you were there but I said the same shit to people here on HN in a hosting discussion. Some company had downtime on AWS and/or a bunch of servers. I said something along lines of how hard can it be to buy four servers at $1-2k each, set them up as HA pairs of pairs, send two to a colo, and manage that? And optionally send another pair to a third, geographical area if one wants more uptime? It's not that hard given we've been doing it since friggin' VMS clusters on refrigerator-sized VAXen. Just dirt cheap now for basic solution. OSS tools are even good enough for homebrewing it with little risk now.

Nah, though, let's pay for a bunch of VM's we have to manage anyway that we don't even control on sites with less uptime. (rolls eyes)

"but I don't really understand how any of this SSL stuff works", there is just one realistic response. Run. Then run some more, hide, change your email and don't answer your phone. Because that shit is about to go down like the titanic."

LOL. That's great. Someone with a meme generator needs to make an image out of this: "DevOps: Replaces Admins, Can't Deploy SSL." I can imagine quite a few more in capacity and disaster planning. Now what image would go with that...?

To me this sounds like the developers weren't tested for ops skills before being brought on to a team while everyone knew that developers are required to do ops.

Of course, specialisation helps. But the most pleasant work experience I've had was at companies where there was no distinction between dev and ops.

I worked for the company ostensibly as a developer, but my formal qualifications are in network engineering, and ops (we used to call it infrastructure) is what I did before I jumped to web work.

When none of the developers are particularly experienced with ops, how do they know whats required to do ops?

Im not saying someone *can't& be skilled at dev and ops. I'm saying the 'normal' result I see, is that management (and some developers) assume any developer can do anything an experienced ops can do, and write that fancy javascript widget too!

But web developers should know how SSL works anyway. Otherwise your probably not a great developer.

I defiantly learned about SSL, and pki infrastructure through developer knowledge.

If library is done well, then you shouldn't have to know much about SSL to be able to use it. Just an abstract idea of it plus how to use the library. SSL from an ops perspective is quite different. That's why it's better to have pro's in each working together on it.

I would want a developer who knows the best practice keeping the ciphersuite up to date and understands stuff like client side certificates if they going to work on any security conscious application.

I'd prefer it but one you mention can be done upstream by library developer with secure defaults. Think NaCl. Client-side certificates might come with best practices or checklists that show proper use with optional data on the way. Neither issue requires understanding SSL in common deployments.

Note that I say this while agreeing with you that I prefer someone who knows what they're doing. Especially as SSL support isn't usually at the usability standard I'm describing. Yet, it's not intrinsic to the problem: just crap UX.