HN user

deserialized

116 karma
Posts0
Comments72
View on HN
No posts found.

My experience with LG&E and Time Warner in Kentucky circa 2008 was getting a shutoff notice dated the day after the payment due date with 14 days to comply. They did in-fact shut the power off at the state date.

This was a common occurrence that people referred to as 'brown billing' because the shutoff notice had a brown header instead of the green header on your regular utility bill.

Have the on prem team start deploying some assets that can utilized by the cloud team via a familiar interface like terraform. (metal as a service, kubevirt, Vsphere, nebula, whatever)

Start small, pick one service at a time (compute this quarter, postgres next quarter, secrets management the next) and use the emerging platform to strangle out paid services

Cloud team gets to stay cloudy, on prem team still gets to farm servers

'Might' is doing a lot of work here.

I've put together multiple hybrid and multi-cloud setups between gcp, aws, azure, equinix, and others using terraform.

Iam tends to be very different between providers but there is absolutely a lowest common denominator between them especially when you focus on compute, storage, and networking as primitives with which to host your own services.

You'll get quite far by consolodating requirements into a json file containing a list of ports to open, ip addresses to allow, required number of cores, disk space, operating system version, max spot bid price, default region, maximum desired replicas etc...

Another factor is how you provision your machines. Cloud-init radically simplifies the process of creating homogenous instances across providers versus custom packer images, ansible playbooks, puppet etc... and is supported by almost every cloud and exposed via their terraform provider

It's real, kubevirt is a kubenetes wrapper for QEMU which allows you to use kubernetes the manage the lifcycle of virtual machines the same way you manage a pod.

Metal3 is just a wrapper for Ironic from open-stack.

The two work together to re-image bare metal machines and attach them to clusters as nodes which can then be sliced up into smaller virtaul machine nodes to sell to your end user which they can then use to run docker, kubernets or whatever else they want.

Doing this allows you to have full kernel level isolation on a per-tenant basis which is not possible just using normal containers.

It also allows you to pin workloads to specific CPU cores for latency sensitive tasks as well as pass pci express devices through to individual VMs on the host and other fun things

It's really only useful if your problem is 'i have one really big computer but I want to have lots of small computers instead' but that's pretty much every data center so shrug

ClusterAPI (CAPI) enters the equation in that CAPI requires Virtual Machines or Bare Metal machines as inputs which it then uses to create a kubenrtes cluster. Thus, kubernetes in kubernetes with kernel level isolation on a per-tenant basis

Definitely neat and a huge flex but I think if you want to actually do multi-tenant kubernetes in kubernetes you should be using kubevirt or metal3 to bootstrap a VM and get a real kernel in there to isolate the cluster from its neighbors.

If you're struggling to get prometheus, nginx, postgres and other battle-tested tooling working in k8s, you're probably also not doing it well in docker-compose, on bare metal or anywhere else because it's the same darn software with the same damn options. No matter what you choose you're going to be creating system services to manage the life cycle of an application and exposing a port or ip address - there is no escape

Lmao, that's the worst of it? A guy had to brake sharply once? And people were polite to him afterwards? The utter tragedy.

I'll trade you streets and you can deal with the 3 dead kids from traffic incidents over the last 5 years

Depends on your requirements.

Vast is a grey-market with very few security measures in place. A host can snoop on your workloads very easily for example because they have full access to the docker host.

You're also limited in that you can only deploy a single container so if you just wanted some spot nodes to scale out your existing Dagster cluster etc.. You're not going to be able to cleanly plug Vast into your existing infrastructure deployment process.

But if you're just playing around or don't have major security/data restrictions and only want a jhub notebook or nvidia-glx-desktop then yeah it's a very hard deal to beat.

Just because the cloud exists doesn't mean you wrote your backend in such a way that it is fully disentangled from the rest of the application, nor that it was containerized and handed off to an orchestration engine which was properly configured to scale out horizontally across dynamically provisioned nodes.

The games industry specifically has a chip on its shoulder with regards to linux and scaling as well as a general refusal to NOT poorly reinvent every wheel in C++ inside their windows-only desktop client.

Otherwise you wouldn't see goofy shit like Square Enix halting sales of their game because they couldnt scale their snowflake out to general-purpose servers

Maybe do a better job on the AI so it correlates poverty to crime instead of skin color to crime, or is able to spot laws created specifically to target and oppress the poor. If the punishment is a fine, then it's legal for the rich