4 ms·

I don't want to use K8s. But I also don't want to use a manually setup rack in a random DC. Back in the day when we had to hire a guy to go down to the cage ev

I don't want to use K8s. But I also don't want to use a manually setup rack in a random DC. Back in the day when we had to hire a guy to go down to the cage every day to repair yet another faulty machine, we would have given our left arm for the ability to magically spin up a new VM of any size with a baked image by just running an API call. It's freakin' magic. I also love, love, love plain Fargate. Not as stupidly complicated as K8s, but I can still run containers without ever thinking about managing hosts. Just keep my containers up to date, push new ones, and trigger a deploy. Never have to "upgrade my cluster to keep from using EOL versions" or "migrate ingress to a new API version" or some other ridiculous thing. It just works, and all I have to think about is my app/container.

dcminter 5y ago
So much this. I have painful memories of talking a not-very-technical "technical support" guy through the use of `lsof` on Linux (they'd never heard of it) to diagnose a deployment issue. Also of multi-day to multi-week waits to get hardware lined up for our projects. I miss it not one jot.
dotancohen 5y ago
Don't confuse faulty hardware with software abstractions of perfect hardware. Those cloud VMs are still running on some hardware somewhere, even it's been abstracted away from your control. And that hardware can and does fail.
- throwaway787544 5y ago
  But with an autoscaling group a new one magically pops up in the same AZ if an old one dies. You don't get that by rolling your own rack (without having hot spares on hand, in multiple racks or data centers). Not to mention getting a managed SAN basically for free (EBS) and backup/restore, and managed DBs... I'm a pretty good engineer, but I'm not good enough to be an expert at managing racks of hosts, switches, routers, storage, tape robots, databases, etc. And I don't have to be with cloud services. I just press a button and it's all there.
  - withinboredom 5y ago
    Except for that one time a new one magically doesn’t reappear… only to find out that the entire region is down. Then you have to explain to the owner that you don’t have multi-region deployments because they didn’t want to pay for it… and you have no idea when it will be back. (based on a true story) At least with more traditional setups, you can have visibility into why/how your entire system is down and can even have a reasonable timeline to get back to running.
    - engineeringwoke 5y ago
      How are you going to make money as an entrepreneur if you are afraid to take risks? The risk/reward here is obviously good. You say this because you are scared of failure.
      - withinboredom 5y ago
        Me, I didn’t really give a shit then nor would I give a shit now. My job was to lay out the risks/rewards to clients. Sometimes, they choose the dumb thing. You can tell them that’s it unwise, but ultimately it’s their wallets. If they don’t want to pay an extra 20k a month just for redundancy, I totally get it. They lost about 50k in sales that day, still less than the cost-of-ownership for redundancy. PS. Please keep conversations civil. You probably don’t know me, but I’m the least “scared of failure” person you’ll ever meet.
        engineeringwoke 5y ago
        Where is the lack of civility in my comment? It's okay to say that you dislike what someone said without projecting that discomfort onto them. Enjoy your civil discussions with people that aren't me
  - deleted 5y ago
    [deleted]
  - Melatonic 5y ago
    As a software engineer you should not ever have had to be responsible for those things - that would be the job of network engineers and system engineers. For a small company that is only rolling one rack then I agree it makes sense to cloud host a lot of it (especially variable workloads). But keep in mind you can also roll your own hardware and have "the cloud" as your magic machine that pops up if your rack (or the connection to that datacenter) dies.
marvinblum 5y ago
> I also love, love, love plain Fargate. Same goes for the HashiStack. I really don't want to work with Kubernetes anymore simply to deploy some containers.
orev 5y ago
Whatever you were doing with those faulty machines that failed daily was a problem with you, not a problem with running remote hardware. I’ve run remote hardware for 20 years and only have to physically go to the data center a handful of times per year (and never need to use remote hands support). It just sounds like you were using crap quality equipment and/or didn’t have remote access setup correctly.
Melatonic 5y ago
You must have been running some damn cheap or old or faulty hardware because that is an insane amount of hardware maintenance.

dcminter 5y ago

So much this. I have painful memories of talking a not-very-technical "technical support" guy through the use of `lsof` on Linux (they'd never heard of it) to diagnose a deployment issue. Also of multi-day to multi-week waits to get hardware lined up for our projects. I miss it not one jot.

dotancohen 5y ago

Don't confuse faulty hardware with software abstractions of perfect hardware. Those cloud VMs are still running on some hardware somewhere, even it's been abstracted away from your control. And that hardware can and does fail.

throwaway787544 5y ago
But with an autoscaling group a new one magically pops up in the same AZ if an old one dies. You don't get that by rolling your own rack (without having hot spares on hand, in multiple racks or data centers). Not to mention getting a managed SAN basically for free (EBS) and backup/restore, and managed DBs... I'm a pretty good engineer, but I'm not good enough to be an expert at managing racks of hosts, switches, routers, storage, tape robots, databases, etc. And I don't have to be with cloud services. I just press a button and it's all there.
- withinboredom 5y ago
  Except for that one time a new one magically doesn’t reappear… only to find out that the entire region is down. Then you have to explain to the owner that you don’t have multi-region deployments because they didn’t want to pay for it… and you have no idea when it will be back. (based on a true story) At least with more traditional setups, you can have visibility into why/how your entire system is down and can even have a reasonable timeline to get back to running.
  - engineeringwoke 5y ago
    How are you going to make money as an entrepreneur if you are afraid to take risks? The risk/reward here is obviously good. You say this because you are scared of failure.
    - withinboredom 5y ago
      Me, I didn’t really give a shit then nor would I give a shit now. My job was to lay out the risks/rewards to clients. Sometimes, they choose the dumb thing. You can tell them that’s it unwise, but ultimately it’s their wallets. If they don’t want to pay an extra 20k a month just for redundancy, I totally get it. They lost about 50k in sales that day, still less than the cost-of-ownership for redundancy. PS. Please keep conversations civil. You probably don’t know me, but I’m the least “scared of failure” person you’ll ever meet.
      - engineeringwoke 5y ago
        Where is the lack of civility in my comment? It's okay to say that you dislike what someone said without projecting that discomfort onto them. Enjoy your civil discussions with people that aren't me
- deleted 5y ago
  [deleted]
- Melatonic 5y ago
  As a software engineer you should not ever have had to be responsible for those things - that would be the job of network engineers and system engineers. For a small company that is only rolling one rack then I agree it makes sense to cloud host a lot of it (especially variable workloads). But keep in mind you can also roll your own hardware and have "the cloud" as your magic machine that pops up if your rack (or the connection to that datacenter) dies.

marvinblum 5y ago

> I also love, love, love plain Fargate. Same goes for the HashiStack. I really don't want to work with Kubernetes anymore simply to deploy some containers.

orev 5y ago

Whatever you were doing with those faulty machines that failed daily was a problem with you, not a problem with running remote hardware. I’ve run remote hardware for 20 years and only have to physically go to the data center a handful of times per year (and never need to use remote hands support). It just sounds like you were using crap quality equipment and/or didn’t have remote access setup correctly.

Melatonic 5y ago

You must have been running some damn cheap or old or faulty hardware because that is an insane amount of hardware maintenance.