SUSE to Acquire Rancher Labs(zdnet.com) |
SUSE to Acquire Rancher Labs(zdnet.com) |
I've come to quite enjoy Rancher products. I think the work they are doing is fantastic and lowering the bar for entry into Kubernetes, especially for on-prem/bare metal. Just deployed 4 production RKE clusters on bare metal and also using K3S.
It really transformed my company DevOps. I´m VERY happy. If you can, use Rancher. It is just perfect!
[1] Shamless plug Squawk: Walkie Talkie for Teams - https://www.squawk.to
_EDIT_ I've just read your blog post. We went the other direction and have used the local storage provisioner to create PVCs directly on host storage, and push the replication to the application layer. We run postgres and redis (keydb) with 3 replicas each with at least one in sync replication (where supported) and shipping postgres wal logs to S3 every 10 seconds.
At first look the numbers in the colourful table near the end, Piraeus/Linstor/DRBD seems 10x faster than Longhorn 0.8. The article goes into great depth of the (a)synchronous replication options of Piraeus, but doesn't mention that Longhorn always does synchronous replication. I wonder why?
SUSE being full into btrfs and CEPH, I wonder if they will allow Yasker https://github.com/longhorn/longhorn/graphs/contributors to continue developing. At Kubecon EU & US 2019 https://youtu.be/hvVnfZf9V6o?t=1659 Sheng Yang explains how he tried to make Longhorn first class citizen Kubernetes Storage.
Get a little bit of money (in comparision to all those shiny great things), build it, wing it and provide a huge benefit :)
Is that complexity needed or do more complex things actually tend to win in certain markets because nerds like knobs?
The collaboration between Service -> Deployment -> ReplicaSet -> Pod -> Container is a great example of how these reconcilers work together.
Yes, it has a lot of knobs and dials but you don't need to understand them to get going. Just pick up something like skaffold.dev and you can be productive very quickly
It only gets complex when you have to provision & manage your own clusters. That's where Rancher really shines, as it makes it so much simpler to deploy and manage K8s everywhere.
If the complexity seems too much, it’s probably a sign you don’t need k8s.
This might give SUSE more inroads to the North American market, considering it's largely a European player at this point.
For those like me, SUSE was sold off again in 2018 after like 5 acquisitions, and has been an "independent business unit" for a while now.
But we are mostly independent now. I.e we choose the directions.
Red Hat already bought CoreOS in January 2018, some 18 months before IBM bought Red Hat.
The question would have been more relevant to either of those.
Look at it from IBM's perspective - battling business units are good and one of them will certainly be the best.
But switch "inferior" to "superior" and your question makes sense. Red Hat's products mostly suck balls. I can't think of a single one which has been an enjoyable experience to use. People paid for them because they were the IBM of the Linux world.... And now they're the Linux of the IBM world.
"The companies announced the deal Wednesday but didn’t disclose the terms. Two people familiar with the deal said SUSE is paying $600 million to $700 million."
Source: https://www.cnbc.com/2020/07/08/suse-acquires-rancher-labs.h...
Disclosure: I work for SUSE
Disclosure: Rancher Labs CTO
Welcome!
K3s is something that I think could be a big impactful product in the kubernetes space.
Has anyone here adopted it over the long term? What made it stick?
Any ideas why SUSE would need/want this?
There was also CoreOS, which has since been bought by RedHat, and Deis, since bought by Microsoft.
So now it's been turned back into an OS war. RedHat, SuSE, and Microsoft.This is fitting because kubernetes feels like an operating system for container clusters. After all, operating systems are just resource managers and schedulers like kubernetes is.
(For those interested, there are several kubernetes distributions that are not company backed and open source. Two of my favorites are Kubespray[1] and Typhoon[2].)
1: https://github.com/kubernetes-sigs/kubespray 2: https://typhoon.psdn.io/
This appears the first significant acquisition of a k8s ecosystem start-up. (Remember the hadoop frenzy) The price might set a sentiment for the entire market segment for a while.
CoreOS dont have a kubernetes product either, right?
We had OBS, that is some kind of build system as a service that guarantee reproducible builds and traceability of packages before that was a thing. We develop an automatically and deeply tested (openQA) rolling distribution (Tumbleweed) at the same time that other was telling in the forums that this was simply impossible to do. We have crazy ideas like MicroOS with transactional updates, together with good old classics like YaST, Zypper or linuxrc.
We are just a few, but we have tons of contributions in the kernel, gcc, btrfs, qemu, runc, openstack, saltstack, kubernetes and whatnot.
I was thinking that AWS would acquire Rancher to make inroads into multi-cloud and hybrid kubernetes.
AWS has a case of not-invented-here syndrome that is so severe that it doesn't technically qualify as NIHS. For one thing, NIHS requires you to accept that there is such a place as "not here".
It's true that the guidelines call for original sources (https://news.ycombinator.com/newsguidelines.html) but we sometimes make an exception for corporate press releases, which tend to use obscure language, omit relevant information, and so on.
Rancher's RKE is the first installer I've come across that "just works". Run rke up against a cluster.yml and within minutes you have a HA cluster with ingress ready to rock. K3S is also looking quite good.
In contrast I've spent days staring down the abyss of vanilla K8s. If you have good alternatives for launching K8S on bare metal/on-prem clusters, would be game to try.
I saw Rancher's offering afterwards and it does look really slick .. the UI is bloody awesome. Wish I could get it for regular kubernetes.
I was talking to both of them about on-prem solutions, and found the Rancher support covered Ubuntu hosts, and Canonical support covered Rancher. Was trying to understand which support contract we would need.
But something happened between the companies and they parted ways. And neither party would comment.
In the end, we ditched Rancher support. The price almost doubled from one year to another and covered very little. I was also unimpressed by the technical chops of the Rancher solutions architect they gave us, which didn't seem to know anything beyond the basic documentation on their site.
But we are using Rancher 2 and Rancher 1.6 in production and have been happy with the solution itself.
We are migrating our on-prem from VMware to OpenStack and may stick with Rancher as k8s provisioner if charmed k8s doesn't live up to the sales pitch.
We are a team of 4 people doing on-prem datacenters on 10+ sites around the world, so we need a little bit of plug and play.
Momentum and credibility in Kubernetes land. Rancher has more of it. SUSE has a lot of experience in Kubernetes but hasn't gotten much credit for it or, I am guessing, many sales from it.
Disclosure: I work for VMware.
It’s a shame because I still feel there’s a gap between docker-compose and Kubernetes. I don’t have k8-size problems, but I do have well-beyond-docker-compose-size problems.
The enterprise K8S business is compelling, especially all the shops using metal/on-prem. I settled on using Rancher and RKE for production clusters just because it was the simplest way to get HA clusters up within minutes without a PhD in K8S.
But I think a lot of the work they are doing on the other parts of K8S are really interesting: K3S, for example, could become very popular for running on IoT and ARM. K3S really put a smile on my face. You just run it and boom, you have a K8S cluster.
https://www.suse.com/products/caas-platform/
(Source: I worked on the documentation for v3.)
The partly-SUSE-sponsored openSUSE Project also has a container-centric distro, Kubic MicroOS:
So it is already active in this area, and yes, I agree, there's a good chance that RancherOS will end up merging or even replacing this.
Redhat invested quite a bit into openshift, IBM bought them (and mentioned Redhat's cloud strategy in the announcement as one of the major reasons).
Microsoft is doubling down on Azure, now SUSE wants a piece of the pie.
I'm not familiar enough with Rancher to tell you why those chose exactly them, but they had to do something.
I wish my dog was as smart as yours, he continues to pay for windos and runs IE since no one on the internet knows he's a dog
Anecdotally, i feel like RHEL dominates the UK enterprise linux market as well as NA
nods head Yup, sounds about right.
SUSE is used pretty widely used in the European financial sector, right? That’s what I remember hearing the most about it.
EDIT: I’m referring to non-personal workloads, i.e. enterprise. Pretty much everything I’ve come across in a working environment has been Red Hat based, I’m not talking about personal local or VPS environments. Ubuntu and Debian do have a presence, but not at the Red Hat scale from my experience.
Mostly it is the size of the repo. openSUSE has everything. I guess that shouldn't be too surprising, the Build Service also builds packages for distributions not their own: https://build.opensuse.org
And of course there's really nothing as good as YaST for system configuration.
They also provide a full aarch64 OS for the Raspberry Pi, something which is surprisingly still quite rare.
I've been through a number of distros; SUSE as mentioned, Mandrake, Debian, Gentoo, Arch, Mint, KDE Neon, probably others that I've forgotten. I installed openSUSE Leap 15.2 on my laptop last week and immediately I felt right at home. KDE as the default desktop with no weird modifications nor excessive vendor branding, plus a well thought out default Btrfs partitioning scheme with good use of subvolumes (and CoW disabled on /var, nice detail) and snapshots for easy backups and rollback in case of botched upgrades or config changes.
The only minor gripe I have is their choice to ship Firefox ESR, but I understand why they do it, and it was easy to add the official repo for the latest release version.
I heard for example that Intel was/is a huge user and used it on their computing farm.
The engineering team inside SUSE are exceptional - they do amazing things, and build really interesting features. The product planning / joined up thinking / visionary direction is where they fall down. As a sibling pointed out they have worked on some really interesting stuff, but (when I was there in any case) failed to pull it together into something that could have been outstanding.
They are neither mediocre nor a behemoth. They have some excellent engineers. SUSE has worked on Ceph even before RedHat acquired Ceph. OBS and SUSE Studio had envisioned containers even before the market was ready. SUSE has some prime contributors for Linux kernel, GCC, Linux HA etc. Greg KH was a SUSE employee once, before moving to linux foundation. Technologically, they are far from mediocre.
In my personal experience, SUSE always felt that they had good engineers but somehow lacked the sense of making enterprise sales or generating postive news. The company being head-quartered in EU and not in California may also be a reason for the lack of the news. During my times, they were going through multiple rounds of acquisitions and nothing was stable in the vision of the company. The SUSE management did not feel like a Behemoth because they were trying to satisfy their investors in Novell, Microfocus, etc.
Disclaimer: I'm the Rancher Labs CTO
also performance is extremly dependant on so many factors which are not always given. i.e. drives, network, etc.
for some stuff even a distributed fs is enough, like glusterfs
I´m really rooting for Longhorn. I´m a sucker for GUIs. But in my tests the performance is not there yet.
However, they opened a new epic ticket to focus on performance, and hopefully they will keep improving Longhorn after the acquisition.
https://wiki.scn.sap.com/wiki/display/ATopics/Supported+Plat...
Heart, Mind and Soul of the Open Source community is possibly a bit of hyperbole.
and - SUSE is (slightly) older than RedHat, so I am not sure you can say RedHat inspired them :)
IBM was inspired by RedHat's earnings (pre acquisition, open source in IBM was .... interesting ... ) and their ability to have a relevant product in the cloud space.
I once tried to deploy a minimal test instance of OpenStack. Granted this was years ago, but I have been doing Linux since 1993 and I could not get it to run. That's an example of absolutely horrible UX at the deployability level.
K8S is nowhere near that bad but it definitely seems much harder than it needs to be to provision a basic default configuration for a working cluster.
K8S has a lot less moving parts - a couple of binaries / containers and etcd. The issue start coming up when you go beyond the single control plane node, and want a HA API.
Scientific Linux, which was built exclusively for HPC, was based on CentOS.
SUSE may be overlooked from a US perspective, which is why they get much less coverage than they deserve on sites like HN. They are huge in Europe and employ some exceptionally good people, and have been making probably the most solid distro out there since ~1994.
SLES is recommended for SAP installs, a huge enterprise market.
Sounds like something Red Hat could say too...
Suse's current owner won't have much synergies between Suse and their real estate business (except that Suse probably rents office space there) You don't do deals like "rent an apartment, get a Suse license for free" Thus Suse, under obersight can likely set their business strategy and objectives more freely.
Well maybe they should? That'd certainly sweeten the deal for me.
- on a side note - OpenStack and Kubernetes are not competitors, they are quite complementary collections of applications, that both have their place in a modern open source infrastructure.
The market is big enough for multiple large Linux distributions (Redhat, SUSE, and Debian^WUbuntu*). The market continues to grow as more things transition to computers.
But all of our APIs sit in one k8s cluster across two datacenters (Hetzner, with whom we couldn't be happier).
I'm particularly interested in what an HA Postgres setup might look like. Assuming you are running some kind of database (whether Postgres or otherwise), what are you doing for persistent storage? Are you using Hetzner's cloud block storage volumes? What is performance like?
The parent's point though is that this isn't the space IBM wants to be in. They're in the business of selling high margin, enterprise-y stuff that includes all the bells and whistles, so there's no reason for them to gobble up something like Rancher (RHAT's OpenShift solution is what they want to be selling already).
What standard tool doesn't work on OpenShift? It's certified to have 100% compatibility with Kubernetes, it just adds stuff, doesn't it?
We could definitely do two clusters and probably should, but the secondary data center has few services that it wasn’t really worth the extra work.
From what I see in https://github.com/openshift/origin/blob/master/test/extende... there are additional policies granted (search for "Disable container security").
I occasionally regret the defaults we picked because people get frustrated that random software off the internet doesn’t run.
That said, every severe (or almost every) container runtime vulnerability in the last five years has not applied to a default pod running on OpenShift, so there’s at least some comfort there.
To grant “run as uid 0” is a one line RBAC as assignment. To grant “run as uid 0 and access host” is a similar statement.
https://github.com/openshift/origin/blob/master/test/extende...