shosti

https://www.iea.org/reports/direct-air-capture-2022/executiv... suggests $125-$335 per ton, so not quite an order of magnitude but still a big difference for CCS.

> According to [2], the cost to reclaim CO2 from natural gas sources is approximately $90 per ton on the high end

I may be reading that wrong, but I'm pretty sure that refers to the CCS cost when you capture at use (e.g. in a power plant). You can't really use CCS when you're heating a house, so the right price to compare to would be direct air capture which is an order of magnitude more expensive IIUC.

It's buried in the article, but the 77% number seems to be based on resistance heating instead of heat pumps:

> the annual energy bill to operate a standard gas furnace/AC combination is about $633 a year. With a heat pump, she said, it would likely be $609 to $718 annually, depending on the heat pump technology chosen and its configuration.

Ingresses on EKS will set up an ALB that sends traffic directly to pods instead of nodes (basically skips the whole K8s Service/NodePort networking setup). You have to use ` alb.ingress.kubernetes.io/target-type: ip` as an annotation I think (see https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress...).

The ingress controller is so I can have multiple public apps and configure them with Ingresses (definitely possible to do the overall setup with just cloudflared but I wanted to use built in ingress objects instead of a complicated cloudflared config).

I feel like Tailscale gets you pretty close to an “easy private cloud”, it’s just the “public” part that’s still a bit tricky.

Yeah this is basically what I was planning to do before I learned about cloudflared.

Yeah that’s what I would do if I was just hosting a blog, I already had the k8s lab set up for other reasons and wanted to get more use out of it.

I would say you don't really need Kubernetes for this sort of setup (I already was running all the K8s stuff which is why I went with it, but docker compose or even just running things in systemd without containers would work too).

I think the main thing is to have some sort of network isolation (like a separate VLAN or a server that blocks outbound traffic) between stuff that's exposed to the internet and stuff that's private on the network.

(Author here) I mostly worry about security for this. If you have nothing private on your network it's probably fine, but if you have, say, a NAS that isn't using proper authentication (pretty common), an os/nginx vulnerability could end up exposing stuff.

Of course there are much simpler ways to lock things down also :)

(Author here) I’m kind of cruel to my hardware lol (they’re all frankenservers hacked together with random parts from eBay). I’m not doing anything fancy to protect from dust and whatnot, but it’s pretty much always chilly in the garage (and I’m using low power parts) so heating hasn’t been an issue.

Thanks, glad you liked it! Minor clarification, I didn’t write the ingress comparison, that’s from https://learnk8s.io (who I’ve been working with recently). They have a bunch of awesome resources on their site.

Location: San Francisco

Remote: Open to it

Willing to relocate: No

Technologies: Go, Kubernetes, Postgres, Ruby/Rails, AWS/GCP, TypeScript, Rust

Résumé/CV: https://www.linkedin.com/in/emanuelevans/

Email: in@eevans.co

I've been working as a Cloud Architecture consultant for the past couple years (previously worked in startups). I'm looking to move to full time for the right opportunity.

This was a project I implemented for fun to try to understand how Raft works (and also get more practice with Rust). The basic idea is that some state gets synchronized between 3 browser windows (currently hard-coded) over WebRTC. It's pretty fast if you're on the same machine (I've seen ~2000 writes/second on Chromium).

It's probably not useful for real applications in its current form, but I could potentially see some use cases in peer-to-peer browser applications.

SEEKING WORK | USA (UTC-8) | REMOTE

Website and portfolio: https://eevans.co

Technologies: Kubernetes, Google Cloud, AWS, Docker, Terraform, Go, others

I specialize in cloud migrations, particularly in deploying applications to Kubernetes and setting up infrastructure with Terraform. I've worked with both startups and larger enterprise companies.

I'm also open to running Kubernetes training workshops or coding work (under the right circumstances).

Email: hn@eevans.co (or contact me through my website)

> This part seems very hand wavy, given that Heroku Shield would've solved many (all?) of their problems.

Author here; I don’t want to go into too much detail, but we tried Shield early on and had a negative experience that made us wary about using the platform (it seems to use a different tech stack under the hood from “normal” Heroku and lacks a lot of the things that make Heroku great). Also it’s very expensive compared to VPC-based solutions on AWS and GCP.

W.R.T. the batch jobs, I think I didn’t explain super well—we are using a different language and runtime from our “normal” background processing jobs (which use worker queues in Rails), it’s just that Heroku isn’t very well suited for the use case (which is basically FaaS-like but with long-lived jobs).

The “split” workflow you described is basically what we were doing (but with AWS Batch instead of Dokku); it’s just that it’s more cost-efficient to consolidate everything into one cluster (especially with preemptible gke nodes) and also better to have a common set of tooling for the Ops team.

To be fair, we haven’t yet completed the move from Batch to k8s so it’s possible that part of the plan won’t pan out as expected.

Yeah AWS Aurora does have some nice capabilities compared to Cloud SQL; if it weren’t for the other issues mentioned in the article it would have been a driving factor towards choosing AWS. Still Cloud SQL seems “good enough” in general (other than the somewhat ungraceful way maintenance is handled); I’d be curious to hear if there are particular issues you ran into that made you switch to unmanaged SQL?

Author here; yeah, helm is the part of our stack we’re least happy with tbh (it’s turned into a huge pile of templated yaml files for each project that seems like it might not be maintainable long-term). I’m curious about looking into kustomize, but the package management/rollback capabilities of helm are quite nice; is there a good “pre-baked” solution for that that doesn’t involve helm?