Someone made a good reply to this and as I was replying to that they deleted it, so I'll copy it here:
----
> Have you actually done a cost-benefit analysis on some of these solutions?
Yes, I even gave a talk at google in stockholm about it.
For my use-case, hybrid was best, with no cloud lock-in aside from Google Storage Buckets (which can be replaced) but I went into detail about that in the talk.
> Take your Riak / S3 plugin. What do your servers cost to run that cluster?
Depends a lot, don't you think?
> How much time do you spend managing it?
Depends again, if it's anything like my elasticseach clusters then about 2-man hrs/mo.
> How do you test your backups?
Continuously, and with alerting.. and, you should be doing this anyway.
> Are you going to target the same SLOs for durability that S3 offers?
Depends on the business, the whole point of SLO is that you pay in what it's worth to the business.
> Do you run multi-data center for high availability?
Depends on SLO.
> In many cases the cheaper or self-hosted solutions have costs that you aren't accounting for.
Yes, physical machines often need some hand-holding, VPS's can have brown outs, but this is true in AWS's EC2 anyway.
Ultimately, this is where the cost increase will be.. but defining it is important, I've deployed cloud and physical (as stated) and it's true that physical machines are not as problem-free as our GCE ones- but we pay about 50% less than the GCE equiv instances, so it's "worth" spending time automating the unpredictable.
> Sometimes that's fine, but "just run it yourself" is as worthless as saying "just ship it to AWS" unless you actually think through the impact.
This is kind of the main point I always make.. understand your trade-offs, don't buy into proprietary tech. Cloud is a fantastic way to prototype and bootstrap but it's /usually/ better to have a migration plan to optimise costs in the future.
If you fail to take that into account then I don't have sympathy for you, because you put the project at risk. Financial in-viability is a risk.
That was me ;) I deleted it because I read your second post and realized I'd completely misread you and actually agree almost in entirety.
> understand your trade-offs, don't buy into proprietary tech. Cloud is a fantastic way to prototype and bootstrap but it's /usually/ better to have a migration plan to optimise costs in the future.
----
> Have you actually done a cost-benefit analysis on some of these solutions?
Yes, I even gave a talk at google in stockholm about it.
For my use-case, hybrid was best, with no cloud lock-in aside from Google Storage Buckets (which can be replaced) but I went into detail about that in the talk.
> Take your Riak / S3 plugin. What do your servers cost to run that cluster?
Depends a lot, don't you think?
> How much time do you spend managing it?
Depends again, if it's anything like my elasticseach clusters then about 2-man hrs/mo.
> How do you test your backups?
Continuously, and with alerting.. and, you should be doing this anyway.
> Are you going to target the same SLOs for durability that S3 offers?
Depends on the business, the whole point of SLO is that you pay in what it's worth to the business.
> Do you run multi-data center for high availability?
Depends on SLO.
> In many cases the cheaper or self-hosted solutions have costs that you aren't accounting for.
Yes, physical machines often need some hand-holding, VPS's can have brown outs, but this is true in AWS's EC2 anyway.
Ultimately, this is where the cost increase will be.. but defining it is important, I've deployed cloud and physical (as stated) and it's true that physical machines are not as problem-free as our GCE ones- but we pay about 50% less than the GCE equiv instances, so it's "worth" spending time automating the unpredictable.
> Sometimes that's fine, but "just run it yourself" is as worthless as saying "just ship it to AWS" unless you actually think through the impact.
This is kind of the main point I always make.. understand your trade-offs, don't buy into proprietary tech. Cloud is a fantastic way to prototype and bootstrap but it's /usually/ better to have a migration plan to optimise costs in the future.
If you fail to take that into account then I don't have sympathy for you, because you put the project at risk. Financial in-viability is a risk.