Multi-cloud is mostly just a meme. Especially if you’re trying to run an active-active multicloud environment. You can try it, but it will always suck, and never work properly.
If you want to be service provider agnostic, run everything in your own kube and host your own CI/CD tooling. You won’t have real-time RTOs, but you’ll be able to get yourself up and running basically anywhere pretty quickly if you have to.
Also, the single biggest lock-in feature for AWS is IAM, and most people never even think about it. So be careful with how you use that if you want to be able to move smoothly.
Edit: and if you’re going to run your own kube, use Knative. Makes it so much easier.
What's your expert opinion on Tahoe-LAFS? How would you build the front-end for a web service using the distributed data, so that if the node/web server was compromised it would have no impact on the whole?
Services like that can be an ok solution for distributed object/file storage. They have a few serious drawbacks though.
For starters, the networks themselves tend to be very fragile. This is partly because all applications in this category are still rather immature development-wise, and partly because these networks need to be very widely adopted to work properly. There are no services like this that are widely adopted enough to actually provide the resiliency they’re aiming for.
More importantly, these type of services are not fit for the purpose of providing the persistence layer to a web app. You can’t just put a front-end in front of this sort of object storage. You need an intermediate web server to retrieve, decrypt and serve the data. This would cause at least two problems. Each document (every post, and every comment on td.win, or parler for instance) would need to be independently stored as its own object on the network. It basically wouldn’t be possible to rely on any sort of consistency in a system like this, and it would be monumentally slow. Furthermore, even if you go to all the effort of getting something like this to be almost functional, you haven’t actually removed the need to have a hosted web server as a point of failure. So you’ve basically done all of that for nothing.
A couple more issues you’ll run into are that in order to get resiliency out of these services, you need to massively over provision for redundancy. Which ends up being very expensive. These services also tend to compensate the storage providers based on storage rather than storage and bandwidth, so you’ll run into issues of host nodes ditching you if you’re a high bandwidth service. Especially if you’re being DDoS’d, which these services don’t really provide a mechanism for dealing with.
They have limited uses in simple forms of content distribution or backup, but for a full web application like td.win, which needs a functional database backend, these services don’t work, and won’t any time soon.
yeah multi cloud in general
And if is there any orchestration tools to set that up so you can have networks from 3 different clouds connected up and balancing traffic etc
or does it need to be rigged up manually?
Multi-cloud is mostly just a meme. Especially if you’re trying to run an active-active multicloud environment. You can try it, but it will always suck, and never work properly.
If you want to be service provider agnostic, run everything in your own kube and host your own CI/CD tooling. You won’t have real-time RTOs, but you’ll be able to get yourself up and running basically anywhere pretty quickly if you have to.
Also, the single biggest lock-in feature for AWS is IAM, and most people never even think about it. So be careful with how you use that if you want to be able to move smoothly.
Edit: and if you’re going to run your own kube, use Knative. Makes it so much easier.
What's your expert opinion on Tahoe-LAFS? How would you build the front-end for a web service using the distributed data, so that if the node/web server was compromised it would have no impact on the whole?
Services like that can be an ok solution for distributed object/file storage. They have a few serious drawbacks though.
For starters, the networks themselves tend to be very fragile. This is partly because all applications in this category are still rather immature development-wise, and partly because these networks need to be very widely adopted to work properly. There are no services like this that are widely adopted enough to actually provide the resiliency they’re aiming for.
More importantly, these type of services are not fit for the purpose of providing the persistence layer to a web app. You can’t just put a front-end in front of this sort of object storage. You need an intermediate web server to retrieve, decrypt and serve the data. This would cause at least two problems. Each document (every post, and every comment on td.win, or parler for instance) would need to be independently stored as its own object on the network. It basically wouldn’t be possible to rely on any sort of consistency in a system like this, and it would be monumentally slow. Furthermore, even if you go to all the effort of getting something like this to be almost functional, you haven’t actually removed the need to have a hosted web server as a point of failure. So you’ve basically done all of that for nothing.
A couple more issues you’ll run into are that in order to get resiliency out of these services, you need to massively over provision for redundancy. Which ends up being very expensive. These services also tend to compensate the storage providers based on storage rather than storage and bandwidth, so you’ll run into issues of host nodes ditching you if you’re a high bandwidth service. Especially if you’re being DDoS’d, which these services don’t really provide a mechanism for dealing with.
They have limited uses in simple forms of content distribution or backup, but for a full web application like td.win, which needs a functional database backend, these services don’t work, and won’t any time soon.