Can someone explain why Red Hat is so valuable? Why would IBM put such a big bet?
(Whether that justifies the valuation I don't know enough to guess on.)
And if they can sell some of them RHEL on POWER9 they will be very happy to take that money as well :)
Given the market is moving, even IBM's major customers would eventually migrate to newer technologies. (On the order of decades)
By providing something that mostly satisfies that need, IBM essentially drilled a relief well to take the pressure off. When they're ready to migrate, they could get 80% value of what a non-IBM migration would get them by moving to IBM's product.
For a lot of large, slow, conservative orgs, that's good enough.
Yes, but that’s only a coincidence. What they have really been doing is transitioning from proprietary to commodity hardware. Which IBM no longer makes. Where does IBM make money? Mainframe sales. There can be only one winner here... IBM will need to kill off their mainframe business to justify this purchase, something they have proved very reluctant to do.
IBM’s mainframe margins are safe for decades to come.
But realistically mainframes are a small part of IBMs business so there are lots of reasons for IBM to buy Red Hat that are entirely unrelated to mainframes or POWER hardware
IBM is mainly a consultancy business, so they basically back integrated with the cloud os - kubernetes, or more specifically in this case - open shift.
The only issue here is that are around 23 or more certified kubernetes distors, so this might have been an expansive price to pay.
If anything I am skeptical about Kubernetes' future. Not in the short term, k8s/docker are the MongoDB of the late 2010s and the same sorts of people are jumping on the bandwagon. But look at the discussion about the AMD EPYCs in Google Cloud. Big machines are now getting so big that a bog standard OS running a bunch of processes is going to provide more than enough power for even very large websites.
One machine now provides more power than a whole rack used to, and horizontal scaling technologies are expensive. A research paper from 2013 showed that just scaling up beat the performance of scaling up for virtually all jobs analysed, which came from Microsoft, Yahoo, and Facebook. So the sorts of companies that are poster-children for this kind of cloud technology.
https://www.researchgate.net/publication/261862149_Scale-up_...
There's not much career or intellectual capital to be gained by just running things on big boxes, but, eventually the cost effectiveness of this will become hard to ignore.
A cloud native system is a system that manage its resources via an API. The vendor locking in this case is the cloud API. I.e. if I want a resource (e.g. a VM) , I need to use the EC2 api.
With kubernetes, I write to the kuberentes API which is open source, cloud vendor natural.
However, and this the key to my comments - kubernetes is the platform of platforms. It is an API platform and not just an API.
In the future (some would say near future), all of the cloud services will be offered as kubernetes APIs (via a set of domain specific CRD). I am currently working on the AI platform.
As for the big machines comments. I absolutely agree. However, I would like to ignore the actual hardware (banning some sort of HA that would require at least 2 machines).
If (big if) some standardized variant of kubernetes "wins."
K8s was transparently Google's strategic shot at forcibly commodifying AWS.
But everyone has their own agenda. Google, Microsoft, and (to a lesser extent) Amazon could survive in a world of fully commodified compute. Give their compute assets are essentially surpluses from running their other businesses (advertising, software sales, and online retail).
So none of them have a strategic imperative to derail k8 evolution.
But managed, specialized cloud services are lucrative to all of them (especially Amazon). So their best-case isn't a fully commodified future.
This is mythology. It is mostly not actually true.
I doubt very much the first deployment of Gmail looked anything like its footprint today.
More regions doesn't necessarily stem solely from customer demand.
I expect the vast majority does, but without numbers, that's just a guess.
An AI service is much more than submitting a CSV file to a cloud and getting a model back, or even a web end point.
You need:
1) watch for changes in the input data.
2) watch for model decay.
3) watch for latency.
4) retrain (preferably automatically).
5) redesign your pipeline and imputation methods when the data changes.
6) watch for problems in the input data during serving
7) Scale out or Scale down.
8) Be optimal with the training resources (for example, train on spot instances).
9) Canary and shadow release of model
10) Data and model versioning.
Not to mention privacy and price.
What happen today is that there are no offering of alternative to the cloud services, so there is no point of reference.
Let's stipulate that most analytic applications can run on single servers. You still need a way to schedule work efficiently when the applications in aggregate require more than a single host. Kubernetes does that very well.
That's leaving out considerations like HA. The paper is notably silent on this topic. To keep systems up across failures as well as maintenance you need replicas in different locations. There's an implication in the paper that everyone is just going to run off S3, which is assumed to be globally available. Not everyone makes that choice for a variety of reasons. So we will continue to see shared nothing designs that require placement across hosts, racks, AZs, etc. Kubernetes is efficient at deploying these.
Kubernetes doesnt solve the vendor lock in issue completely. You still need workers, external dns, databases, gateways and other to operate.
The strength of Kubernetes comes in development speed. And thats pretty much it. You can push something out pretty fast and scale it. Ah, this and the fact its easier to find newbs familiar with k8s (they often have no idea how to deal with bare-metal).
I wouldnt say the amount of operational work vs normal cloud management is simplified. Managing kubernetes cluster is painful, Ive witnessed 3 updates of EKS where each one broke some part of the cluster: dns / autoscaling / monitoring etc.
But hey it is fast. Building runtime image with immutable layers is a huge adventage in itself.
Also see https://github.com/kubernetes-incubator/external-dns.
The better question is, why did it cost so much? First of all, Red Hat makes a lot of money and it has a solid market position.
Secondly, you tend to overpay in an acquisition, because it is a huge amount of sudden demand.
Lastly, pretty much all stock is "overvalued" right now, because money is cheap (see my other comment).
> Why would IBM put such a big bet?
Because it is a giant corporate monstrosity that cannot really innovate by itself anymore. It still can buy things though.
Seems like IBM is hedging their future on Linux.