211–220 of 278 posts
Earlier quoted context omitted.
One layer, maybe, but should you be able to deploy any type of web server on every OS if you're writing a web app? I'm not so sure.
> One layer Yes, that's why I said "layer beneath" and not "layerS beneath"
I’m itching to replace my home server’s FreeBSD with Linux and Kubernetes. I use it (& build dev tools for others) at work plenty so for me, the learning curve is in the past. I’m not sure if I would recommend this journey for others, but I also wouldn’t recommend FreeBSD to anyone, either. In both cases, you know what you’re getting in to - something complex, opinionated, powerful, and industrial strength.
You'll know this already but I'd say when you're coming from FreeBSD you'll be disappointed with Docker in particular, because it serves no purpose in the (usually) well-organized BSD world where the good stuff is built from source, and developed to POSIX guidelines most of the time anyway. Docker is just a workaround for the perceived mess of shared libraries in the Linux world of multiple O/S vendors (by not using…
If there was a Jailfile equivalent for FreeBSD and a command-line tool with the same interfaces as docker, namely `docker run --rm -it ...`, I might be staying on FreeBSD.
So I'm calling it quits for now. Just running the cluster requires a small ops team.
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…
Are you running databases in Kubernetes? Do you have any existing on-prem infrastructure that you want to utilize (or are required to, because sunk costs) to integrate with Kubernetes?
Is you company a startup with no existing legacy application that you need to figure out how to containerize before you can even think about getting it into Kubernetes? We've seen benefits from running it, for sure, but I'm honestly not sure if the amount of work it took (and still takes) to make it work for us was worth the ROI.
Sometimes I feel like Kubernetes is a play by Google to get everyone using their methodology, but only they can provide the seamless experience of GKE.
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…
Earlier quoted context omitted.
> But maybe I envision my side project turning into full-time startup some day. The state of the art for cluster management will probably something completely different by then. Better to build a good product now and if you really want to turn it into a startup, productionize it then. > Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. If learning Kubernetes _is_ your s…
> 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…
Until then I think my efforts are best spent making a simple monolith.
For random toy projects, spinning up a whole Kubernetes cluster is absolutely overkill (unless part of the project is learning Kubernetes). The thing is as you get further along, for some applications, it becomes harder and harder to move to a container-based design as you have to unwind all the weird dependency mappings. I've got an app I've been involved with containerizing for a client at work, and they're dead se…
So, back to the point, I'm sure you couldn't deploy your app on Heroku if that's your requirement (because cedar-14 is deprecated, and not available for new deployments anymore) but if you seriously wanted to try containerizing it onto Kubernetes, and if you don't have other obstacles to 12-factor design that you're also not prepared to tackle, then Hephy Workflow v2.19.4 might actually work for you.
https://teamhephy.com and https://docs.teamhephy.com
I'm sure this probably won't work for you, for reasons you may not have explained, but ... maybe you'd like to look?
I'm not doing a great job selling it, the one redeeming quality I've mentioned is that it runs an outdated stack that you need ;)
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…