I never had the "hands off" hosting experience that cloud providers advertise in the first place. Before (with AWS and Heroku) if things went down, I was the person that had to investigate and escalate to the appropriate vendor's support. Now, I'm the person responsible for investigating and fixing things. For many small issues, it's easier to fix them than to get someone at AWS with the necessary clearance on the phone.
One big trade-off is that I only have one datacenter so in cloud lingo, I only offer one availability zone with offsite backups. But then again, when AWS us-east went offline, so went most companies, because the proudly advertised multi-AZ failover didn't work that well in practice.
As for the APIs, I just limit the subset of APIs that I offer. Since this is used only for my consulting clients, my cloud only needs to support those APIs that they require. In effect, that means CEPH+PostgreSQL do most of the heavy lifting.
I've seen Cloud APIs explode in funny ways when customers actually arrive with Petabyte-scale datasets. In that sense, my customers are pre-qualified because all of them have had horrible experiences with Cloud providers over-promising and under-delivering. So once they are on my platform, dissuading them from wanting more APIs is very easy. "Would you like to continue to use my cloud at the current price? Or would you like to pay 3x the monthly spend just to use the Amazon cloud and gain API call XY? And please remember the last time they crashed badly and you could not reach any Amazon support by phone. Didn't they even bill you for EC2 while it was unreachable?"
And if they insist, I can always point them towards the Open Source project that Amazon/Heroku use under the hood. But in my opinion, most Cloud APIs don't add business value anyway. "Keep it simple" always wins out in the long run.
> I never had the "hands off" hosting experience that cloud providers advertise in the first place.
We've had exactly the same experience. From a business perspective it does mean that you can shift the blame if something goes down but it still impacts your product all the same. And you're left without the ability to directly fix the underlying issue. Most of our infrastructure runs on our own hardware out of a single datacenter and we've been able to get significantly better performance/ value. I love your approach of commoditizing your complement and acquiring a hosting provider.
Point of clarification: us-east-1 is an entire AWS Region, which contains multiple availability zones. Multi-AZ setups in AWS are generally fairly straightforward, multi-region generally isn't.
...that said, one of the key techniques most people use for failing over between regions is changing DNS, which wouldn't have worked with Route 53 in this instance because its control plane is in us-east-1, so it's not like AWS looks spotless even in this analysis.
Judging from your username, you're affiliated with rsync.net. If that is correct, then no. That's a very interesting service for offsite backups, though. At the moment, I just rent colocation with lots of HDDs inside and do the RAID management myself.
> How can we work with you ?
That depends on what you need and how long you can wait. I've already committed to launching 2 AI-based products in 2022, so currently it looks like I'll be fully busy until end of the year.
But most of my customers used RDS and are now on MySql, MariaDb, or PostgreSql. Similarly, S3 -> CEPH. Nginx as front-end, Varnish as cache, Ha-Proxy for load balancing. Queues? RabbitMQ. Map-Reduce? Hadoop. Lots of data? ZFS.
There are A LOT of great open source projects to base your infrastructure on.
One big trade-off is that I only have one datacenter so in cloud lingo, I only offer one availability zone with offsite backups. But then again, when AWS us-east went offline, so went most companies, because the proudly advertised multi-AZ failover didn't work that well in practice.
As for the APIs, I just limit the subset of APIs that I offer. Since this is used only for my consulting clients, my cloud only needs to support those APIs that they require. In effect, that means CEPH+PostgreSQL do most of the heavy lifting.
I've seen Cloud APIs explode in funny ways when customers actually arrive with Petabyte-scale datasets. In that sense, my customers are pre-qualified because all of them have had horrible experiences with Cloud providers over-promising and under-delivering. So once they are on my platform, dissuading them from wanting more APIs is very easy. "Would you like to continue to use my cloud at the current price? Or would you like to pay 3x the monthly spend just to use the Amazon cloud and gain API call XY? And please remember the last time they crashed badly and you could not reach any Amazon support by phone. Didn't they even bill you for EC2 while it was unreachable?"
And if they insist, I can always point them towards the Open Source project that Amazon/Heroku use under the hood. But in my opinion, most Cloud APIs don't add business value anyway. "Keep it simple" always wins out in the long run.