7 ms·
Yes, but I think very broadly speaking the quirky behavior is stuff you bump into, learn about, fix, and then can walk away from. The daily/monthly maintenance
by erikpukinskis 8y ago
Yes, but I think very broadly speaking the quirky behavior is stuff you bump into, learn about, fix, and then can walk away from.
The daily/monthly maintenance cycle on a self hosted SQL server is “generally understood” but you still have to wake up, check your security patches, and monitor your redeployments.
You can do some of that in an automated fashion with public security updates for your containers and such. But if monitoring detects an anomaly, it’s YOU, not Heroku who gets paged.
It’s a little like owning a house vs renting. Yes if you rent you have to work around the existing building, and getting small things fixed is a process. But if the pipes explode, you make a phone call and it’s someone else’s problem. You didn’t eliminate your workload, but you shrunk the domain you need to personally be on call for.
- forty 8y agoIt's someone else problem unless it prevents you from living here, in which case it's still your problem too. I think the analogy works quite well :)
- deleted 8y ago[deleted]
- maxxxxx 8y agoThe problem is that if I run my own servers I can fix problems (maybe with a lot of effort but at least it can be done) but with managed services I may not be able to do so. There is a lot of value in managed services but you have to be careful not to allow them to eat up your project with their bugs/quirks.
- diminoten 8y agoThe point is with a managed service, none of your problems will be with the service. That's what the managed service is selling.
- maxxxxx 8y agoThat's the promise but in reality every software has bugs, including managed services.
- diminoten 8y agoNot really, not anything like what you're describing. 12 outages since 2011, and none of them are anything like what you're describing: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
- bsagdiyev 8y agoWe've moved from on-prem to AWS fully and we see random issues all the time while their status page shows all green, so I feel you probably have a small amount of resources in use with them or something, because what you're saying doesn't jive with what we see daily. I see you've also copy-pasted your response to other comments too, so I'll do the same with my response.
- diminoten 8y agoI don't feel like copy/pasting all of our comments to each other, so I'd appreciate it if you didn't do that, thanks.
- bsagdiyev 8y agoThen don't do it yourself. You're dead set on ignoring people whose experience is different than yours, wrapping yourself in an echo chamber of sorts and telling others they are wrong.
- diminoten 8y agoI'm not dead set on anything, I'm trying to have conversations with multiple people, not create an immutable record. And I don't think you know what an echo chamber is if you think one person can create one alone...
- deathanatos 8y agoI just finished a 2+ week support ticket w/ AWS. We were unable to connect over TLS to several of our instances, because the instance's hostname was not listed on the certificate. This is a niche bug that's trivially fixable if you own the service, but with AWS, it's a lot harder: you're going to need a technical rep who understands x509 — and nobody understands x509. I've found & reported a bug in RDS whereby spatial indexes just didn't work; merely hinting the server to not use the spatial index would return results, but hinting it to use the spatial index would get nothing. (Spatial indexes were, admittedly, brand new at the time.) I've had bugs w/ S3: technically the service is up, but trivial GETs from the bucket take 140 seconds to complete, rendering our service effectively down. I've found & worked w/ AWS to fix a bug in ELB's HTTP handling. All of these were problems with the service, since in each case it's failing to correctly implement some well-understood protocol. AWS is not perfect. (Still, it is worth it, IMO. But the parent is right: you are trading one set of issues for another, and it's worth knowing that and thinking about it and what is right for you.)
- diminoten 8y agoOkay, I'm sorry you thought I said AWS was perfect and bug free. I didn't, however, say that. I said (implied, really) it's better than anything you could possibly home brew. Nothing you've said here changes that. Further, didn't I say that it's trading one set of issues for another? Or at least, I explicitly agreed with that. I feel like you didn't read what I wrote honestly, and kind of came in with your own agenda. All I ever said was that the issues you trade off are orchestration issues vs. operational issues, and operational issues are 10x harder than orchestration issues because you don't get to decide when to work on operational issues, you tend to have to deal with them when they happen.
- frankchn 8y agoYou wrote “The point is with a managed service, none of your problems will be with the service.” What deathanatos wrote sounds awfully like problems with the service to me. I don’t think S3 taking 100+ seconds to respond to a GET request can be solved by orchestration alone.
- msla 8y ago> The point is with a managed service, none of your problems will be with the service. That's what the managed service is selling. Until the managed service simply goes away, of course, taking your data with it.
- holoduke 8y agoExactly this
- scarface74 8y agoSo what “problems” were you unable to fix with AWS?