I don't know how big sufficiently large codebase is, but we have a 1mil loc Java application, that is ~10years old, and runs POS systems, and Claude Code has no issues with it. We have done full analyses with output details each module, and also used it to pinpoint specific issues when described. Vibe coding is not used here, just analysis.
This is highly dependent on the use case. Backblaze gives you 3x free egress, but after you hit that you pay for any additional egress. Wasabi has terms of use not to exceed 1x your storage, but is not in their model to pay egress. As a long-term storage user, you can restore a full system-wide backup without any concern of charges at Wasabi(typically, you're not restoring everything, just recent backups), as long as you are not consistently doing it. Backblaze will get you more egress for sharing data over the public internet, but if you need more, you will get charged.
> typically, you're not restoring everything, just recent backups
Not knowing the pricing difference between the two and assuming they are similar, I would favor Backblaze as it would allow me to exceed the limit if I needed. Based on how you framed it, I would expect that with Wasabi you might hit a hard limit.
Wasabi doesn't have an egress hard limit and doesn't charge for egress. You get consistent pricing, and if you need to recover everything, it's not an issue at all, and you won't pay for it.
"The reasonable use egress policy indicates that if your monthly downloads (egress) are greater than your active storage volume, then your storage use case is not a good fit for Wasabi’s free egress policy, and we reserve the right to limit or suspend your service."
If you're using Wasabi for normal backup data storage, you shouldn't worry about egress. It is meant to prevent malicious users from uploading data and using up all the egress bandwidth, for example, a 500GB user egressing 5TB with public access or using Wasabi as a dump point to upload in one location and download in another region 1:1 ratio. As your storage goes up, your available consistent monthly egress goes up. It only becomes an issue if you abuse the account by uploading/downloading in a 1:1 ratio on a consistent basis.
What happens is you get an email from support asking if something changed in your use case. If so, they will help troubleshoot it(Think of a CDN scenario, where the CDN gets misconfigured). You also have an egress monitor for suspicious activity in case you aren't normally downloading all your data, and then you see a rise in egress https://docs.wasabi.com/docs/en/whats-new?highlight=egress#e....
problem with wasabi is that their ToS are not concrete with their conditions. backblaze is specific. black on white. no buts of ifs. you know exactly what you pay for. with wasabi, you don't. if you run a business, wasabi is not the way to go. if you run personal things, it is an ok option. but in the end, 1x vs 3x is such a major difference, that there is just no point in discussing it.
I don't think this needs to be an all-or-nothing thing, and aside from a few items, it seems pretty standard. We start off with the Zero to Prod model, and when handlers become too large, move them over to "Repository" types. GET usually stays in the handler, vs POSTing a new request for an action that may include several DB calls, channels, async tasks etc.. goes into a "Service" type crate. Its usually little work though. As far as separating "entities" from requests/responses, that seems to be the norm in any language/framework. You don't want secrets to be responded when you create something, or all of your internal properties. When there starts to be too many config knobs, things are extracted to their respective places. I like that this lays out out a framework for it. It doesn't necessarily mean I would start there.
Not the person you’re replying to but the company I work for switched to Bandwidth.com as our SMS/Voice provider.
To call Twilio’s 10DLC handling “incompetent” would be a major understatement. In general Twilio was horrible to work with, we’d jump through all their hoops and they’d still block our messages randomly.
Which doesn't really matter. At some point you have to admit defeat, and find a new name to distinguish yourself - if not for any other reason then just for SEO optimization: you want to be the first Google result when someone searches your name.
I worked for a service provider doing some cellular testing and we had a special clear box that did this. It was probably expensive at the time. I wonder how well those faraday bags or boxes for $20 work from amazon or ebay.
This thing works great. It's loaded in my local 5-node(2x3) k8s cluster, with a Coral TPU plugged into a single node. I have 6 4k cameras running, and it does object analysis on all of them with < 10% CPU on the node.
I run this too on k8s, but there's no benefit of running on k8s because the app doesn't benefit from multiple pod / clustering. Unless I'm missing something, there's no real advantage to running on k8s compared to docker. It would be cool if each camera stream could be spawned off to a pod so that it could leverage clustering.
I'm very aware of the encryption options AWS and other clouds provide.
Yet I've never seen those options being used. Additionally one has to trust the implementation provided by the cloud. Surely people can encrypt on the source ( and some do) but that's rare as well.
People encrypt at rest because it is a specific requirement that the data is encrypted at rest. Maybe to meet regulatory requirements or orders from above. Regulators are not going to object to data being handed over on court orders.
If the regulator or the management requiring it are OK with the cloud provider doing it (and AWS and the like do their best to ensure that) then using their keys and key management is the easiest way to do it.
Apart from cloud backups, in most cases the data will be decrypted in their cloud anyway, so you have to trust them.
There are a few things you need to keep in mind with Wasabi. Depending on your payment method, there is a 90-day or 30-day minimum storage duration policy. This means that if you upload an object, then 30 days later, delete the object. You will be billed as if the object is active(even though it is truly deleted) for another 60 days. You may use more than expected if you have high amounts of short-duration churn of your data. If you have long-duration storage needs, this is great.
The other thing is that while egress is free, there is a fair egress policy. This means you should not egress more than you store on Wasabi monthly.
For example, if you want to host web assets, Wasabi could be a good fit if you use a CDN to frontend all the egress. However, if you do not use a CDN, you will use up your egress ratio quickly. While there are no extra charges, you will get notifications from the support team to figure out the issue.
Other than that, if you are looking for object storage and neither of the above bothers you, Wasabi is a great high-performance object storage vendor with predictable pricing.
I didn't know about their fair use policy. I planned to keep having Cloudflare as CDN fronting storage.
You know of another S3 compatible store without fair use policy?
On the minimum days duration policy. If one has a public application backed by Wasabi, this is hard to predict. Time we show.
After all, maybe calculate in the cost of a platform like Cloudflare to create a proper business plan. Wasabi seems uncertain in terms of being really that cheap on the long run (for certain use cases).
