For a startup, I'm still trying to figure out why you would use k8s instead of Google App Engine or other managed PaaS. You never worry about the problems listed in this article. You focus on writing code, deploying it with minimal config and let Google handle all these problems. Can anyone explain?
Because k8s is simpler than those solutions if you're not deploying things manually through the ui.
If you try to do something like infrastructure as code across multiple environments, with containers orchestration, service discovery, autoscaling, easy troubleshooting, authorization, easy domain name resolution, secrets at the container level then trying to do those things with App Engine becomes a horrifying ordeal.
The next question is obviously do you even need those things? But basic k8s really is easy to setup. Spinning up a cluster, writing some deployments, services, and setting up an ingress takes < 6 hours (half that if you do this regularly that you have documentation on it) and is the same experience everytime - there is no, I am using GCP at home so I don't know how to do this with AWS here. The CI/CD for the git repo is also pretty much the same.
Moreover, it's actually good. Sometimes you have industry standards that are just painful to use but do anyways because it's popular. With k8s, it really is a well thought out, mature solution that's better than most alternatives. Managed services often have a whole layer of bullshit e.g. last night I was looking at using App engine for a node app and I can't use the standard environment because I am using the latest version of Node that's not supported yet - and it's just one more nuisance to deal with. With k8s, it's just compute resources, containers, done. Simple.
You don't need to re-write the whole CI/CD stack, you don't need to re-engineer the app as a 12 factor app if/when the thing takes off and you need a real solution.
If your lead engineer gets hit by a bus tomorrow the whole deployment is in a helm chart somewhere and you can hire generic kubernetes tech #158326 to take over that job at any time.
Being able to engineer the app correctly the first time around, plus guaranteed business continuity are pretty big selling points. I would not invest in any company that did not have kubernetes, or a similar orchestration platform underpinning their product. Eventually that engineer will leave and you do not want to be scrambling for their replacement in the middle of the big growth push.
K8s probably wouldn't make sense for a lot of startups -- it's designed to solve a lot of different problems, and you're probably not going to be interested in solving most of those.
On the other hand, once you know k8s, it means you don't have to learn the specifics of any cloud platform. For most of my career I've worked in places that can't use cloud providers. I honestly dread having to learn all the different GCP or AWS tools/apis at a future job. But now that I have spent a lot of time learning k8s, it's nice to know that I can build on any cloud platform in the future, or self-hosted servers, and reuse the standard k8s APIs that I use at this job.
If I was building a startup, I'd use whatever the majority of engineers were already familiar with -- k8s, aws, gcp, whatever.
> k8s instead of Google App Engine or other managed PaaS
K8s is also available as a managed solution with GKE Autopilot, which in general is a breeze to use.
> You never worry about the problems listed in this article.
You still have to. If you look at the whole list of "how-to" guides one of the language docs for GAE (e.g. [0]), you see that there are about as much topics to worry about than if you were deploying to K8s. They also pretty much 1:1 map to things in K8s, but in contrast are non-standardized across vendors.
> deploying it with minimal config
I think the article laid out quite well how for a minimal deployment, the configuration you need for K8s is also pretty minimal. Yes, it might be more than a one-liner for a GAE config, but most of it is boilerplate you can ignore.
* you have workloads that don’t mesh well with common cloud PaaS patterns
* you want to pick-and-choose your cloud dependencies
* you want to use a commodity tech-stack so that hiring, tooling and support are far more readily available.
All of this comes with the obvious caveat of: sure, if you aren’t having issues, or reaching the limits of whatever PaaS solution you’re currently using, then don’t swap unnecessarily, but that still means there’s a lot of useful features that K8s offers.
For a startup that can do everything from scratch on one cloud provider, there aren’t many benefits. Those may come later once lock-in and complexity become a problem.
