4 ms·

1. Use managed cloud based APIs. S3 for object store, k/v distributed store for more high performance/smaller records, authenticating APIs (from any cloud vendo

1. Use managed cloud based APIs. S3 for object store, k/v distributed store for more high performance/smaller records, authenticating APIs (from any cloud vendor, like Auth0), etc. 2. Use a managed cloud orchestration system. Autoscaling groups, AWS ECS Fargate, App runner frameworks, Serverless, Managed K8s. 3. Run operations from chatops, gitops, or a web UI. By making operations work over a remotely accessible communications tool, you can make changes from anywhere, anytime, and never have to deal with local environment setup or resource constraints. 4. Do development in the cloud (Cloud Shell, Codespaces, DevSpace, etc). Same rationale as #3. 5. Mahe everything as immutable as possible. If something fails, throw it away and replace it with a known good artifact. If you can't run it from an API and pay someone to manage it, it's a waste of your time and money and not reliable. Don't be your own car mechanic for your business; lease a truck. If it ever takes off, you can easily give others access. And you can use this pattern for anything.

planb 4y ago
This is very much the opposite of the advice I would give: Keep it simple and rely on proven methods, keeping in mind what might go wrong and how to fix it. Just because you don't have to care for kernel updates or broken disks does not mean nothing can go wrong. I don't think there are many solo founders that know all the possible failure modes of these complex services you mention...
- throwawaaarrgh 4y ago
  Those things I mention are simpler than what you suggest. If they fail, the solution is "wait", because the cloud vendor maintains it. But they generally won't fail, because they're designed to be HA. Worst case you open a support ticket.
syats 4y ago
This is bad advice for a couple of reasons: 1. It is expensive. 2. It moves complexity away from you and onto your providers, so it doesn't really solve the problem, only hides it from you (at a price). 3. The overall cost (energy, person-hours, material) of even the smallest project grows a lot with this approach. Even if you have the money to pay for it, you are wasting a bunch of resources around the world just for an illusion of peace of mind. 4. Most importantly, it will still fail (as all systems eventually do) and then you have no idea where it failed or how to fix it. All you can do is file some support tickets at big-corp support center and watch for updates on their twitter feed. A lot of people complain here on HN about the sad, over-complicated, state of software-engineering, the need to know more and more concepts and to manage more and more tech "stacks" just to accomplish boring, formerly simple, tasks. One reason for this sad state is the philosophy expressed in the parent comment.

planb 4y ago

This is very much the opposite of the advice I would give: Keep it simple and rely on proven methods, keeping in mind what might go wrong and how to fix it. Just because you don't have to care for kernel updates or broken disks does not mean nothing can go wrong. I don't think there are many solo founders that know all the possible failure modes of these complex services you mention...

throwawaaarrgh 4y ago
Those things I mention are simpler than what you suggest. If they fail, the solution is "wait", because the cloud vendor maintains it. But they generally won't fail, because they're designed to be HA. Worst case you open a support ticket.

syats 4y ago

This is bad advice for a couple of reasons: 1. It is expensive. 2. It moves complexity away from you and onto your providers, so it doesn't really solve the problem, only hides it from you (at a price). 3. The overall cost (energy, person-hours, material) of even the smallest project grows a lot with this approach. Even if you have the money to pay for it, you are wasting a bunch of resources around the world just for an illusion of peace of mind. 4. Most importantly, it will still fail (as all systems eventually do) and then you have no idea where it failed or how to fix it. All you can do is file some support tickets at big-corp support center and watch for updates on their twitter feed. A lot of people complain here on HN about the sad, over-complicated, state of software-engineering, the need to know more and more concepts and to manage more and more tech "stacks" just to accomplish boring, formerly simple, tasks. One reason for this sad state is the philosophy expressed in the parent comment.