231–240 of 268 posts
Earlier quoted context omitted.
Doubtful. I've personally had projects pull many hundreds of gigabits per second of s3 throughput. How you architect and design has a large influence to your analytics performance.
“Many hundreds” Last time I talked to a technical person at AWS the limit was 5GBits. Wonder what you’re doing differently. Perhaps that changed.
Earlier quoted context omitted.
My estimates - the company had a combined total of $200,000 dollars in credits across both clouds and the OP charged $10,000 for the migrations.
You're reasonably in the ballpark. It was complicated a bit because hosting on Hetzner was so much cheaper for them that $1 in credit was not worth $1 to them, as if/when they had to spend cash they spent substantially less than that at Hetzner.
I switched from Heroku to AWS, then eventually back to Heroku. Heroku to AWS was for cost reasons (cut monthly costs by roughly 35%) but wasn't enough savings to justify hiring a devops person. As soon as there were too many issues I didn't know how to fix (setting up everything Heroku offers was hard and likely done wrong, which made ongoing maintenance some level of hell), I switched back to Heroku where the lack o…
Earlier quoted context omitted.
> But most companies' dream is to reach that ""inevitable"" point where the cloud saves it; it becomes a bet where they either reach that level of scale, or die trying. And how many die trying due to bleeding all the funding to AWS, instead of running everything off a couple cheap boxes underneath the CTOs desk? I've been in at least one which ran out of money that way. Don't pay for the future pipedream now, pay for…
AWS gives away literally tens of thousands of pounds to start ups. Granted, it's to lock them in down the line but getting free credits gets you further than not having credits.
Earlier quoted context omitted.
This! I benchmarked a whole bunch of different cloud providers for fun (& my bachelor thesis) and was impressed by how bad some cloud VPS perform. Considering the really steep price to get any kind of significant memory/CPU resources with the major cloud providers as well as the steep bandwidth charges this little experiment was eye opening
Could you please share your thesis? Maybe over email?
Every provider has severe downtime (when even phone lines are not operational) so we do failover across several providers. Saved a lot of uptime for us.
Also we do not use (almost) vendor-specific solutions. Almost everything your cloud provider sells up to you can be achieved without using the provider lock. Will save time later when provider quality goes into sh*t (eventually happens) and you have to migrate your infra somewhere.
Earlier quoted context omitted.
I searched for exactly those 3 words on Duckduckgo.com and got https://docs.ovh.com/us/en/publiccloud/ai/training/build-use... which is a tutorial for what I use.
Docker and AI are technologies used on the OVH host, it's not part of the product itself...
In my company, we were aware about the potential honeypots in each cloud and we developed our product from the first commit to be deployed on 3 (!) clouds: AWS, Azure, IBM. And while we made it work by sticking to the least common denominator which was FaaS/IaaS (Lambda, S3, API GW, K8s). It was certainly not easy. We also ignored tools that could've helped us greatly only against a single cloud in order to be multi…
Was it a business or technical decision to do multi-cloud? Did you run simultaneously in 3 clouds? Can you explain the setup? If not, did you do just run on each for a while to test, or have a reason to switch? This is probably an impossible question to answer, but: were the savings/benefits of doing this actually worth the engineering costs involved in the end? Eg even if you chose what turned out to be the most exp…
> Did you run simultaneously in 3 clouds? Can you explain the setup?
The solution itself could be running on a single cloud. But we work in the finance sector and targeting highly regulated clients. And we got a tip very early on, that each client could ask for deployment on their cloud account that is monitored by them. Which will probably be AWS or Azure. Today we know only some require that. So it helped somewhat.
> were the savings/benefits of doing this actually worth the engineering costs involved in the end?
Like you said, very hard to know. In our case, we had a DevOps Cloud guy working a full time job, so, it was not noticeable. Reason being, Probably,
[1] Because although he had problems to solve on all clouds, clouds deployments eventually get stable enough, So pressure was spread.
[2] Although all clouds still need constant maintenance, it's a-synchronic (you can't plan ahead when AWS EKS K8s will force a new version), so pressure was spread out and it never stopped client feature building.
But who knows, maybe for other architectures or a bigger company, it would have become noticeable.