From: Tomas Volf <~@wolfsden.cz>
To: Vincent Legoll <vincent.legoll@gmail.com>
Cc: "Vagrant Cascadian" <vagrant@debian.org>,
"Ludovic Courtès" <ludo@gnu.org>,
guix-devel@gnu.org, guix-sysadmin <guix-sysadmin@gnu.org>
Subject: Re: Sustainable funding and maintenance for our infrastructure
Date: Tue, 9 Jul 2024 11:47:38 +0200 [thread overview]
Message-ID: <Zo0HOpEidiBsjmvd@ws> (raw)
In-Reply-To: <CAEwRq=oAAXb0WFW0zGBu2xbgVUw9DgnL65i9Q2m4UNES6Smo0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]
On 2024-07-08 18:28:23 +0000, Vincent Legoll wrote:
> Hello,
>
> On Mon, Jul 8, 2024 at 3:47 PM Vagrant Cascadian <vagrant@debian.org> wrote:
>
> > This may be a little wild, but what are the downsides to doing some
> > combination of all of the above?
> >
> > A mixed strategy could reduce ... the upfront cost of buying and hosting
> > hardware (#1), the ongoing costs of renting (#2), and dependence on the
> > generosity of a third party for sponsored hardware & hosting (#3).
> >
> > It seems like any strategy should have some redundancy (e.g. multiple
> > independent build farms) so that a failure in one datacenter does not
> > effectively take down the whole network...
> >
>
> That would be my opinion too.
>
> But for the cloud renting I would first research if there are associated
> network or other costs,
Yes, there are other costs. You in general pay for the egress used. I have no
idea how much traffic does our current farm use. I will speak of AWS, because
that is the one I know, but other will be likely similar. If we would have
setup just in one "Availability Zone" (think data center), traffic between VMs
is free. Traffic to the internet however is not. First 100 GB is free each
month, and after that (source [0]):
First 10 TB / Month $0.09 per GB
Next 40 TB / Month $0.09 per GB
Next 100 TB / Month $0.07 per GB
Greater than 150 TB / Month $0.05 per GB
The prices differ by region a bit, but Europe and US are the "cheap" ones.
Interesting point is that someone can just decide to download a lot from you,
and *you* would pay for it. It is nice way to drive up bill of someone you do
not like.
You also pay for storage and various other things. Doing cost estimates in the
cloud is hard, because everything is complex and there are lot of options to
spend on.
Than there also is the "moral" side of the clouds.
> because the computing is cheap only to lure you into the (sometimes
> prohibitive) hidden costs.
Even the computing is not cheap by itself, if you just want compute, Hetzner is
cheaper. Clouds give the nice things on top, like storage snapshots, backups,
... (ignoring the cost). But, at least in my experience, not cost saving,
unless you radically re-design your application/stack to match the cloud
providers infrastructure.
Naive "lift and shift" migrations to the cloud can have tangible benefits, but
cost saving is rarely one of them.
Now, this all describes just actual "clouds". Hetzner, for example, does not
charge for traffic (with some exceptions[1]). You pay 2 EUR for public IPv4,
but other than that, I did not notice any unexpected charges on my invoices.
I personally think that renting actual physical servers might be a reasonable
idea. One issue to consider is that (Hetzner in particular) has a history of
MitM attacks against their customers (assumption is that it was due to court
order, but it was never confirmed AFAIK). So I would expect physical compromise
(signing keys) to be possible as well. I have no idea how that would compare to
the security in the current hosting.
Have a nice day,
Tomas
0: https://www.cloudflare.com/learning/cloud/what-is-aws-data-transfer-pricing/
1: https://docs.hetzner.com/robot/general/traffic/
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-09 9:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 14:24 Sustainable funding and maintenance for our infrastructure Ludovic Courtès
2024-07-03 1:13 ` indieterminacy
2024-07-04 16:37 ` Simon Tournier
2024-07-08 12:02 ` Ricardo Wurmus
2024-07-09 14:49 ` Simon Tournier
2024-07-11 9:23 ` Ludovic Courtès
2024-07-08 15:46 ` Vagrant Cascadian
2024-07-08 18:28 ` Vincent Legoll
2024-07-09 9:47 ` Tomas Volf [this message]
2024-07-11 10:33 ` Andreas Enge
2024-07-11 20:44 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-11 9:38 ` Ludovic Courtès
2024-07-12 10:44 ` Simon Tournier
2024-07-21 12:52 ` Ludovic Courtès
2024-07-08 16:27 ` Efraim Flashner
2024-07-08 17:21 ` Enrico Schwass
2024-07-11 10:48 ` Andreas Enge
2024-07-11 9:28 ` Ludovic Courtès
2024-08-01 22:11 ` Marek Paśnikowski
2024-08-13 2:53 ` Jonathan Frederickson
2024-08-13 16:23 ` Sergio Pastor Pérez
2024-08-13 23:38 ` Jonathan Frederickson
2024-08-14 13:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-08-24 23:15 ` Jonathan Frederickson
2024-08-21 22:07 ` P2P Guix package building and distribution Christine Lemmer-Webber
2024-08-22 9:05 ` Andreas Enge
2024-08-22 21:57 ` Samuel Christie via Development of GNU Guix and the GNU System distribution.
-- strict thread matches above, loose matches on Subject: below --
2024-07-02 14:26 Sustainable funding and maintenance for our infrastructure Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zo0HOpEidiBsjmvd@ws \
--to=~@wolfsden.cz \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=ludo@gnu.org \
--cc=vagrant@debian.org \
--cc=vincent.legoll@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).