21–30 of 261 posts
I'm curious how many engineers per year this costs to maintain
Earlier quoted context omitted.
> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !
With s3, you cannot use ls, grep and other tools. > Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Wow that's a lot to learn before using s3... I wonder how much it costs in salaries. > With what network topology? You don't need to care about this when using SSDs/HDDs. > With what ac…
You do need to care when you move beyond a single server in a closet that runs your database, webserver and storage.
> No risk of leaking files due to misconfigured cloud services.
One misconfigured .htaccess file for example, could result in leaking files.
Earlier quoted context omitted.
> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !
You can't ever definitively answer most of those questions on someone else's cloud. You just take Amazons word for whatever number of nines they claim it has.
Tbh I feel this in one of those that would be significantly cleaner without serverless in first place. Sticking something with 2 second lifespan on disk to shoehorn it into aws serverless paradigm created problems and cost out of thin air here Good solution moving at least partially to a in memory solution though
Yeah, so now you're basically running a heavy instance in order to get the network throughput and the RAM, but not really using that much CPU when you could probably handle the encode with the available headroom. Although the article lists TLS handshakes as being a significant source of CPU usage, I must be missing something because I don't see how that is anywhere near the top of the constraints of a system like thi…
Earlier quoted context omitted.
With s3, you cannot use ls, grep and other tools. > Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Wow that's a lot to learn before using s3... I wonder how much it costs in salaries. > With what network topology? You don't need to care about this when using SSDs/HDDs. > With what ac…
I mean you can easily mount the S3 bucket to the local filesystem (e.g. using s3fs-fuse) and then use standard command line tools such as ls and grep.
Earlier quoted context omitted.
> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !
With s3, you cannot use ls, grep and other tools. > Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Wow that's a lot to learn before using s3... I wonder how much it costs in salaries. > With what network topology? You don't need to care about this when using SSDs/HDDs. > With what ac…
I'm curious how many engineers per year this costs to maintain
The end of the article has this:
> Consider custom infrastructure when you have both: sufficient scale for meaningful cost savings, and specific constraints that enable a simple solution. The engineering effort to build and maintain your system must be less than the infrastructure costs it eliminates. In our case, specific requirements (ephemeral storage, loss tolerance, S3 fallback) let us build something simple enough that maintenance costs stay low. Without both factors, stick with managed services.
Seems they were well aware of the tradeoffs.
[flagged]
It's the government who lost 850TB of citizen data with no backups[0] Because Cloud bad. [0] https://www.techradar.com/pro/security/the-south-korean-gove...
Earlier quoted context omitted.
With s3, you cannot use ls, grep and other tools. > Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Wow that's a lot to learn before using s3... I wonder how much it costs in salaries. > With what network topology? You don't need to care about this when using SSDs/HDDs. > With what ac…
I mean you can easily mount the S3 bucket to the local filesystem (e.g. using s3fs-fuse) and then use standard command line tools such as ls and grep.
Earlier quoted context omitted.
And I am curious how many engineer years it requires to port code to cloud services and deal with multiple issues you cannot even debug due to not having root privileges in the cloud. Without cloud, saving a file is as simple as "with open(...) as f: f.write(data)" + adding a record to DB. And no weird network issues to debug.
> as simple as "with open(...) as f: f.write(data)" Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and... Without on-prem, saving a file is as simple as s3.put_object() !
> Save where? With what redundancy? With what access policies? With what backup strategy? With what network topology? With what storage equipment and file system and HVAC system and...
Most of these concerns can be addressed with ZFS[0] provided by FreeBSD systems hosted in triple-A data centers.
See also iSCSI[1].