Red Hat to Acquire CoreOS
redhat.com
redhat.com
Additionally, both companies seem like good places to work, with leadership that's often praised and has the results to show. I'm happy for CoreOS on this one, they're joining a company that I admire.
Looking forward to see how this will impact RHEL8.
(disclaimer: working at Red Hat, though not on anything related to containers).
More details here: https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
I've thought for a while that the platform market would shake out and be left with one and at most two winners. Previously we saw Deis fold into Microsoft and now CoreOS into Red Hat.
I expect that Docker will run independently for another few years before their investors realise it's time to push for an acquisition exit, but it's unclear by whom. I figure Heptio will go to one of Red Hat, Google or Microsoft.
As for CoreOS's technologies, my guess is that Red Hat will be gently herding Tectonic and Container Linux users to OpenShift and RHEL respectively. About the only products I expect to survive fully intact would be Quay and etcd.
Disclosure: I work for Pivotal, we compete with Red Hat and Docker. So read my remarks with whatever mix of skepticism and mirth you think is appropriate.
Given their self-inflicted XHR debacle that dethroned Office, I just don't see Microsoft passing up this opportunity.
Google, on the other hand, doesn't need Docker to plug any holes in their go to market unless it's a blocking play. However, Docker is already cozy with Microsoft, so I don't see a Google acquisition going anywhere.
Red Hat does not give a damn about rkt. They care about Kubernetes, specifically establishing and consolidating a dominant position in upstream kubernetes development. CoreOS helps them do that.
rkt on the other hand is a dead project and completely useless to Red Hat.
> Google, on the other hand, doesn't need Docker to plug any holes in their go to market unless it's a blocking play.
Google has a massive hole in their go to market. They have no clue how to sell to enterprises, and because of that they are falling behind AWS and Microsoft in the cloud market. However you're right that it would take much more than a Docker to plug that hole.
Honestly if I were Google I would try to buy Red Hat, or an even larger enterprise vendor like SAP or Oracle. Not only would they be buying the enterprise distribution they lack, but they would also secure a major customer for their own infrastructure and keep up with the economies of scale AMZN and MSFT are building up. But I don't know that they will develop the humility to admit that they need that - and even if they do there's no guarantee that the integration would work... Culturally they are worlds apart.
EDIT: another interesting acquisition target for Google Cloud would be Vmware. Diane Greene founded it, then got fired by EMC post-acquisition, something I am betting she still holds a grudge over. Now she runs Google Cloud. If I'm her, I like the idea of buying the place and savoring a triumphal Steve Jobs takeover moment. I don't know to what extent this is complicated by this week's announcement of a Vmware/Dell reverse merger. Maybe they buy the whole thing? But then would Michael Dell want to run this new mega-Cloud group? And how does that play with Diane's ambitions? This might bool down to whether Diane likes the idea of working for Michael Dell. He has vastly more go-to-market experience which is what matters most in their position.
I really think there should be an HBO Silicon Valley - Enterprise spinoff :-)
I'm not sure what will be gain from that. Google probably doesn't care about the softwares these companies provides as it has its own internal alternatives/derivative and Google is not really a software vendor, so it's a bit outside of their core business.
What would make more sense in my opinion would be for Google to have a partnership with a big Enterprise player (or several in fact) and promote it loudly.
Enterprise distribution. Without significant enterprise revenue, Google Cloud will never catch up to AWS and Azure. Nobody can beat Google on technology, but technology alone cannot solve this.
> I'm not sure what will be gain from that. Google probably doesn't care about the softwares these companies provides as it has its own internal alternatives/derivative and Google is not really a software vendor, so it's a bit outside of their core business.
Google Cloud absolutely is a software vendor. They sell cloud services which compete directly with traditional enterprise software. Their services are superior in many ways, but enterprise adoption is definitely not one of them. That is the problem they could solve by buying an enterprise-savvy competitor.
As a bonus, these traditional software vendors are all racing to deploy cloud versions of their software. Because they have massive install bases, they can drive enterprise workloads to the cloud of their choice.
What would make more sense in my opinion would be for Google to have a partnership with a big Enterprise player (or several in fact) and promote it loudly.
They are already partnering aggressively, just like their competitors. I think they announced exactly this with SAP recently.
But partnerships have their limits. Most vendors will not allow themselves to grow too dependent on their main competitors. If they did, they would lose all leverage in the deal, and slowly starve as Big Cloud grabs all the margins. And then we're back to the acquisition scenario.
They do: they have a Cisco partnership for Google Cloud.
https://news.sap.com/flexibility-scalability-speed-sap-googl...
When news came through of Google and SAP ‘partnering’, upper management saw the writing on the way and went into full money-is-no-object mode and mandated the firm have a plan to switch away from SAP to alternative solutions (that I am not at liberty to discuss) within twelve months, with and that this plan must involve switching over within no more than ninety days including integration tests. Much preliminary work and change requests have been formulated and even implemented not even knowing if they will ever be needed (i.e. if data-sharing policies change and/or an actual acquisition becomes a real prospect).
Why? The reason is simple: the last thing a company that values its IT and operational profiles wants is to find itself in a situation where it can be data-mined by a publicity-driven juggernaut such as Google. Any expense is suitable to head off that threat.
No major corporation would be willing to shoulder this risk. It's the stuff upper-management's nightmare are made of. And decision-makers in positions of power within SAP and to a lesser extent Google are well aware of this. They won't precipitate a nuclear war with their own clients.
Google is not going to access corporate cloud customer data no more than IBM, Amazon or Microsoft.
Plus Google already has the data if they want as the executives at all these companies use Google search and other services.
Google could inow what decision makers search in before a sales call but obviously are not going to be doing that.
Is your post suppose to be serious?
I guess the specter of google just draws out assumptions.
Forget knowing what executives google... you’d have a real-time fingerprint of the whole economy, ready to be explored and monetized.
This would be... terrifying. Imagine if google discovered that (oh, I don’t know) some firm supplying parts into the Pixel product line had high margins on one of those items, and decided to play hardball to push it down. Suppose Google discovered that one small firm competing with it depend ended on another customer for most of its current revenue, and Google decided to focus its ’competition’ on changing that key client’s idea?
It would be a nightmare.
One could argue the same about AWS for a long time. They’re still lumpy depending on the region. Google has gotten way better in this regard, and are hiring like mad. I wouldn’t presume the above is true any longer.
Microsoft on the other hand can sell, but Azure is flaky.
Google’s main limitation is they don’t have the breadth of offerings of AWS or Azure. That will change with time...
Yes, and it took them years to get it right. Which means Google is years behind, and doesn't have the benefit of a forgiving early market.
> Google has gotten way better in this regard, and are hiring like mad. I wouldn’t presume the above is true any longer.
Let's hope so for their sake. Personally I'll believe it when I see it. You can hire all the sales reps you want... If your top leadership doesn't understand or respect enterprise buyers, or know how to scale the entreprise distribution "machine", then it won't matter.
I've spoken to several enterprise IT buyers - commanding billions of dollars in aggregate budget - comparing the benefits of AWS and Azure. When I asked them "what about Google Cloud", the room burst out laughing. This happened several times.
Diane Greene knows the enterprise... she has hired an experienced team on the product, sales, and marketing side.
> I've spoken to several enterprise IT buyers - commanding billions of dollars in aggregate budget - comparing the benefits of AWS and Azure. When I asked them "what about Google Cloud", the room burst out laughing. This happened several times.
I too can play the anecdote game - I have senior relationships with at least a few major international banks with aggregate budgets in the billions, and they are betting on GCP. I also know a very large bank betting on AWS, and a couple are straddling the fence with multi-cloud between their on-prem, Azure, and GCP. I see Azure commitments in a big way in insurance.
Of course, it depends what you're trying to do as to which cloud is the better fit. We saved a pile of money moving our AWS workloads to GCP and got better performance for it. I think laughing at Google is a mistake, but clearly they have work to do.
If several banks are in fact betting on GCP as a primary provider, that would be encouraging news. I will believe it when I see it! Do you expect any of them to be referenceable anytime soon?
By the way: I myself think GCP is great, and I use it for various non-enterprise projects.
It looks like we agree that they have a lot of work to do.
Big companies might not adopt Google Cloud for a variety of reasons. Small and medium companies should have a look, it can be easier to manage and much cheaper.
[1]: http://cri-o.io/
Interesting thought, although these merger/acquisitions play out over quarters and years. Not really conducive to a 12 episode season every year. And seems Silicon Valley has already had a touch of this type of narrative :)
rkt on the other hand is a dead project and completely
useless to Red Hat.
And just anecdotally docker hasn't been the greatest experience for me running in production. So much so that I've considered exploring rkt as a replacement. I would not at all be surprised if RedHat was hedging their bets re: docker with this coreos acquisition.
I'm not sure their code has enough mileage to paper over their quality issues. At this point the only reason I'm not switching over is that I've written enough shims and code to paper over dockers problems that I have it somewhat stable and the switch cost is just barely high enough to make sticking with it the right choice for now. But it won't take too many more problems to make me reevaluate that decision.
Why is this? I've only recently started looking at it.
Yep. Even technical people are used to referring to Linux container tech as 'Docker' so when you ask them what technology they use, they'll mention Kubernetes.
[0] or reassign to better projects
Do you mean how Google used XHR (ajax) for Google Docs to dethrone Microsoft Office? Or something else I'm missing?
Perhaps Docker's only play is to fold into Microsoft to achieve a cross platform solution. Microsoft does have Brendan Burns now.
If there is, I'd like to learn about it.
Great for the founders, hopefully great for the team, solid for early investors. Disappointing for latest investors, but shit happens - and the best investors understand the long-term value of graciously allowing the founders to follow their heart, even at the cost of a short-term disappointment.
Why did CoreOS go for this deal though? also, how could the investors agree?
Despite being a ‘buyer’ it was virtually impossible to get traditional enterprise risk management processes to bet the farm on an upstart OS + platform.
Now a vendor that enterprise starts to trust can offer this and everyone wins. It’s just what the doctor ordered for the K8s roadmap at RedHat.
I see people throw these "valuation based on the last round" and I'm always interested at how they arrive at these numbers. Is there no rule of thumb then?
One variable is how much VC firms at a given stage typically need to own (below a certain ownership in the company, even a fantastic outcome will not cover the cost of the many failed investments that are characteristic of high-risk ventures). So that puts an upper bound on reasonable valuation for a given investment amount.
Then there is a similar variable for team dilution. Founders will only give away so much of their company before losing the feeling of ownership that is a big part of the motivation of entrepreneurs. So that puts a lower bound on reasonable valuation.
Then there is the trajectory of the company. How far are they from being IPO-ready? How many more rounds to get there? And if they don't get there, what are realistic acquisition prospects? If any similar company has been sold, what was the price?
None of this is an exact science. Sometimes people do unreasonable things, because they don't have a choice, or because they don't know any better. And many well-informed analysts also have biases or conflicts which twist their estimates.
Since you mention online resources - in my experience almost everything you read in professional ad-supported publications is biased, wrong, or blatantly one-sided.
It's a reasonable return for early employees, but way under $10 a share as they had over 26 mil shares before series b. Assuming 20% dilution in series b, and no other dilution, looking at closer to $7.5 a share in total. Then you get into the VC liquidation preference which would lower value of the employee shares further. Of course if your strike price is 50 cents a share, you still made money, just not what you might have hoped for.
So long, Container Linux, we hardly knew ye... ?
But well CoreOS is already extremly extremly simple for running k8s and stuff.
We've used CoreOS basically from the beginning. We are small and so had a fleet cluster with 3 nodes. It worked, kinda but due to docker it wasn't a nice experience. Docker just had a too fast changing cycle and to much things didn't worked as we liked.
However now we run more and more internal stuff on k8s self hosted cluster and it's basically a breeze. we use ignition to bootstrap the nodes and then we just need to run kubeadm join on every node. everything else is self configuring.
bootstrapping k8s was basically just 3x kubeadm init. with calico we can even bgp route every pod and can access them.
the only pain point is storage, but this is not a problem of coreos. small scale high available disks would be cool, but this is not an easy problem. we have nfs but it is not on k8s and minio is only good for object storage (and needs 4 nodes, while I would prefer a solution that uses either etcd or k8s configmap as a backing store for HA).
Edit: I completly forgotten. Thanks for all what you guys did and I hope you will be good under the RedHat umbrella.
(P.S.: if tectonic would be free to use for all sizes, that would be even more amazing, but I'm probably dreaming).
Disclosure: I work for Pivotal, we compete with Red Hat.
Good thing Red Hat has a couple of distributed-storage projects then.
https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos
Container Linux and its investment in container-optimized Linux and automated “over the air” software updates are complementary to Red Hat Enterprise Linux, Red Hat Enterprise Linux Atomic Host and Red Hat’s integrated container runtime and platform management capabilities. Red Hat Enterprise Linux’s content, the foundation of our application ecosystem will remain our only Linux offering. Whereas, some of the delivery mechanisms pioneered by Container Linux will be reviewed by a joint integration team and reconciled with Atomic.
EDIT: Thanks for everything CoreOS team, and congrats on the sale! This immutable distribution was a breath of fresh air in a crowded "enterprise / kitchen sink" space.
I was a big fan of Red Hat back when they were leading the way in the early days of linux with things like application packaging, and a general vision towards simplicity. This is the same thing that attracted me to CoreOS' elegant engineering. I don't object to companies focusing more on revenue, as Red Hat's Enterprise move clearly was. But I cannot abide the erosion of vision in pursuit of profits. In particular when elegance and simplicity are replaced with complexity, and user hostile design to increase switching costs.
I realize there is probably a natural selection process at work here, and user hostile design is clearly a more profitable strategy, but I can't keep from hoping that one of these times the well engineered, simplicity focused, user centric design will find the right business model and survive... vision intact.
The split of Fedora and RHEL was a great move for users IMHO. Serving the needs of desktop users and enterprise (servers) with the same distro just isn't doable. They have wildly different and incompatible needs. I've been a happy fedora user for years.
Red Hat has also done tons of things that directly fly in the face of a company seeking profits. Like continuing to release your full source code, even when punks like Oracle just rip it off and sell it for less. They even directly support the CentOS project, even tho it cannabalizes people who might otherwise buy RHEL.
Red Hat is an amazing company that has poured countless millions of dollars in both money and time to make all of our lives better. Even the Gnome project may not be a thing without Red Hat's contributions, and everybody on linux benefits from that work. I wish there were more companies out there like Red Hat.
Disclaimer: I have zero affiliation with Red Hat. I'm just an appreciative observer and beneficiary.
“Free taster” is certainly an apt anaology, I know there’s plenty of people who will never buy the supported products but there are likely a lot of other organizations like us that decide to buy in AFTER trying the upstream projects first.
Red Hat really believes in the power of open source. It must be a great place to work at.
[1]: https://github.com/ansible/awx I wish more companies had that kind of courage.
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
I'm using NixOS happily since 2014 after getting messed up in pacman dependencies on Arch and haven't looked back. But their too radical shift from LSB makes for a less attractive enterprise story. Hopefully GuixSD[1] can plug that hole due to the GNU brand as it has been progressing nicely.
We've also built https://github.com/vpsfreecz/vpsadminos recently which is based on not-os / NixOS
Also Atomic is more than just an OS; it's a system of reliable upgrades / versions switching. So it's got something in common with NixOS.
I used to be a gnome foundation member (I trained Andrea Veri on the sysadmin team who trained Patrick Uiterwijk, the current lead sysadmin for GNOME) when Colin Watson wrote OSTree. He was talking about it and some of the ideas from it at the KDE/GNOME desktop summit in Berlin (2011ish) in some of the comments after https://desktopsummit.org/program/sessions/improving-how-we-...
At the following Boston (GNOME) developer summit one of the big conversational points sans Ubuntu pulling away from GNOME to build Unity was the idea of GNOME OS because Linux was hard then. He built rpm-ostree after that, and it was after CoreOS as a distro was a thing.
rpm-ostree's first commit was Dec 21, 2013: https://github.com/projectatomic/rpm-ostree/commit/958dfa435...
https://coreos.com/blog/coreos-fourth-birthday CoreOS as a company was created on July 13th, 2013.
TL;DNR: It's complicated, but Atomic as a distro most definitely does not predate ContainerLinux as rpm-ostree didn't exist when CoreOS the company was founded.
Forgive me for poking around a little more but I like reading computer history. That rpm-ostree first commit was an import from something called pkgsys-ostree. The first commit in pkgsys-ostree was only a little earlier; Aug 2013.
[1]: https://nixos.org/nix/ [2]: https://ostree.readthedocs.io/
CoreOS = 2013 Atomic host = 2014
But Atomic was architected as containers infrastructure and is/was a direct competitor to CoreOS and other lightweight container OSes.
People in the desktop team had been working on read-only root OS's for a long time, and it was only at a certain point that RH management bought off on forming a product/spin. But to say that work only started once Atomic was a thing would be inaccurate.
It's probably fair to say that ChromeOS/CoreOS lit a match under some upper management though.
Congratulations to the CoreOS team, by the way.
Also CoreUpdate is based on Chrome and ChromeOS but it's the only os that integrated it nicely. Running CoreOS is way simpler to manage than most other distro's because of that fact.
basically on coreos I don't need to run "rpm-ostree" to have an updated system. it is actually updated automatically.
It's also open source
But yeh, Matchbox + Ignition for automatically bringing up configured nodes with iPXE was an extremely powerful combination. However, those ideas can be easily ported over or already exist through cloud-init.
So for bare metal use cases, I'm EOL?
we actually play around with tectonic at the moment.
Could you or anyone else recommend any literature on ContainerLinux boot image and its use of ChromeOS as a foundation?
Red Hat FAQ: https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos
CoreOS Blog post: https://coreos.com/blog/coreos-agrees-to-join-red-hat/
(Added FAQ and CoreOS links)
However, I would love to see how they have evolved their openstack offering and their integration with intel's secure compute since the last time I worked on that project... I havent really looked - but I wonder if at all the meltdown/spectre issue affected them at all.
is there any at all risk from a security standpoint where redhat owns the tooling for many devops customers?
They open source a lot of their tools, so I don't really think there's any lock-in (I assume that is what you meant by "insecurity" in them owning the tools, and not traditional computer security)
Anyone want to wager that MS buys Canonical?
I don't think that the warming relationships means anything in the way of acquisition, what do Microsoft have to gain from such a deal? I think they are far better to work with them as partners.
Or bundle hardware with source code for the software side.
Now for open source desktop software targeted at regular consumers, that is a total different story.
Now they'll own the entire stack and have a great integration story for enterprises. Even though containers have been around 3+ year's in the form of docker, corporations still don't have a scooby on how to integrate their existing deployment and development workflows.
I second this. If its a legacy stack, enterprises struggle to fully containerize their apps and commit to deploying with a container orchestration layer like OpenShift or Kubernetes. IMHO, we need more enterprises to get over this barrier, than view it as a passion project by over eager devops' teams...
https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos
It will probably continue to be available in some paid commercial offering with well defined releases and lifecycles, as well as a community-supported free-in-both-senses offering which moves faster. Red Hat repeatedly uses this model across their portfolio.
Can't answer the OpenShift question - I have no inside info from either company. But open sourcing it is the bigger impact.
I am a bit disheartened to see discussions often going in the direction of big corporation politics / power play, rather than how it benefits the community.
For Docker the question is: can they carve out enough of the enterprise IT budget to reach IPO-level revenue growth before either A) their direct competition (Red Hat and Vmware) catches up to them, or B) Big Cloud commoditizes the entire container platform space, eventually nuking the growth of Docker, Red Hat and Vmware alike.
Docker is in a kind of weird place in the market where they're selling as-a-service for on-premise. Puts them in the same place as OpenStack and CloudFoundry for me - the former is already squished; jury's out on the second (IMHO). I don't see their current strategy succeeding, personally.
[1] http://www.hoovers.com/company-information/company-search.ht...
For $250M Red Hat bought outstanding technology, a strong R&D team with community street cred, and upstream influence in Kubernetes. They know how to monetize these things. They definitely did not buy revenue or customers. In fact they got a great price precisely because CoreOS failed to monetize these things sustainably, and needed a way out. It's a great outcome for the team, and a great match for Red Hat.
Redhat offers an existing and proven enterprise customer base that will cut the big checks. Redhat customers are the customers that CoreOS always wanted but likely struggled to acquire.
Assuming the industry norm, which is a botched sunsetting and incomplete migration, the majority of free CoreOS users would go looking elsewhere. And they would probably scatter to the wind rather than flock to a single winner, since the OS space is quite crowded and fragmented.
My point was not to imply this is a bad deal for any of the involved parties, but simply to add a data point to the discussion, one which other entrepreneurs looking for areas to add value should find highly interesting.
Given the fact that Trump and the GoP are in control right now, the FTC's position is weaker than it's ever been. We'll need anti-trust legislators in 10 to 15 years or disparity in the US will be at an all-time high.
It's a great time to be a developer!
> ... fourth fiscal quarter or fiscal year ending Feb. 28, 2018.
Disclaimer: I'm a Red Hatter
[1] http://stackalytics.com/?metric=commits&project_type=kuberne...
Its just one of the distributions that try to be a ... docker hypervisor for lack of a better term.
It tries to be a tiny distribution for the sole purpose of letting you use a docker daemon.
a direct competitor would be RancherOS
/edit: furthermore, the kubernetes docker daemon is (afaik) a fork from the original docker and predates docker swarm by a long time. It was the only way to really scale with docker back then. Docker Swarm seems to be a viable alternative at this point, however. And honestly, its way easier to use from my experience.
This is painful and sad.
The key point is “content”, which means the packages and kernel. Atomic itself is only based on RHEL content at the same schedule as RHEL (rpm-ostree and some of the tooling is the difference). So it’s not quite about Container Linux the concept being dead, just that Red Hat isn’t going to create a new packaging stream (Ubuntu, Debian, Fedora, RHEL, SUSE are all independent streams) because then Red Hat would have to duplicate all that work.
I can’t speak to what the plans will be, but the FAQ is not saying Container Linux is dead.
Disclaimer: Red Hat employee
There's no timeline or FAQ telling us how we can keep our container linux deployments, with the same software, with the same configs, working for the next years.
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
We plan to revise and update this as soon as we have plans in place.
We've got no info, and are supposed to run production systems with that.
This is a corporate acquisition, these things don't happen randomly. Why was there no plan made ahead of time? I'm disappointed and confused.
You mount a config file into the system, but CoreOS on it (or boot per PXE), and coreOS does the entire rest for you. You never have to install or reinstall, never have to deal with updates. If you put that config file on any system with coreOS, it'll be exactly like yours.
This means I can create a config to tell a server to join a kubernetes cluster, and then whenever I create a new server I simply mount the config in, and am done. I never have to set up or configure servers. Everything is handled automatically. No more fighting with Ubuntu wiping all repos 10 minutes (!) after a version is replaced by the successor, never dealing with misconfiguration.
It's truly amazing, and I loved using it. Going back to normal distros is painful.
And it automatically handles updates across the cluster - only a certain amount of servers restarts at a time, allowing you to stay constantly up while handling updates automatically, and potentially scaling out in seconds.
It's sad RedHat EOL'd it immediately.
“Red Hat Enterprise Linux’s content, the foundation of our application ecosystem will remain our only Linux offering”
TL;DR: container linux, as we know it today, is dead.
No package management or bloated softwares distributed.
It's immutable infrastructure. You configure your host once during provisioning, then it can accept container workloads in your cluster.
The essence is that RedHat bought CoreOS. I didn't realize HN was a place people expected to see purchase prices in headlines.