13 ms·

Exactly. There's no silver bullet, only trade offs. In this case you're only shifting the complexity from "maintaining" to "orchestrating". "Maintaining" means

Exactly. There's no silver bullet, only trade offs. In this case you're only shifting the complexity from "maintaining" to "orchestrating". "Maintaining" means you build (in a semi-automated way) once and most of your work is spent keeping the services running. In the latter, you spend most of your time building the "orchestration" and little time maintaining. If your product is still small, it makes sense to keep most of your infrastructure in "maintaining" since the number of services is small. As the product grows (and your company starts hiring ops people), you can slowly migrate to "orchestrating".

diminoten 8y ago
The costs associated with "maintaining" usually involve the possibility of a 3am call for whoever is in charge of maintaining. Orchestrating can be done ahead of time, during your 9-5, and that's super valuable. It's still a lot of work, but it's work that can be done on my time, at my pace.
- throwaway2048 8y ago
  Managed services still have plenty of unexplained goings-on, and 3AM pages.
  - diminoten 8y ago
    Said like a person who hasn't actually ever converted. It's nothing like that at all. 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.
      - diminoten 8y ago
        Can you actually quantify any of this or are you asking me to trust you? What I gave is an objective standard, what you've given so far is "trust me I'm right".
        bsagdiyev 8y ago
        Without breaking my employer confidentiality agreement? No. But you basing off reported outages is you trusting Amazon in the same way you don't trust me, that is, on their word.
        diminoten 8y ago
        I'd rather trust a corporation providing some information over an individual providing absolutely nothing, especially when that corporation's information matches with my own internal information. The reality is, if you're having problems with AWS, it's you, and not AWS, for 99.9999999% of your problems. Continuing to pretend it's AWS is a face-saving, ego protecting activity that no rational person plays part in.
        jacoblambda 8y ago
        While I want to avoid getting into this argument, what you are saying is the same as "well it works on my machine" and "there can't be anything wrong with Oracle Database because Oracle says there are no bugs."
        diminoten 8y ago
        No, what I'm saying is, "None of your problems are consistent across use cases, therefore they're your problems not the system being used." I haven't actually said anything about my own experience, so it's funny you claim I have...
        jacoblambda 8y ago
    - adrianN 8y ago
      When your Redshift instance locks up, it doesn't end up on Wikipedia.
  - aprdm 8y ago
    We moved some stuff from AWS back to on prems because it broke less often and in more obvious ways.
PaulHoule 8y ago
Funny enough, I've experienced the largest benefits from "scaling down" with Amazon's managed databases. For instance I made an email newsletter system which handles subscriptions, verifications, unsubscribes, removing bounces, etc. based on Lambda, DynamoDB, and SES. What's nice about is that I don't need to have a whole VM running all the time when I just have to process a few subscriptions a day and an occasional burst of work when the newsletter goes out.
- mcny 8y ago
  I have a db.example.com $10 a month VM on digital ocean. It is strictly for dev and staging. Not actual production use because prod doesn't exist yet anyways. My question is what kind of maintenance should I be doing? I don't see any maintenance. I run apt upgrade about once a month. I'm sure you'd probably want to go with something like Google Cloud or Amazon or ElephantSQL for production purely to CYA but other than that if you don't anticipate heavy load, why not just get a cheap VM and run postgresql yourself? I mean I think ssh login is pretty safe if you disable password login, right? What maintenance am I missing? Assuming you don't care about the data and are willing to do some work to recreate your databases when something goes wrong, I think a virtual machine with linode or digital ocean or even your own data center is not bad?
  - Jedi72 8y ago
    Amazon are pushing very hard to convince the next generation of devs who grew up writing front-end JS that databases, servers etc. are some kind of technical wizardy best outsourced, when a few weeks of reading and playing around would be enough to get them up to speed.
    - scarface74 8y ago
      It’s not about “getting up to speed”. It’s about not having to manage it on and ongoing basis. I wouldn’t work for a company that expects devs to manage resources that can be managed by a cloud provider and develop. How well can you “manage” a Mysql database with storage redundancy across three availability zones and synchronous autoscaling read replicas? How well can you manage an autoscaling database that costs basically nothing when you’re not using but scales to handle spikey traffic when you do?
adamlett 8y ago
There's no silver bullet, only trade offs. I see this a lot and it bugs me, because it implies that it's all zero sum and there's nothing that's ever unconditionally better or worse than anything else. But that's clearly ridiculous. A hammer is unconditionally better than a rock for putting nails in things. The beauty of progress is that it enables us to have our cake and eat it too. There is no law that necessitates a dichotomy between powerful and easy.
- placebo 8y ago
  > it implies that it's all zero sum and there's nothing that's ever unconditionally better or worse than anything else Not necessarily - to start with, a good trade-off is unconditionally better than a bad trade-off. Also, progress brings with it increasing complexity. Recognizing the best path includes assessing many more parameters and is far more difficult than deciding whether to use a hammer or a rock to nail things. The puzzling nature of many people to over-complicate things instead of simplifying them makes the challenge even more difficult. By the way, the closest thing I've ever found to a silver bullet in software development (and basically any endeavor) is "Keep it simple". While this is a cliche already, it is still too often overlooked. I think this is because it isn't related to the ability to be a master at manipulating code and logic, but the ability to focus on what's really important - to know how to discard the trendy for the practical, the adventurous methods to the focused and solid - basically passionately applying occam's razor on every abstraction layer. If this was more common, I think articles like "You are not Google" would be less common.
  - mcguire 8y ago
    Ever wonder how the Go team seems to get stuff done more efficiently than other groups? It's not Go, it's that they simplify (perhaps oversimplify).
  - tracker1 8y ago
    > Not necessarily - to start with, a good trade-off is unconditionally better than a bad trade-off. Are you better off with a simple dokku server, or a k8s cluster? There's lots of good/bad on both sides... it really depends on your needs. You could use one locally or through dev layers and another for production.
rightbyte 8y ago
If you are hunting vampires there are the choice of the Silver Bullet avaible. Some times, the benefits from something compared to another thing are so great that there are no downsides. If the rasp in the closets doesn't suffice you can always add another one.

diminoten 8y ago

The costs associated with "maintaining" usually involve the possibility of a 3am call for whoever is in charge of maintaining. Orchestrating can be done ahead of time, during your 9-5, and that's super valuable. It's still a lot of work, but it's work that can be done on my time, at my pace.

throwaway2048 8y ago
Managed services still have plenty of unexplained goings-on, and 3AM pages.
- diminoten 8y ago
  Said like a person who hasn't actually ever converted. It's nothing like that at all. 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.
    - diminoten 8y ago
      Can you actually quantify any of this or are you asking me to trust you? What I gave is an objective standard, what you've given so far is "trust me I'm right".
      - bsagdiyev 8y ago
        Without breaking my employer confidentiality agreement? No. But you basing off reported outages is you trusting Amazon in the same way you don't trust me, that is, on their word.
        diminoten 8y ago
        I'd rather trust a corporation providing some information over an individual providing absolutely nothing, especially when that corporation's information matches with my own internal information. The reality is, if you're having problems with AWS, it's you, and not AWS, for 99.9999999% of your problems. Continuing to pretend it's AWS is a face-saving, ego protecting activity that no rational person plays part in.
        jacoblambda 8y ago
        While I want to avoid getting into this argument, what you are saying is the same as "well it works on my machine" and "there can't be anything wrong with Oracle Database because Oracle says there are no bugs."
        diminoten 8y ago
        No, what I'm saying is, "None of your problems are consistent across use cases, therefore they're your problems not the system being used." I haven't actually said anything about my own experience, so it's funny you claim I have...
        jacoblambda 8y ago
  - adrianN 8y ago
    When your Redshift instance locks up, it doesn't end up on Wikipedia.
- aprdm 8y ago
  We moved some stuff from AWS back to on prems because it broke less often and in more obvious ways.

PaulHoule 8y ago

Funny enough, I've experienced the largest benefits from "scaling down" with Amazon's managed databases. For instance I made an email newsletter system which handles subscriptions, verifications, unsubscribes, removing bounces, etc. based on Lambda, DynamoDB, and SES. What's nice about is that I don't need to have a whole VM running all the time when I just have to process a few subscriptions a day and an occasional burst of work when the newsletter goes out.

mcny 8y ago
I have a db.example.com $10 a month VM on digital ocean. It is strictly for dev and staging. Not actual production use because prod doesn't exist yet anyways. My question is what kind of maintenance should I be doing? I don't see any maintenance. I run apt upgrade about once a month. I'm sure you'd probably want to go with something like Google Cloud or Amazon or ElephantSQL for production purely to CYA but other than that if you don't anticipate heavy load, why not just get a cheap VM and run postgresql yourself? I mean I think ssh login is pretty safe if you disable password login, right? What maintenance am I missing? Assuming you don't care about the data and are willing to do some work to recreate your databases when something goes wrong, I think a virtual machine with linode or digital ocean or even your own data center is not bad?
- Jedi72 8y ago
  Amazon are pushing very hard to convince the next generation of devs who grew up writing front-end JS that databases, servers etc. are some kind of technical wizardy best outsourced, when a few weeks of reading and playing around would be enough to get them up to speed.
  - scarface74 8y ago
    It’s not about “getting up to speed”. It’s about not having to manage it on and ongoing basis. I wouldn’t work for a company that expects devs to manage resources that can be managed by a cloud provider and develop. How well can you “manage” a Mysql database with storage redundancy across three availability zones and synchronous autoscaling read replicas? How well can you manage an autoscaling database that costs basically nothing when you’re not using but scales to handle spikey traffic when you do?

adamlett 8y ago

There's no silver bullet, only trade offs. I see this a lot and it bugs me, because it implies that it's all zero sum and there's nothing that's ever unconditionally better or worse than anything else. But that's clearly ridiculous. A hammer is unconditionally better than a rock for putting nails in things. The beauty of progress is that it enables us to have our cake and eat it too. There is no law that necessitates a dichotomy between powerful and easy.

placebo 8y ago
> it implies that it's all zero sum and there's nothing that's ever unconditionally better or worse than anything else Not necessarily - to start with, a good trade-off is unconditionally better than a bad trade-off. Also, progress brings with it increasing complexity. Recognizing the best path includes assessing many more parameters and is far more difficult than deciding whether to use a hammer or a rock to nail things. The puzzling nature of many people to over-complicate things instead of simplifying them makes the challenge even more difficult. By the way, the closest thing I've ever found to a silver bullet in software development (and basically any endeavor) is "Keep it simple". While this is a cliche already, it is still too often overlooked. I think this is because it isn't related to the ability to be a master at manipulating code and logic, but the ability to focus on what's really important - to know how to discard the trendy for the practical, the adventurous methods to the focused and solid - basically passionately applying occam's razor on every abstraction layer. If this was more common, I think articles like "You are not Google" would be less common.
- mcguire 8y ago
  Ever wonder how the Go team seems to get stuff done more efficiently than other groups? It's not Go, it's that they simplify (perhaps oversimplify).
- tracker1 8y ago
  > Not necessarily - to start with, a good trade-off is unconditionally better than a bad trade-off. Are you better off with a simple dokku server, or a k8s cluster? There's lots of good/bad on both sides... it really depends on your needs. You could use one locally or through dev layers and another for production.

rightbyte 8y ago

If you are hunting vampires there are the choice of the Silver Bullet avaible. Some times, the benefits from something compared to another thing are so great that there are no downsides. If the rasp in the closets doesn't suffice you can always add another one.