6 ms·

"For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to

"For anyone who's not used these "managed" services before, I want to add that it's still a fuck ton of work. The work shifts from "keeping X server running" to "how do I begin to configure and tune this service"." I have noticed that too. With some managed services you are trading a set of generally understood problems with a lot of quirky behavior of the service that's very hard to debug.

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 ago
  It'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 ago
  The 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 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.
    - maxxxxx 8y ago
      That's the promise but in reality every software has bugs, including managed services.
      - diminoten 8y ago
        Not 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 ago
        We'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 ago
        I 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 ago
        Then 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.
dfee 8y ago
But you’re talking about a reduction in the number of types of specialized people to the number of specializations per type of person. That makes this more scalable.
grigjd3 8y ago
So I've worked with AWS and with our internal clusters as a dev. My experience has been that I have to make work-arounds for both, but at least with AWS, I don't have to spell out commands explicitly to the junior PEs. EDIT: I should be clear, our PEs are generally pretty good, but because their product isn't seen by upper management as the thing which makes money, they're perpetually understaffed.
- Macha 8y ago
  Also Amazon documents their stuff in a nice public website, internal teams documented the n-2 iteration of the system and have change notes hidden in a Google drive somewhere that if you ask the right person on the other side of the world they might be able to share you a link to.
  - grigjd3 8y ago
    You were able to find documentation? Where do you work?
  - pm90 8y ago
    This. So. Much. I can't explain just how much developing on GCP has helped me simply by having such amazing documentation. I don't think I appreciated how little I knew: every company where we worked with on premise/ internal services, we would have to use custom services built by others. With GCP, you have complete freedom, not just to design your application architecture from scratch, but to understand how others (coworkers mostly) have designed _their_ applications too! And as a company, it allows the sharing of a common set of best practices, automatically, since its "recommended by Google". Its kinda like Google/Amazon are now the System/Operations engineers for our company. Which they're good at. And its awesome.

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 ago
It'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 ago
The 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 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.
  - maxxxxx 8y ago
    That's the promise but in reality every software has bugs, including managed services.
    - diminoten 8y ago
      Not 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 ago
        We'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 ago
        I 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 ago
        Then 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.

dfee 8y ago

But you’re talking about a reduction in the number of types of specialized people to the number of specializations per type of person. That makes this more scalable.

grigjd3 8y ago

So I've worked with AWS and with our internal clusters as a dev. My experience has been that I have to make work-arounds for both, but at least with AWS, I don't have to spell out commands explicitly to the junior PEs. EDIT: I should be clear, our PEs are generally pretty good, but because their product isn't seen by upper management as the thing which makes money, they're perpetually understaffed.

Macha 8y ago
Also Amazon documents their stuff in a nice public website, internal teams documented the n-2 iteration of the system and have change notes hidden in a Google drive somewhere that if you ask the right person on the other side of the world they might be able to share you a link to.
- grigjd3 8y ago
  You were able to find documentation? Where do you work?
- pm90 8y ago
  This. So. Much. I can't explain just how much developing on GCP has helped me simply by having such amazing documentation. I don't think I appreciated how little I knew: every company where we worked with on premise/ internal services, we would have to use custom services built by others. With GCP, you have complete freedom, not just to design your application architecture from scratch, but to understand how others (coworkers mostly) have designed _their_ applications too! And as a company, it allows the sharing of a common set of best practices, automatically, since its "recommended by Google". Its kinda like Google/Amazon are now the System/Operations engineers for our company. Which they're good at. And its awesome.