4 ms·

The 'main gotcha' seems like the common thing people always gloss over when using IaaS. It solves already solvable problems (albeit with more specialised tools

The 'main gotcha' seems like the common thing people always gloss over when using IaaS. It solves already solvable problems (albeit with more specialised tools/people) with a 'magic' solution that works until it doesn't, and then requires even more specialised people to maybe solve it. But that's the whole profit model for IaaS: offer 'magic' solutions that are worse than what a qualified ops team will build, for the same money, to small companies who dont actually need the bells and whistles, and hope that by the time they do need the bells and whistles they're locked into your platform too much to change when they inevitably realise they made a huge mistake.

braythwayt 8y ago
Well, there is a general thing where small companies build a thing, and then they scale to the point where the thing doesn't work any more, and they have to make some changes. History has taught me that accepting the inevitability of change is far better than trying to build a thing with so many features that it need never be changed. In this particular case, I find it hard to believe that anybody will be "locked in" to a serverless SQL database in the same sense that, say, being a game company on top of iOS "locks you into the Apple Ecosystem," or writing your app in Rails "locks you into Ruby."
- stephenr 8y ago
  > I find it hard to believe that anybody will be "locked in" to a serverless SQL database I didn't say that did I? AWS/GCP/Azure/etc as a whole, are platforms that companies become locked-in to, both technically and in terms of mindset.
irrelative 8y ago
I appreciate the skepticism, but "for the same money" is off base in my experience. Maintaining IaaS services costs much less when taking personnel expenses into account.
- stephenr 8y ago
  > Maintaining IaaS services costs much less when taking personnel expenses In my experience the cost savings are because people assume that AWS means "I dont need Ops (any more)" and have developers with zero ops/sysadmin experience running their production environments.
  - exclusiv 8y ago
    There's a lot of us devs that have been at it long enough to have learned sysadmin and networking skills because we had to at the time. Older full stack devs. We don't need sysadmins for 99% of projects. AWS and other solutions work for us and save a lot of time. We know our way around it since we've been using it since it's infancy. That being said, it can burn you. For an ETL platform I was developing cobbling it together with Lambda and other services was a nightmare. Things you'd expect to work didn't. And the cost was way too high for concurrency. So I went back to a single box with beanstalkd and common tools. But I agree many go with a promised solution without the expertise and when it fails or gets hacked they're screwed. And those costs aren't factored in. If we're not hosting and maintaining and the client doesn't have skillset in-house I'll have a client go to Rackspace or similar.
  - scarface74 8y ago
    I’m a developer, but I can hold my own against most “AWS Architects”. Most of them only know netops and they don’t understand how the infrastructure decisions they make affect the other two portions of using AWS - devops and development.
scarface74 8y ago
It solves already solvable problems (albeit with more specialised tools/people) with a 'magic' solution that works until it doesn't, and then requires even more specialised people to maybe solve it. Because no one ever had scaling issue before IaaS that required major architectural changes....

braythwayt 8y ago

Well, there is a general thing where small companies build a thing, and then they scale to the point where the thing doesn't work any more, and they have to make some changes. History has taught me that accepting the inevitability of change is far better than trying to build a thing with so many features that it need never be changed. In this particular case, I find it hard to believe that anybody will be "locked in" to a serverless SQL database in the same sense that, say, being a game company on top of iOS "locks you into the Apple Ecosystem," or writing your app in Rails "locks you into Ruby."

stephenr 8y ago
> I find it hard to believe that anybody will be "locked in" to a serverless SQL database I didn't say that did I? AWS/GCP/Azure/etc as a whole, are platforms that companies become locked-in to, both technically and in terms of mindset.

irrelative 8y ago

I appreciate the skepticism, but "for the same money" is off base in my experience. Maintaining IaaS services costs much less when taking personnel expenses into account.

stephenr 8y ago
> Maintaining IaaS services costs much less when taking personnel expenses In my experience the cost savings are because people assume that AWS means "I dont need Ops (any more)" and have developers with zero ops/sysadmin experience running their production environments.
- exclusiv 8y ago
  There's a lot of us devs that have been at it long enough to have learned sysadmin and networking skills because we had to at the time. Older full stack devs. We don't need sysadmins for 99% of projects. AWS and other solutions work for us and save a lot of time. We know our way around it since we've been using it since it's infancy. That being said, it can burn you. For an ETL platform I was developing cobbling it together with Lambda and other services was a nightmare. Things you'd expect to work didn't. And the cost was way too high for concurrency. So I went back to a single box with beanstalkd and common tools. But I agree many go with a promised solution without the expertise and when it fails or gets hacked they're screwed. And those costs aren't factored in. If we're not hosting and maintaining and the client doesn't have skillset in-house I'll have a client go to Rackspace or similar.
- scarface74 8y ago
  I’m a developer, but I can hold my own against most “AWS Architects”. Most of them only know netops and they don’t understand how the infrastructure decisions they make affect the other two portions of using AWS - devops and development.

scarface74 8y ago

It solves already solvable problems (albeit with more specialised tools/people) with a 'magic' solution that works until it doesn't, and then requires even more specialised people to maybe solve it. Because no one ever had scaling issue before IaaS that required major architectural changes....