Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why and how we’re migrating many of our servers from Linux to the BSDs

it-notes.dragas.net

Post reply on HN
Print view View original

111–120 of 237 posts

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#111

Post by bigfatkitten »

jwildeboer wrote: post #61

"As an experiment, I decided to migrate two hosts (each with about 10 VMs) of a client — where I had full control—without telling them, over a weekend." And that's where I draw the line. Abusing the trust of your customers is an absolute no-no in my book.

How is it an abuse? As long as the customer continues to receive the service they paid for, who cares?

The major providers such as GCP, AWS etc share very few details about their underlying infrastructure with their customers. They change all sorts of things all the time.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#112

Post by dbolgheroni »

INTPenis wrote: post #76
DeathArrow wrote: post #59

All is fine and dandy and BSDs can solve many use cases. Unfortunately for the solution we are working on, which imply many microservices we need Kubernetes and no BSD equivalent to Kubernetes exists.

Can't you just run k8s on bsd? You might have to build and maintain your own release of it, but I'm sure someone has done it already.

No, FreeBSD has jails but k8s uses different types of runtimes for OCI containers (containerd, CRI-O, Docker Engine, etc).

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#113

Post by systems_glitch »

binkHN wrote: post #14

Glad to see all the major BSDs used here; I use OpenBSD whenever it makes sense.

Indeed, most of our public-facing services are hosted on OpenBSD, and all of our routers and firewalls run it. We started managing everything with Ansible to make it easier to ignore what the host OS is for a deployment, and that has worked well both in moving things to [Open,Net]BSD for experiments, and also standing up tests on various Linux distros just to make sure we're not running into a BSD vs. GNU issue, or even a "problem only on this specific distro" issue.

#1 reason we chose Ansible over other tools was support for the BSDs.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#114

Post by threeseed »

dspillett wrote: post #96
jbverschoor wrote: post #57

Earlier quoted context omitted.

Yeah I started around 4.something until 6 I believe. After that it was all Debian. My lesson was to just use what moet people use. But then again, I always used PostgreSQL even though most were on MySQL

> I always used PostgreSQL even though most were on MySQL That far back mysql and postgres were not even close to being a like-for-like comparison. One was a proper database, with things like referential integrity and a type system that didn't count the 31st of February to be a valid date, and the other was a glorified ndbm with some structure, a SQL interface, and was very very fast at running simple single-table SE…

Yet for most users none of that mattered.

Because they would just use a SQL library or ORM which hid all of these details.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#115

Post by threeseed »

kev009 wrote: post #83
DeathArrow wrote: post #59

All is fine and dandy and BSDs can solve many use cases. Unfortunately for the solution we are working on, which imply many microservices we need Kubernetes and no BSD equivalent to Kubernetes exists.

I've helped build two top 10 service provider networks (10s of Tbps). One on FreeBSD, and one on Linux with Kubernetes. I don't really see Kubernetes as being a game changer. The biggest pro, it makes it easier to onboard both development and operations personnel having a quasi-standard for how a lot of things like scheduling and application networking work. But it also seems to come with a magnitude of accidental an…

Kubernetes has unquestionably been a game changer.

If you look at most enterprises today you will see it deployed everywhere.

And most of the complexity has been abstracted away by the cloud providers so all you're left with is a system that can handle all manner of different applications and deployment scenarios in a consistent way.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#117

Post by threeseed »

hggigg wrote: post #98
kev009 wrote: post #83

Earlier quoted context omitted.

I've helped build two top 10 service provider networks (10s of Tbps). One on FreeBSD, and one on Linux with Kubernetes. I don't really see Kubernetes as being a game changer. The biggest pro, it makes it easier to onboard both development and operations personnel having a quasi-standard for how a lot of things like scheduling and application networking work. But it also seems to come with a magnitude of accidental an…

Agree with this on all points. We went from a virtualized server model to managed Kubernetes and costs have escalated considerably. The additional complexity and maintenance overheads of Kubernetes are not trivial and required additional staff hires just to keep things ticking. I think the cost so far from moving from two cages in separate datacentres running blades to AWS is approximately a 6x multiplier including s…

That's because you've moved to AWS which is an expensive cloud.

You could have easily run Kubernetes on your virtualised servers.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#118

Post by Neil44 »

jwildeboer wrote: post #61

"As an experiment, I decided to migrate two hosts (each with about 10 VMs) of a client — where I had full control—without telling them, over a weekend." And that's where I draw the line. Abusing the trust of your customers is an absolute no-no in my book.

Abusing trust is a bit strong, customers pay for a service and beyond a certain level of abstraction these obscure technical details (from their perspective) are not their concern. They're paying to have that abstracted.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#119

Post by aljarry »

jsiepkes wrote: post #38
shrubble wrote: post #33

Earlier quoted context omitted.

"One of the reasons Linux persists despite not having something up to the level of ZFS is that most of ZFS features are redundant to larger enterprise customers." ZFS is used heavily on Linux and runs well, though there are some limitations which are being addressed over time in the OpenZFS project. It is used across all areas that Linux serves, whether laptop, desktop, home server all the way to enterprise. https://…

ZFS on Linux is not really usable for most users because every kernel update can break your ZFS compatibility. Meaning unless you want to put in the time to manually test every kernel update and ensure your kernel version stays in-sync with OpenZFS you can very likely end up with an unbootable system.

Ubuntu supports ZFS, so if you can track Ubuntu's kernel, you get ZFS without risking unbootable system.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#120

Post by [deleted] »

_huayra_ wrote: post #13
lotharcable wrote: post #8

Earlier quoted context omitted.

It hard to know the timeline with his data loss, but I am assuming it was a long time ago. XFS is originally from SGI Irix and was designed to run on higher end hardware. SGI donated it to Linux in 1999 and it carried a lot of its assumptions over. For example on SGI boxes you had "hardware raid" with cache, which essentially is a sort of embedded computer with it's own memory. That cache had a battery backup so that…

Facebook runs their entire stack using Btrfs [0]. I would encourage anyone who is stuck in the "oh btrfs is so buggy and loses data" mindset (not helped by articles like this [1] that play off btrfs as some half-baked contraption, when it's really btrfs raid that needs a LOT more time to bake) to look into things and realize that large companies (OpenSuse, Redhat, Faceboook) have poured a lot of time to get it to wor…

[deleted]
Post reply on HN