I have been using ksonnet but that is now officially dead. Working with jsonnet seemed unnecessarily painful when coming from coding typescript. This information is quite timely and welcome, I'll look further at the ts example.
We have ksonnet expats on the team (we're all in cloud city -- Seattle), and I've been keeping an eye on that project myself, since I think it got a lot of things right and frankly many of the ideas for Pulumi were inspired by early chats with the Heptio team. But, as you say, why create a new language when an existing one will do -- that was our original stance and it's working great in practice.
Oh! I don’t know where I got that impression from then! perhaps I just thought that we couldn’t use the free tier because of the number of licenses we’d need, but you’re right, it’s still there!
I'm not sure you understand the value k8s proposes based on your comments throughout this entire thread.
Managing many nodes is the reason orchestration software exists. Your suggestion to "put some effort into configuration management" is effectively naive, homegrown orchestration.
Build or buy? That's the same argument - except k8s is free and available from many providers.
I get the sense that the naysayers outweight the supporters, simply because the headline alone is not news. Don't let them deter you, spend a few hours and decide for yourself.
Which part of kubernetes is "developed with the intention to eventually get you to use the hosted version"?
Offering software for free, software that is widely adopted cannot be based on the motivations you propose, unless there is a grand conspiracy of cloud providers for which I am unaware.
LXC on which Docker was based always had a much more sensible container model and contrary to the pervasive misinformation by the devops ecosystem is far easier to use.
It supports a standard OS environment and does not enforce the use of layers so users don't have to deal with single process non standard OS environment which removes half the complexity.
We are working on a project, Flockport, that supports LXC and provides an app store, orchestration, networking, distributed storage, service discovery and HA. So there are attempts to explore simpler alternatives.
I see a semblance to their original motivations in building chrome. By making the web as a whole more competitive, it made google's offerings more competitive (more ad surfaces, more gmail users, less OS lockin). Actually winning the browser war isn't necessary.
For a huge number or organizations, the cloud isn't a meaningful option because the switching costs are astronomical. Kubernetes, otoh, means someone that chooses on prem today actually has a migration path later.
Google benefits hugely from that path just existing.
Use k8s exactly for the reason of either being federated across cloud providers or simply portable across cloud providers. You can't do that with vendor specific solutions e.g. elastic beanstalk
What keeps people highly coupled with could provider is not where their code is running but rather other "here only" solutions like custom DBs or infrastructure.
You can rewrite code deployment script for any provider in few days worth of work, but switching between other tech stack will be near impossible.
> You can rewrite code deployment script for any provider in few days worth of work
I've directly experienced the counter example to this at a major SaaS company. Beyond methods you'd use for < 20 machines this just isn't true. Your orchestration of machine lifecycles will be tied up into the particular cloud no matter what kinds of abstractions you try to put in. Unless you start running on multiple clouds or you write to k8s instead of the cloud APIs, you will be locked in.
> What keeps people highly coupled with could provider is not where their code is running but rather other "here only" solutions like custom DBs or infrastructure.
I agree, and the advent of k8s adoption is one less thing that locks you into a provider.
Yes. Based solely on your desire to be on top of tech and given the broad adoption by every major provider, you probably want to invest at least a couple of days.
That doesn't mean there is any impetus to transition your current production, only that it is most definitely worth a cursory understanding for the future.
All major cloud providers have/will have managed kubernetes and they are free to use the name, therefore I doubt it could be regarded as direct marketing for GCP. I would expect many to consider GCP but I just don't perceive this as a backdoor way of Google getting your apps, given the broad buy-in by the cloud provider community.
Well yes, you can replace Google with like two or three other companies in my comment. At the end of the day I don't like the trend of outsourcing all the interesting bits of technology to a handful of mega corporations. I think it is not a good bargaining position for us developers, Google and the like can already get away with paying shitty salaries and it will only get worse the more control they have. For all the smaller companies, they are paying a cloud provider instead of hiring local talent to build solutions. It's loose/loose.
That's effectively anti-globalization. Adapt and overcome. Good developers will always have a job in the forseeable decades to come, weak or stagnant developers will be at risk, it is a maturing industry. White knuckling tech by resisting change/momentum is no more effective than starting a trade war with tariffs.
