4 ms·

The typical argument about the superiority of cloud services is that it's more hands-off, but what they don't talk about is how shared resources causes all kind

The typical argument about the superiority of cloud services is that it's more hands-off, but what they don't talk about is how shared resources causes all kinds of new headaches I never had before. I recently migrated from a dedicated DC to AWS because of business reasons (ie. CAPEX vs OPEX). Before, my PostgreSQL DBs were always perfectly in sync because they were on a dedicated, private network. Now, I often get large replication delays because the network in EC2 isn't of the same quality I had before, so I've had to spend a lot of dev time working around the delay issue with creative caching solutions. My point is, there's trade-offs and mostly my calculations show that they're not really worth it, if you have knowledgable Ops people. Which, once you grow to a certain size, you should.

stickfigure 11y ago
I think you're misreading the message - managed services doesn't mean EC2. Managed services are things like DynamoDB, ElasticBeanstalk, SQS (in the AWS world) or Cloud Datastore and App Engine (in the Google world). If you're building on IaaS like EC2 or GCE, you will need ops people. If you build at a higher level, you don't.
- nasalgoat 11y ago
  If anything my argument holds up because you're putting even more abstraction between you and your systems by using the managed services, which leads to less understanding of how things actually work. For instance, I went with running PostgreSQL instead of RDS because I have much more control over what's going on in the DB than I would with RDS. But your point that the managed services don't require ops might be true in the short term, but what happens when something breaks? Or you experience a level of growth that expands past the capabilities of the services you've organized? There's hard practical limits to all the of SaaS offerings - mostly latency and throughput - that doesn't really come up in these discussions. The analogy about it being like assembly programming might be more apt than I originally thought, given how not doing it yourself generally results in slower and poorly optimized solutions, but then "good enough" is often the mantra of the day at a certain scale.
  - khedoros 11y ago
    Further on the "assembly programming" line of thought: there was a long time where compilers just couldn't match the speed of hand-coded assembly...but that time is almost completely behind us, and probably has been for quite some time. As management tools mature and automatic, systemic optimizations are developed for SaaS systems, I wonder if the analogy will continue and areas where you need to manage it yourself to eke out performance and flexibility will get fewer and farther between over time.

stickfigure 11y ago

I think you're misreading the message - managed services doesn't mean EC2. Managed services are things like DynamoDB, ElasticBeanstalk, SQS (in the AWS world) or Cloud Datastore and App Engine (in the Google world). If you're building on IaaS like EC2 or GCE, you will need ops people. If you build at a higher level, you don't.

nasalgoat 11y ago
If anything my argument holds up because you're putting even more abstraction between you and your systems by using the managed services, which leads to less understanding of how things actually work. For instance, I went with running PostgreSQL instead of RDS because I have much more control over what's going on in the DB than I would with RDS. But your point that the managed services don't require ops might be true in the short term, but what happens when something breaks? Or you experience a level of growth that expands past the capabilities of the services you've organized? There's hard practical limits to all the of SaaS offerings - mostly latency and throughput - that doesn't really come up in these discussions. The analogy about it being like assembly programming might be more apt than I originally thought, given how not doing it yourself generally results in slower and poorly optimized solutions, but then "good enough" is often the mantra of the day at a certain scale.
- khedoros 11y ago
  Further on the "assembly programming" line of thought: there was a long time where compilers just couldn't match the speed of hand-coded assembly...but that time is almost completely behind us, and probably has been for quite some time. As management tools mature and automatic, systemic optimizations are developed for SaaS systems, I wonder if the analogy will continue and areas where you need to manage it yourself to eke out performance and flexibility will get fewer and farther between over time.