Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes for personal projects? No thanks

carlosrdrz.es

Post reply on HN
Print view View original

181–190 of 278 posts

Re: Kubernetes for personal projects? No thanks

#181

Post by hosh »

theptip wrote: post #174
carlisle_ wrote: post #165

Earlier quoted context omitted.

> taking more time away from actually building your side project and putting it into building infrastructure around your side project. I generally dislike this way of thinking. Infrastructure is a core component of whatever it is you're building, not an afterthought. Maybe you can defer things until a little bit later, but if you can build with infrastructure in mind you'll be saving yourself so many headaches down t…

> Infrastructure is a core component of whatever it is you're building That's true in some sense -- but you can get surprisingly far using a PaaS like Heroku to abstract that infrastructure away. I'm a big fan of Kubernetes, and use it in production at my company, but I would not recommend using k8s in a prototype/early-stage startup unless you're already very familiar with the tool. The complexity overhead of k8s is…

I am a big fan of K8S too, not only use it in production, but I was also the one that set it up for my team. I agree that, unless you are already familiar with it, it is not always useful for protyping stage.

There is something to be said about having the infrastructure in mind though. That's why I'm inclined to use something like Elixir/Phoenix for web-based projects. Some (not all) of the ideas that K8S brings to the table are already built into the Erlang/OTP platform.

As for Heroku, there was a recent announcement that I think shifts things quite a bit: https://blog.heroku.com/buildpacks-go-cloud-native ... having standardized container images that runs buildpacks.

The ecosystem and tooling is not quite there yet, but I can see this as significantly reducing the investment to put into Dockerizing your app for K8S.

At that point, for the hobbyist, it might be:

Prototype -> Heroku -> K8S with an Operator that can run the buildpack

K8S is really a toolset for building your own PAAS. If there were a self-driving PAAS (using Operators) targeting small hobbyists that will run cloud native buildpacks, then the barriers of entry for a hobbyist using K8S is much lower.

Re: Kubernetes for personal projects? No thanks

#182

Post by hosh »

specialp wrote: post #74
carlosrdrz wrote: post #37

Earlier quoted context omitted.

I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably…

I don't understand what the operational burden is. We literally do nothing to our K8s cluster, and it runs for many months until we make a new updated cluster and blow away the old one. We've never had an issue attributed to K8s in the 2 years we have been running it in production. If we ever did, we'd just again deploy a new cluster in minutes and switch over. Immutable infrastructure. It is not like I haven't done…

I have had the same experience and the same journey from hand deploys, using configuration management, and all of that.

Re: Kubernetes for personal projects? No thanks

#183

Post by [deleted] »

collyw wrote: post #92
pstadler wrote: post #36

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. On…

> just write a couple of manifests to deploy a project, versus... Whenever anyone says " just do something" these days, it usually means that it hasn't been thought through properly. Is that only my personal experience?

[deleted]

Re: Kubernetes for personal projects? No thanks

#184

Post by hosh »

tokyodude wrote: post #163
solatic wrote: post #21

Oh man, the original article went way over the author's head. The point of the original article was that even though Kubernetes is primarily useful for tackling the challenges involved with running many workloads at enterprise scale, it can also be used to run small hobbyist workloads at a price point acceptable for hobbyist projects. Does that mean that Kubernetes should now be used for all hobbyist projects? No. If…

I wish it had been around 4 years ago. 4 years ago I made a website where users can post 100k messages. I used Meteor which was fine but it was frustrating as hell that it wasn't "complete stack". I don't know what term to use but "full stack" apparently just means front end (html/css/js in browser) and backend (server software). Full stack is missing backup and restore, deployment, seamless upgrades (pushing new ver…

It's getting there. The building blocks are being created one by one -- Minikube (single-node K8s for devs), Helm (packaging for K8S), Operator framework (and individual Operators for self-driving infrastructure). The most recent piece is Heroku's announcement for cloud-native buildpacks, allowing for standardized container images to run your buildpacks.

Stateful workloads (the database servers) are not quite there yet and remains one of the most challenging parts of K8S. We are just starting to see Operators written for specific datastores (Mongodb, Postgresql, Redis, etc.)

I don't know about 10 years ... but it is not that turn-key right now, yet.

Re: Kubernetes for personal projects? No thanks

#185

Post by icedchai »

justinsaccount wrote: post #160
wgjordan wrote: post #153

Earlier quoted context omitted.

> Still A single service on a single machine, how do I safely upgrade it? Depending on your OS-package's provided init script (here Ubuntu), it's as simple as `service nginx reload`, (`service nginx upgrade` if upgrading nginx itself). Or skip the init script entirely with `/usr/sbin/nginx -s reload`.

I am asking how one would safely upgrade the service that nginx is proxying to, not how to restart nginx.

You could do "blue-green" deployments with port numbers... service rev A is on port 1001, service rev B is on port 1002... deploy new rev... change nginx config to point to 1002... roll back, you repoint to 1001...

Re: Kubernetes for personal projects? No thanks

#186

Post by nijave »

hosh wrote: post #181
theptip wrote: post #174

Earlier quoted context omitted.

> Infrastructure is a core component of whatever it is you're building That's true in some sense -- but you can get surprisingly far using a PaaS like Heroku to abstract that infrastructure away. I'm a big fan of Kubernetes, and use it in production at my company, but I would not recommend using k8s in a prototype/early-stage startup unless you're already very familiar with the tool. The complexity overhead of k8s is…

I am a big fan of K8S too, not only use it in production, but I was also the one that set it up for my team. I agree that, unless you are already familiar with it, it is not always useful for protyping stage. There is something to be said about having the infrastructure in mind though. That's why I'm inclined to use something like Elixir/Phoenix for web-based projects. Some (not all) of the ideas that K8S brings to t…

Cloud Foundry dev (pcf dev) or minishift will give you your own PaaS running in a VM

Re: Kubernetes for personal projects? No thanks

#187

Post by dsnuh »

Draiken wrote: post #122
falcolas wrote: post #76

Earlier quoted context omitted.

Let's talk about complexity for a moment, for one aspect of a simple service: ingress. Kubernetes: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 Nginx: location /testpath { proxy_path http://127.0.0.1:8080 } Which is less complex? Which is beta, and thus could be changed over time (it happens a lot). W…

I think this is proving my point. They're basically the same, but one is completely dynamic and the other will have to be changed as soon as anything changes. We've been using Kubernetes in production for almost two years now and I have yet to face a big API change that breaks everything. The core APIs are stable. There's a lot of new stuff added, but nothing that breaks backwards compatibility. As you just said, if…

I think the key element here is that you are using GKE. Managed cloud Kubernetes, and self-hosted on-prem Kubernetes are two different beasts. Yes, it's easy when you don't actually have to run the cluster yourself.

Ansible has its warts, but it is great for managing and configuring individual servers.

Re: Kubernetes for personal projects? No thanks

#188

Post by [deleted] »

collyw wrote: post #92
pstadler wrote: post #36

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. On…

> just write a couple of manifests to deploy a project, versus... Whenever anyone says " just do something" these days, it usually means that it hasn't been thought through properly. Is that only my personal experience?

[deleted]

Re: Kubernetes for personal projects? No thanks

#189

Post by wpietri »

mhink wrote: post #150
wpietri wrote: post #106

Earlier quoted context omitted.

Personally, as somebody who is building a small Kubernetes cluster right now at home just for the fun of it: I think using Kubernetes for small projects is mostly a bad idea. So I appreciate the author warning people so they don't get misled by all the (justified) buzz around it. For your average developer who just wants to get something running on a port, Kubernetes introduces two barriers: containerization and Kube…

> For your average developer who just wants to get something running on a port, Kubernetes introduces two barriers: containerization and Kubernetes itself. These are non-trivial things to learn, especially if you don't have an ops background, and both of them add substantial debugging overhead. From the application-developer side, I'd dispute this. I was told to use Docker + Kubernetes for a relatively small work pro…

Did you already have a Kubernetes cluster set up? If so, that seems plausible to me. And yes, if you're deploying to a PaaS already, Kubernetes is a fine one. But compared to "start up a process and leave it running", I think any PaaS requires a fair bit of learning to deploy anything complicated.
Post reply on HN