Red Hat to Acquire CoreOS(redhat.com)
redhat.com
Red Hat to Acquire CoreOS
https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership
202 comments
Probably rhel9. I have no professional insight into this but the historic timeline implies 8 will be out soon, I suspect they are just waiting for Wayland to get some where they feel comfortable with. Anything past Wayland is probably a 9 feature.
Atomic Host was introduced in RHEL7.2 if I remember correctly. There's a lot of room for introducing CoreOS technology before RHEL9, which would probably be 4-5 years from now.
(disclaimer: working at Red Hat, though not on anything related to containers).
(disclaimer: working at Red Hat, though not on anything related to containers).
CoreOS product manager here. Container Linux will live on, beside Fedora and CentOS as other Linux projects with maintainers from Red Hat. Keep Kube'n and Docker'n per usual.
More details here: https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
More details here: https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
Investing is probably putting it mildly. The top contributor is directly on their payroll...
This is a good move for CoreOS and Red Hat, I think.
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.
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.
I agree that this is a good move by Red Hat to position themselves with rkt and Quay ahead of Docker going to Microsoft (who will pay a premium to try to put this genie back into the bottle)
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.
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.
> this is a good move by Red Hat to position themselves with rkt
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 :-)
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 :-)
Frankly, I'm not sure why Google would acquire RedHat, SAP or Oracle.
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.
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.
> Frankly, I'm not sure why Google would acquire RedHat, SAP or Oracle.
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.
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.
> 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 do: they have a Cisco partnership for Google Cloud.
https://cloud.google.com/cisco/
They do: they have a Cisco partnership for Google Cloud.
https://cloud.google.com/cisco/
Cisco's reach beyond the network silo is very small.
SAP and Google do partner, exactly what you mentioned
https://news.sap.com/flexibility-scalability-speed-sap-googl...
https://news.sap.com/flexibility-scalability-speed-sap-googl...
My company uses SAP as an ERP. They’ve been trying to push HANA on us for ages, promoting their cloud service as a manner of lessening the sticker-shock.
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.
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.
What in the world are you talking about? Who is going to data mine?
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?
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?
Dead honest.
The data mining concept, it's just inconceivable to me. I wonder how your management drew that conclusion.
I guess the specter of google just draws out assumptions.
I guess the specter of google just draws out assumptions.
How could this be inconceivable to you? With all supplier and customer data codified into a standardised structured format, you’d instantly have a ”social network”of all the firms operating at various stages in a value chain, and probably the best model ever of how the whole economy is composed in detail. You’d get the bills of materials, ’recipes’ for just about anything anybody produces; you’d get their profit margins from the controlling modules, you’d be able to estimate the risk banks are exposed to by aggregating the loans they give out to companies and estimating the default risks of each and tot the up.
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.
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.
> They have no clue how to sell to enterprises, and because of that they are falling behind AWS and Microsoft in the cloud market.
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...
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...
> One could argue the same about AWS for a long 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.
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.
> 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.
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.
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.
> I have senior relationships with at least a few major international banks with aggregate budgets in the billions, and they are betting on GCP
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.
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.
There are a couple that are public (ie. conference talks and/or tweets) about their use I believe but likely aren’t references... only one I see on GCP’s website is a subsidiary of BNP Paribas. That said, take a look at Google Summit Toronto’s schedule, or a glance on YouTube for google cloud banking for another.
They are on-par on all the IaaS offerings. The Amazon has more products is an outdated meme, they have lots of renamed and minor products.
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.
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.
Red Hat cares a lot about getting rid of Docker. They're a major contributor to CRI-O [1], which is very similar to rkt.
[1]: http://cri-o.io/
[1]: http://cri-o.io/
I really think there should be an HBO Silicon Valley - Enterprise spinoff :-)
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 :)
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 sure rkt is well engineered (overall CoreOS has good open-source engineering). It just doesn't have much usage, and whatever advantages it has, evidently it wasn't enough to convince a meaningful number of Docker users to switch. I use Docker intensively and, like you, I've had my share of frustrating issues with it over the years. But at the end of the day, the bugs get fixed reasonably quickly, and Docker just gets the job done. Their code has so much mileage at this point, I just don't see the point in starting over with a competitor. Evidently I'm not the only one who feels that way.
I don't know. I wouldn't say my experience has been that the bugs get fixed reasonably quickly. It's more like they make several attempts to fix the bugs reasonably quickly and then eventually figure it out.
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.
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.
I think it’s because RedHat has thrown its weight behind CRI-O instead of rkt:
https://www.redhat.com/en/blog/introducing-cri-o-10
https://www.redhat.com/en/blog/introducing-cri-o-10
I think Google being able to buy Oracle is a bit of a stretch at this point. Oracle is 1/4 the market cap of Google. So, it seems unlikely they would have the capital available.
You are right. I was extrapolating future scenarios where Oracle or SAP trip up in their race to the Cloud, causing a major drop in their stock. Honestly it's a pretty realistic scenario, it's not a secret that the Dell, HPE, SAP and Oracles of the world have serious challenges ahead of them. One of them is bound to hit an attractive price, and for a bold and deep-pocketed suitor to act on it. The question is when?
And Who?
>rkt on the other hand is a dead project
Why is this? I've only recently started looking at it.
Why is this? I've only recently started looking at it.
> Red Hat does not give a damn about rkt. They care about Kubernetes, specifically establishing and consolidating a dominant position in upstream kubernetes development.
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.
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.
Google already partners with SAP to bring larger enterprise customers to their cloud.
Google should buy Oracle, fire all the employees[0] except Larry Ellison and have him mow their lawns.
[0] or reassign to better projects
[0] or reassign to better projects
>Given their self-inflicted XHR debacle that dethroned Office,
Do you mean how Google used XHR (ajax) for Google Docs to dethrone Microsoft Office? Or something else I'm missing?
Do you mean how Google used XHR (ajax) for Google Docs to dethrone Microsoft Office? Or something else I'm missing?
This sounds pretty logical ... the other big player is probably Oracle who will end up purchasing Pivotal, Rackspace, ...
Hadn't thought of it from this angle. Docker's only chance of survival is to have a cross platform container. Something that works on Windows and Linux.
Perhaps Docker's only play is to fold into Microsoft to achieve a cross platform solution. Microsoft does have Brendan Burns now.
Perhaps Docker's only play is to fold into Microsoft to achieve a cross platform solution. Microsoft does have Brendan Burns now.
Didn't Docker announce Windows support years ago?
My comment wasn't too clear. I'm not talking about just running docker cli on Windows or using windows 10 containers. Am yet to see a coherent story on how to write say a Java application containerize it, deploy it on Windows and Linux without having dealing with differences in each OS container solution.
If there is, I'd like to learn about it.
If there is, I'd like to learn about it.
From a financial viewpoint, CoreOs took in an investment of ~$50M [1] and sold for $250M. Assuming the $50M investment comprised 50% of the equity pool, a 2.5X return on investment isn't too bad.
[1]: https://www.crunchbase.com/organization/coreos
[1]: https://www.crunchbase.com/organization/coreos
That seems an unlikely assumption. $30M of series B in May 2016 would have been at around $200M valuation. Given the risks that is a disappointing return.
It's worse than that, their series B valuation was closer to $300M.
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.
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.
This is true. CoreOS was doing well and i am sure could grow on their own too.
Why did CoreOS go for this deal though? also, how could the investors agree?
Why did CoreOS go for this deal though? also, how could the investors agree?
They want for the deal because, in spite of doing well on the community side, they did not go as well on the business side. Enterprise Linux and Enterprise Kubernetes are very crowded and difficult markets. Being popular with startups is a big advantage in many ways, but it doesn't pay the bills.
This is important. A startup has to get beyond upstart.
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.
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.
Can you explain how you arrived this number? What sources and formula did you use? I'm no questioning it, I am generally curious. Thanks.
I got the number the same way journalists get any funding number: by talking to some of the many people involved in the deal. Funding terms are notoriously hard to keep secret in Silicon Valley, because everybody talks.
OK, so you didn't consult some resource online and see what the series B or whatever round was and use a formula based on what the raise was to derive the valuation?
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?
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?
There are definitely rules of thumb but there is a lot of margin of error. You can triangulate based on different variables.
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.
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.
your valuation is correct from what I remember being told by friends.
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.
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.
Given they later investors most likely have an exit preference I wouldn't say the risks were that big. What are the odds that CoreOS isn't worth $30M?
"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."
So long, Container Linux, we hardly knew ye... ?
So long, Container Linux, we hardly knew ye... ?
Is the interesting part of Container Linux open-source? Can anyone fork it and build a similar offering, simpler than RHEL?
What is the source? I didn't see that in the linked article.
From their FAQ: https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos
well it would be cool if some of their stuff would be 100% open source than. Like the CoreUpdate interface.
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).
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).
Red Hat typically opensources everything, which is one of the things I admire about them, so you should see repos going up sooner or later.
Disclosure: I work for Pivotal, we compete with Red Hat.
Disclosure: I work for Pivotal, we compete with Red Hat.
> the only pain point is storage
Good thing Red Hat has a couple of distributed-storage projects then.
Good thing Red Hat has a couple of distributed-storage projects then.
Not great news if you use container Linux:
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.
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.
Yeah, not great. That sounds like an EOL announcement.
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.
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.
Man have I really enjoyed CoreOS/Container Linux, etcd and generally all the work the CoreOS guys have done, and boy have I hated Red Hat's business practices. I moved away from Red Hat back when they split the OS into Enterprise and Fedora flavors.
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.
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.
Interesting, I totally disagree.
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.
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.
Companies that dont want to pay would simply use another free Linux, or maybe BSD. Centos keeps Red Hat relevant to those users and ensures they have an easy path to commercial Red Hat. It also makes sure accademics and students have an option to get familiar with it and provides a platform for developing skilled Red Hat aware talent. I'd be surprised if it costs them much more than 1% of sales, and as a free taster Im sure brings in much more.
Then there’s projects like OpenShift, we deployed OpenShift Origin on a cluster of CentOS Atomic VM, just over a year ago - at this point we are looking at buying dedicated hardware and OCP licenses from Red Hat now that we’ve used it in production for a while and need/want support when things go awry.
“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.
“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.
Recent example: they open sourced Ansible Tower. They must've lost quite a few sales, but even after only a few months community contributions started flowing in.[1]
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.
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.
Sounds like they are now going to support it as Open Source at least, even if RH is not interested in it:
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
Super disappointed in this part of it. Is anyone else aware/familiar with a decent immutable lightweight Linux distro like Container Linux?
If you're looking for immutability, I can recommend NixOS. However what is drawing me to container Linux is mainly its update process
The draw of CoreOS Linux for me is its curated pairing of the Linux kernel, Docker, and etcd. There was a commercial entity reviewing upstream changelogs and making sure that they were pairing components appropriately. I wonder if an non-commercial district can really get this right.
Take a look at Linuxkit by Docker: https://github.com/linuxkit/linuxkit . I didn't develop it, but I use it indirectly via Docker for Mac, which I use a lot. The latest version supports Kubernetes. This means Docker commercially maintains a Linux/Docker/Kubernetes stack that needs to run reliably on what I think is a very large install base. They have open-sourced the system they use for this, it's called Linuxkit and it's a very cool, underrated project.
+1 too :-)
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.
[1]: https://www.gnu.org/software/guix/
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.
[1]: https://www.gnu.org/software/guix/
GuixSD is just as disconnected from the Linux Standard Base as NixOS.
+1
We've also built https://github.com/vpsfreecz/vpsadminos recently which is based on not-os / NixOS
We've also built https://github.com/vpsfreecz/vpsadminos recently which is based on not-os / NixOS
RancherOS: http://rancher.com/rancher-os/
Rancher is awesome. As was CoreOS, and I am really pissed RH bought them out. RH manage to break everything they touch.
Fedora / CentOS Atomic, which is Redhat's "clone" of container linux.
Atomic (or at least OStree) predates ContainerLinux by quite a bit.
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.
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.
Sort of, but not quite. I'm familar :)
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.
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.
OStree's mailing list starts in April 2012.
I'm sure Colin did a bunch of work before then.
Oh OSTree was definitely around then, but it wasn’t building a competitor to ContainerLinux until rpm-ostree, which made it insanely powerful in that it could build images from existing (and pervasive) redhat package repos. I’m definitely not arguing that much whatsoever. Only that it wasn’t building a full distro in a way to put it on par with ContainerLinix until after ContainerLinux was a thing and CoreOS was a company.
Thanks for the info and I agree.
Also thank you for your work for Gnome. Awesome!
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.
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.
Heh, good on you for digging deeper. I think ultimately, the two were developed pretty much independently (Atomic and ContainerLinux), one from ChromeOS, and the other from Fedora / RHEL. They both prove the idea of a small container only os with atomic updates is a solid design to build a container orchestration system (k8s/openshift) ontop of. I'll still stand by the gist of my original comment though in that CoreOS was a thing before Atomic and they had a working P.O.C. before ostree was used to build an entire distro (such as atomic). Either way, we both learned something new so net win.
Common only in very high-level concept as the implementation details are vastly differing. NixOS is based on the Nix[1] purely functional package manager and configuration language while OSTree is termed to be "git for operating systems"[2].
[1]: https://nixos.org/nix/ [2]: https://ostree.readthedocs.io/
[1]: https://nixos.org/nix/ [2]: https://ostree.readthedocs.io/
Atomic doesn't predate CoreOS.
CoreOS = 2013 Atomic host = 2014
CoreOS = 2013 Atomic host = 2014
OSTree (the foundation for it) was built as part of GNOME Continuous in 2011.
Yup, what I sort of alluded to in my comment above re: GNOME OS, however I was saying CoreOS the distro predates rpm-ostree. Colin was talking about some of these ideas in Berlin circa 2011 at the desktop summit (isn't that where we met btw? I forget).
Absolutely.
But Atomic was architected as containers infrastructure and is/was a direct competitor to CoreOS and other lightweight container OSes.
But Atomic was architected as containers infrastructure and is/was a direct competitor to CoreOS and other lightweight container OSes.
It might appear that way to people that weren't involved in the history, but a lot of it was based on ideas learned from stateless linux, circa 2004.
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.
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.
There's Alpine Linux.
https://www.alpinelinux.org/
Intel's Clear Linux is yet another option.
Alpine for sure.
Which delivery mechanisms? The ContainerLinux boot image updater comes from Chrome and ChromeOS (Omaha). They must be talking about the higher-level partitioning of a cluster into groups with separate policies, etc.
Congratulations to the CoreOS team, by the way.
Congratulations to the CoreOS team, by the way.
tectonic, ignition, matchbox?
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.
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.
Atomic uses rpm-ostree, which looks similar to Omaha from a client perspective (update, roll back to previous version): http://www.projectatomic.io/docs/os-updates/
is there an alternative to locksmith? the "automatic" update (https://coreos.com/os/docs/latest/update-strategies.html) and/or https://github.com/coreos/container-linux-update-operator?
basically on coreos I don't need to run "rpm-ostree" to have an updated system. it is actually updated automatically.
basically on coreos I don't need to run "rpm-ostree" to have an updated system. it is actually updated automatically.
And importantly, you can control updates across a whole cluster by limiting how many machines are allowed to update simultaneously.
I just can't get a decent "This is how to get started" from windows guide with atomic. It's all assuming I'm perfectly happy on linux. Not to knock it, but I just want to start some VMs on hyper-v and have a go.
This is good feedback. I'll bring it to the Fedora docs team.
Container Optimised OS (Which is just ChromiumOS stripped down) has been working pretty nicely for me on GCloud. Just reboot and you have the latest updates. https://cloud.google.com/container-optimized-os/docs/concept...
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.
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.
Container Optimised OS also says they don't support use cases outside of GCloud, and it also relies on CoreOS' services itself.
So for bare metal use cases, I'm EOL?
So for bare metal use cases, I'm EOL?
well basically we use that on gcloud k8s in the future.
but we still have a bare metal cluster. we only used ignition + vmware to provision it in the first place and it was a breeze.. etcd was configured on the fly in a HA setup, k8s was made ready to bootstrap (just needed to run kubeadm init --config...) and we had basically a working cluster. highly available, with as many nodes we wanted, just copy the worker.yaml and edit what's needed.
we actually play around with tectonic at the moment.
we actually play around with tectonic at the moment.
I was thinking of locksmith. It's nice, as you say, to be able to have no more than N nodes per pool restart at any time, so that rolling updates are automatic and in the background. You can't replicate it easily without a cluster-wide etcd and ignition. I forgot about matchbox. There was also good old fleet, but that one is dead.
>"The ContainerLinux boot image updater comes from Chrome and ChromeOS (Omaha)."
Could you or anyone else recommend any literature on ContainerLinux boot image and its use of ChromeOS as a foundation?
Could you or anyone else recommend any literature on ContainerLinux boot image and its use of ChromeOS as a foundation?
Blog post from Red Hat: https://www.redhat.com/en/blog/coreos-bet
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)
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)
Red Hat acquired Ansible, now CoreOS. They seem to be really gunning for the DevOps marketplace.
+1: They're really in to it with their OpenShift offerings which are really good and open source too! I really admire them for that.
yep, I would suspect that too many at-scale ops are using either ubuntu/amazon/centos etc are eating at their market share capabilities... buying up these cements them in the devops toolbox a lot longer. Super smart.
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?
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?
> 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)
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)
Yeah thats what I meant -- but "trust but verify" -- how verify?
I didn't realize they acquired Ansible.
Congrats to Alex and his team! I've loved their technology since their alpha days. Glad to see it working out and hopefully getting into more hands with the acquisition.
Congratulations Alex & co for a great exit. I think the price is great considering that it is pretty much impossible to survive as an independent company in the infra space.
And they say there's no money in open source... ;-)
Anyone want to wager that MS buys Canonical?
Anyone want to wager that MS buys Canonical?
This is something I have long thought about. For a long time, I thought they might set their sights on SUSE as well, but they haven't. I dislike the idea of Microsoft acquiring a Linux company. Despite my primary current bread and butter being PowerShell and Windows Servers, I have, in a past life been a UNIX admin, and would prefer the two camps to remain divided. Microsoft embracing "open source" cuts both ways in my opinion. They may well indeed give back, promote GitHub and give away a few trinkets, but they are still the wolf they were under Ballmer, only now led by a much smarter, more saavy CEO.
Microsoft is constantly being chummy with Canonical. Coming to Canonical events — offering the WSL based on Ubuntu, etc. it makes total sense. It’s such a Microsoft thing to do: they could buy them and then offer them as a alternative to Windows and still make a ton of money. Or buy them an make WSL even better and shut everything else down. I really think it’s going to happen. And if they get flack from regulators they can just point to RedHat
They also befriend RedHat nowadays.They partner with them around MSSQL on OpenShift and RedHat offerings (RHEL, OpenShift) on Azure. They also invite RedHat to their events, let them have sessions and so on.
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.
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.
There is money where one can make a business selling support contracts, training or consulting to companies.
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.
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.
It's all about Openshift. Redhat developers have actively contributed to Kubernetes for about two years now.
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.
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.
> 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...
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...
This is great news! I am not sure what happens to tectonic? Is is going to be part of OpenShift?
As per the question in the FAQ about open sourcing CoreOS's technology, we can assume it's going to become open source, at least:
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.
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.
Thanks, I didn't see the FAQ link. Yea, let's see what happens with OpenShift.
Is this a good technical fit? Is this good for the tech community as a whole?
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.
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.
The only thing positive I can say is I MUCH rather have Redhat buy them than Oracle. I think Redhat has been a positive community member and well I will invoke the mom rule for Oracle.
Mom rule == "If you can't say anything nice, don't say anything at all"?
I suspect an announcement re: Docker's acquisition by a major tech player may follow closely on the heels of this news.
I don't think so. Docker Inc seems to want to take this as far as they can on their own, and I haven't seen anything to indicate a deviation from their stated and implied goal of becoming an entrenched brand of enterprise platform. I don't think they've done much in the way of positioning themselves to be bought, though I'm sure some of the bigger players would like to buy them. I'm interested in this kind of discussion, though, and would like to hear all about why I may not be right.
I think you're right. CoreOS never made the transition from technology and community leader to a sustainable enterprise business. I think Docker has made that transition. They are at a completely different stage than CoreOS and facing vastly different challenges.
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.
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.
I'm not sure their direct competition really is Red Hat or VMware to be honest. Their product is Containers-as-a-Service, which is becoming a table-stakes service in cloud: everyone offers k8s management at a starting price of "free".
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.
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.
Why is that? They seem to be at very different stages.
Amazon perhaps?
My bet would be Microsoft
Great to see their innovation recognized and hopefully it will become even more popular & widespread with RedHat's distribution muscle and enterprise customer relationships.
Congrats to the CoreOS team, although I’m a little bit sad to see this happen it’s a way better outcome than what happened with RethinkDB!
A quick D&B search on CoreOS, Inc. shows revenues of ~$550,000 [1], which means at $250m acquisition price, RH paid ~454X revenues..!
[1] http://www.hoovers.com/company-information/company-search.ht...
[1] http://www.hoovers.com/company-information/company-search.ht...
I have personally seen checks cut to CoreOS that were larger than the D&B number you quote. The set of similar corporate customers we'd run into was surprisingly vast and diverse. Redhat's made a brilliant move here.
I doubt CoreOS has any meaningful revenue (my guess is they are between $5M and $10M of recurring annual revenue). I also doubt they have a single customer that isn't either A. already a Red Hat customer, or B. too small to be interesting to them.
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.
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.
As someone who used CoreOS in a commercial setting, I think you are spot on. We wanted to pay them but we were never big enough to afford their commercial offerings. They wanted a lot of cash for their subscriptions and I think most would-be customers were looking for something less expensive--basically open source with support.
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.
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.
So are you predicting a CentOS/Red Hat split for existing CoreOS users, or do you think existing customers will migrate to something different?
Probably a mix. A lot of it depends on how they handle the sunsetting and migration.
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.
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.
The D&B numbers would be from the last fully reported year, i.e. 2016. They typically have pretty accurate data.
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.
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.
It seems like early 2018 is rife with acquisitions and mergers. Was the recent tax law a factor? Seems like these acquisitions take so much time that it couldn't have been dependent on that. So why all this activity?
Wages didn't really recover after 2008. The larger the company, the more flush with cash they've become. Nearly every major industry has been going through mergers. Dow Chemical and Dupont. Bayer and Monsanto. Disney and Fox. Charter and Time Warner.
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.
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.
M&A has been the strategy of just about all major companies for the last 18 months, and because of the lead time, I think 2018 is going to be even busier.
Huge changes in computing and technology, driven by the cloud in good part: big data, AI and machine learning, chatbots, and containers, microservices, etc. The major players all want a part of these so are acquiring innovators in each of these spaces.
It's a great time to be a developer!
It's a great time to be a developer!
New financial year, fresh budgets
Except Red Hat is financially now in Q4.
End of financial year... budgets to spend?
FTA:
> ... fourth fiscal quarter or fiscal year ending Feb. 28, 2018.
> ... fourth fiscal quarter or fiscal year ending Feb. 28, 2018.
Unlikely. Most of the acquiring companies, including Red Hat have fiscal years that don't end on Dec 31.
What i dont get is why Google ventures gave it ? Perhaps because CoreOS was based on chromeos and doesnt fit to fuschia OS and the new microkernel ? Anyways congrats to both RH & CoreOS. RH got passionate people in love with problem and CoreOS Core team monetised the value and innovation which they shared openly to the community. Thanks CoreOS team good luck !
Why was "Expanding its Kubernetes and Containers Leadership" removed from the title here when it is part of the original article title?
my two cents:
"Red Hat to Acquire CoreOS" is fact
"Expanding its Kubernetes and Containers Leadership" is hyperbole
Just some facts: Red Hat is #2 corporate committer (after Google and "independent") to Kubernetes[1]. With the acquisition of CoreOS Red Hat engineers now lead or co-lead 15 of the Kubernetes SIGs[2].
Disclaimer: I'm a Red Hatter
[1] http://stackalytics.com/?metric=commits&project_type=kuberne...
[2] https://twitter.com/openshift/status/958454802605846528
Disclaimer: I'm a Red Hatter
[1] http://stackalytics.com/?metric=commits&project_type=kuberne...
[2] https://twitter.com/openshift/status/958454802605846528
I started learning about containerization just this week. I didn't even know there were other popular alternatives to docker. So from what I gather, coreOS/rkt is an alternative to alpine/docker, with kubernetes instead of docker swarm as their primary orchestration solution?
Calling rkt a competitor to docker would be a stretch. Docker has undergone really vast improvements since its inception which is not really true for rkt.
no. there is no clear distinction like that with coreOS.
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.
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.
Happy for the team, sad for the product. I've always wondered how long they would survive for. I was actually afraid they would go out of business.
Since it has Red Hat in its name now i dont feel like using it anymore. Would use BusyBox or Ubuntu Core instead.
[deleted]
i wonder if it will mean that coreos becomes the official server-side fedora to rhel ... and replaces the community powered centos.
The RedHat press release states that RedHat won't maintain any distro aside of those they previously maintained, which many interpret as that all Core OS distros are now EOL.
This is painful and sad.
This is painful and sad.
The exact quote is “Red Hat Enterprise Linux’s content, the foundation of our application ecosystem will remain our only Linux offering”
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
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
That's a nice way to talk around the bush, but that doesn't solve the issue that, without warning or deprecation plan container linux will at some point just stop working.
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.
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.
This is the current official message:
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
We plan to revise and update this as soon as we have plans in place.
https://groups.google.com/forum/#!topic/coreos-user/GR4YlF2c...
We plan to revise and update this as soon as we have plans in place.
Okay, where does that tell me how updates wil continue until you have a plan? Will they just continue being maintained by CoreOS? Will they stop? What is happening now? If we'll have to manually migrate, how much time will we get before we have to? How much time will we get between you announcing a plan, and it being put into action? When can we expect a plan?
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.
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.
I don’t think anything has been decided yet about the fate of Container Linux. I do think there is a strong desire to find a path that doesn’t leave users like yourself high and dry. Hopefully more specifics will be coming soon.
[deleted]
So CoreOS's claim to fame is that it _only_ runs containers? How is that useful? You can run containers on any distribution.
Because it does the rest for you, magically.
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.
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.
Ah, I see. So it's basically integrated Puppet, but with first class support from the configured system
Yes, and this is fast. I can spin up a new server, have it configured, started, updated, and joined to my kubernetes cluster in 12 seconds (!).
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.
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.
Like the above user said.
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.
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.
Wondered when that would happen. ;)
[deleted]
This should be in the title, by the way: "for a purchase price of $250 million"
Why is everyone critiquing headlines?
The essence is that RedHat bought CoreOS. I didn't realize HN was a place people expected to see purchase prices in headlines.
The essence is that RedHat bought CoreOS. I didn't realize HN was a place people expected to see purchase prices in headlines.
I think a headline with the price tag would have simply been more useful. I had to spend 30 seconds to find it, and that's the main piece of information I wanted.
Out of curiosity, why "should" that be in the title? There's only so much one can fit in there and, personally, I think the price itself is just fine in the article/press release.
This story is inherently about a purchase and all that needs to be added is "for $250M".
sup polvi
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.