this post was submitted on 13 Jul 2021
9 points (100.0% liked)

Asklemmy

44824 readers
1002 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy ๐Ÿ”

If your post meets the following criteria, it's welcome here!

  1. Open-ended question
  2. Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
  3. Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
  4. Not ad nauseam inducing: please make sure it is a question that would be new to most members
  5. An actual topic of discussion

Looking for support?

Looking for a community?

~Icon~ ~by~ ~@Double_[email protected]~

founded 5 years ago
MODERATORS
top 6 comments
sorted by: hot top controversial new old
[โ€“] [email protected] 5 points 3 years ago (1 children)

KVM.

I don't like that is only set in Linux at all.

However, I like that allows me to emulate several computer architectures with not much resources in comparison with containers which cannot (no emulation) or other VM hypervisors (XEN).

[โ€“] [email protected] 2 points 3 years ago (1 children)

Depends on your needs. If you need to emulate several computer architectures absolutely go with KVM, but if you just need to run a bunch of services Docker/Kubernetes may be the best option.

[โ€“] [email protected] 2 points 3 years ago

If I use Libvirt I could just deploy applications in LXD.

[โ€“] [email protected] 2 points 3 years ago (1 children)

I like Kubernetes.

  • It encourages immutable infrastructure for apps by default. You update the pod to a new image rather than slowly mutating a VM with new versions.
  • It has a basic rollout system which will be sufficient for quite a while.
  • Its HTTP load balancing and routing is sufficient for most services, especially if you stick a CDN in front of it.
  • Its TCP+UDP load balancing is enough to get started with, and the APIs are there for bypassing it when you need to.
  • It makes it very easy to support failover between multiple VMs and cloud availability zones so that you don't have (significant) downtime for machine failures or node updates.
  • Lots of tooling built around it.

I think my main tip is don't get too caught up in the various tooling. If you are trying to be productive just pay GCP or another cloud and run with it. You can always migrate to another solution later when the costs are significant relative to the opportunity costs of your development time. The migration to things like self-hosted NGINX ingresses or self-hosted kubernetes are relatively small so focusing on your product at the beginning is the most important.

[โ€“] [email protected] 1 points 3 years ago

Cool, thanks.

[โ€“] [email protected] 2 points 3 years ago

Honestly for what I do in my work and daily life, the container technology I end up using most is a tarball and systemd-nspawn/machinectl. It does most of the stuff I need (configuring the network, binding paths in, setting limits, whatever) with less fuss than the more 'image' oriented ones.