13 ms·

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

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'm thinking of playing around with a Raspberry Pi or other SBC, do I need to install Kubernetes on the SBC first? If I'm thinking of playing around with IoT or serverless, should I dump AWS- or GCE-proprietary tools because nobody will ever run anything that that can't run on Kubernetes ever again? If I'm going to play around with React or React Native, should I write up a backend just so I can have something that I can run in a Kubernetes cluster, because all hobbyist projects must run Kubernetes now, because it's cheap enough for hobbyist projects? If I'm going to play around with machine learning at home, buy a machine with a heavy GPU, figure out how to get Kubernetes to schedule my machine learning workload correctly instead of just running it directly on that machine, because uhhh maybe someday I'll have three such machines with powerful GPUs plus other home servers for all my other hobbyist projects? No, no, no, no, no. Clearly. But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Different people will use different solutions for different project requirements.

carlosrdrz 8y ago
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 wrong. I don't think that is wrong. I do think it is probably overkill, and IMO it does introduce operational burden and complexity. That doesn't mean you shouldn't do it, though, if you're interested in exploring the technology, for example.
- Draiken 8y ago
  I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not. The difference is that if you did build it all by hand as the author said, if it ever scales, you're going to have double the job to make it scale. It's all a question of: do I think my software will succeed? If it's a hobby project that will never get big, it's not worth the hassle. If it actually has a chance of succeeding, the small added complexity of Kubernetes will pay dividends extremely quickly when the system needs to scale. Even with as little as two machines, I'd argue k8s is already adding more value than managing those by hand. People can say otherwise because they're used to it, but being used to it is not the point of the discussion. The author also talks about Ansible which is another piece of complexity that would be comparable with doing it in k8s. I'd argue you have less YAMLs with k8s than with Ansible for a small project. The only argument I see for doing anything by hand today is if it's a play thing.
  - carlosrdrz 8y ago
    I see what you mean, but I don't really agree. You can introduce that burden and complexity whenever you want. If you spend the start of your project working on this, you will be prepared for scaling (if you ever need it) but you could have used that time on actually working on the project and checking if you actually will need scale at some point. I don't know about your projects, but I'm my case most (all) of them doesn't really need any kind of scale. Hell, this blog has a tiny 5$ DO machine and is still happily serving traffic from HN. I do understand not all projects are small blog instances, though :) I guess in my case I prefer to just keep it simple and see how far I go with that setup than spending time working on making the perfectly-scalable project that is never serving more than 2 requests per second. If it ever grows, I will need to work to make it scale, sure, but on the other hand that is a good problem to have. Anyway, I understand this is pretty subjective and depends on how you think about your projects and your requirements, so I do understand there will be people both in agreement and disagreement.
    - Draiken 8y ago
      I completely agree it's overkill to run your own cluster. That'd be good for a learning experience, but way too complex to use/maintain otherwise. However I read somewhere you had experience with Kubernetes, right? That means there is no extra work to learn the technology. Now let's take your blog as an example. I'm gonna guess there's an official Docker image for whatever software you use and you could create an image, deployment + service + ingress in less than an hour for it (pretty much every example out there is about how to setup a blog, heh). If you have to do all that manually through SSH, I'd argue it takes pretty much the same time and the complexity is the same. You will simply change the tools/concepts but won't be caught by manual gotchas.
jaxtellerSoA 8y ago
>But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Exactly. Or maybe "I would love to advance my career and work for a larger company that is using Kubernetes, and I can get some hands on experience without breaking the bank."
- calgoo 8y ago
  FYI the last part of the conclusion mentions this as well: "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! But really, would I do all of this just to run a personal project? No thanks."
geggam 8y ago
Do kubernetes the hard way and soon you might realize its not really a nice shiny machine. Its a complex system which you can put together in a way to help.... or hurt, completely dependent on your abilities. https://github.com/kelseyhightower/kubernetes-the-hard-way https://github.com/kelseyhightower/kubernetes-the-hard-way
shams93 8y ago
Doing a small project is a best way to learn a new system. If you never plan to use Kubernetes then I would agree, why would you use it at all? But if you're exploring it there could be no better way to get your feet wet than with a small project.
wpietri 8y ago
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 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. And again for that developer, they provide very, very small gains. I think the calculus changes if that developer starts to run multiple services on multiple servers, wants to keep doing that for years, and needs high uptime. I have a bunch of personal services I run in VMs with Chef, and I'm excited to convert that over to Kubernetes, as it will make future OS upgrades and other maintenance easier. But my old setup ran for something like 6 years and it was just fine. For hobbyists whose hobbies don't include playing with cluster-scale ops tooling, I think it's perfectly fine to ignore Kubernetes. It's the new hotness, but it doesn't provide much value for them yet. They can wait a few years; by then the tooling will surely have improved for low-end installs.
- ehsankia 8y ago
  > These are non-trivial things to learn Right, but again I think the point being made is that, if those are skills you do want to learn, or plan on using later down the road, it's worth knowing that you can use K8s even at a small scale. Obviously, in most cases it could be premature optimization, but for some people (including you), it can be fun to learn.
  - emodendroket 8y ago
    OK, but this is a point made in the article the comment attempts to refute!
- weberc2 8y ago
  I think the original article made a good point, and one that seems to be overlooked by pretty much every critical response: if you don't already know standard sysadmin tooling and procedures, then the value proposition for k8s for small projects alone is probably comparable to standard sysadmin tooling. At least with k8s, you can take that knowledge with you when you want to scale. I don't know if I'm totally convinced by that argument alone, but it would be nice if every critical response didn't seem to assume that every hobbyist is born understanding systemd, ansible, packer, qemu, etc.
nebulous1 8y ago
I don't see anywhere that you've explained how the original article "went way over the author's head", and your examples of suitable small project vs non-suitable aren't in the original article at all, you just decided all of that yourself. The original article concludes with "It's my contention that Kubernetes also makes sense for small deployments and is both easy-to-use and inexpensive today". This article contends that it's not at all easy to use and price-wise he hasn't compared like-with-like.
superkuh 8y ago
It is a really weak argument for Kubernetes for personal projects when the only realistic scenario is when the personal project is to learn Kubernetes.
admax88q 8y ago
> 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 side project, then perfect go do that. Otherwise its just a distraction, taking more time away from actually building your side project and putting it into building infrastructure around your side project. If what you really wanted to build is infrastructure, then great, you're doing swell, but if you were really trying to build some other fun side app, Kubernetes is just a time/money sink in almost all cases IMO.
- tomnipotent 8y ago
  > The state of the art for cluster management will probably something completely different by then Has it not only changed twice in the prior two decades between first VMs and now containers? Don't think this is something you have to worry about long term.
  - llama052 8y ago
    Uh I don't think vms or containers are cluster management in itself. They are just technologies. What you use to orchestrate them is entirely different, and yes that has changed over the years many times.
    - tomnipotent 8y ago
      For example? Most early cluster management was found in products doing general fleet provisioning, HPC/HTC in academia, proprietary commercials offerings like relational databases, or proprietary in-house solutions like Google's Borg. I'd describe cluster management as four things - provisioning + configuration, resource management (CPU+RAM+Disk), scheduling (when & where to put things based on availability/resources), and deployment (running things). At least, these are the things I'm concerned about when managing a product that requires a cluster (besides monitoring). Early cluster management tools were often just doing provisioning and configuration (CFEngine). We see Puppet, Chef, and eventually Ansible further refine the solution as we enter the "Bronze Era" where standing up new servers take a fraction of the time. Now we didn't even bother to name each server by hand when we were going through the installation process after booting up the OS - servers had become cattle, and they were tagged appropriately. Around the same time (2003-2006) we see virtual machines begin to catch on, culminating in the 2006 debut of Amazon Elastic Compute Cloud (EC2) and the birth of modern cloud computing. We now had a general purpose mechanism (VMs) to spin up isolated compute units that could be provisioned, configured, and managed using tools like CFEngine & Puppet. IT departments begin spending less on the SANs that dominated the early aughts and shift budgets to AWS or VMWare ESXi. Then in 2006 we see Hadoop spin off from Nutch, and the MapReduce paradigm popularized by Google leads to an optimization of the resource and scheduling problems thanks to YARN and Mesos and related tools. Non-trivial programs and workloads can now be scheduled across a cluster with vastly improved confidence. Distributed programs are now in reach of a much larger audience. Suddenly new Hadoop clusters are springing up everywhere and the "Silver Era" begins. Tools enabling greater efficiency hit the scene like RPC serialization frameworks (Thrift, Protobuf), improved on-disk storage (O/RCFile, Parquet), distributed queues (RabbitMQ, SQS), clustered databases (Cassandra, HBase), and event streaming and processing (Storm, Kafka). Coordination becomes more complicated and essential, so we get ZooKeeper and etcd and consul. Managing passwords and other secure data leads to tools like Vault. Logstash and Graylog make log management less of a nightmare. Solr leads to Elasticsearch leads Kibana and we now have logging and visualization for both server and application monitoring. Developers also begin to take advantage of VMs and it's not long before tools like Vagrant help bridge the gap between development, staging, and production. Our profession takes a collective sigh of relief as getting our distributed programs started on a new developers machine went from three days of trial-and-error to minutes thanks to well-maintained Vagrantfiles. Still, deployment is a big pain point. A single cluster could be home to Hadoop (which benefits from YARN) and thirty other things being run by teams across the organization. One day you discover that your mission critical web app is sharing resources with your BI team after your CEO calls you in a panic to tell you the website is down. Turns out a DBA transferred a 20TB backup across the same switch shared with your customer-facing website because somebody forgot to isolate a VLAN to prevent backups from interfering with other traffic. This doesn't even take into the consideration the abominations we call deployment scripts that developers and DevOps wrangle together to get our programs deployed. Then Docker and containers become a thing. Developers are now able to setup incredibly complex distributed programs with little more than text files. No more coordinating with DevOps to make sure your servers have the latest version of libpng, or spending months fighting to get Java upgraded to the latest version. I shout in glee as I delete Chef from my machine because progress. Then the beer goggles dissipate and the love affair ends and we realize things are shitty in a different way. Docker Swarm and Kubernetes emerge, and that brings us to today which I'll call the "Golden Era". We now have incredible tooling that deals with provisioning and configuration, resource management, scheduling, and deployment. But like any new era there are rough spots, but I'm positive incredible new tech will popup. Throughout all of this, virtual machines and containers were the fundamental building blocks that enabled improved clustering and cluster management. They're inextricably tied together. But all-in-all, things have changed VERY little (couhg LXC cough) in 20 years compared to the rest of the landscape. We're solid for another 10 years before anything like this is going to happen again.
coldtea 8y ago
>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? Well, it shouldn't be used but for very very few (if any) hobbyist projects. Which is closer to this post, than the original article. >But maybe I envision my side project turning into full-time startup some day. Facebook managed this just fine as a simple PHP project on some guys laptop. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
turtlebits 8y ago
Kubernetes is way overkill for personal projects. If a side goal is to learn Kubernetes while deploying your projects, then go for it. If not, docker-compose is good enough and is actually very good for local development.
tokyodude 8y ago
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 versions without down the service), scaling, testing infrastructure both front and backend, staging As such, I have a hacked manual backup for my site. Anytime I want to update my site I have to take it offline for at least a moment. If any users were on it they lose their work. If it ever gets too much traffic I'll have to manually figure out how to scale it. It also took at least a week to get it where it is, as in a week doing stuff not my actual site but just learning how to deploy at all. I can see no reason all of that can't be 100% provided out of the box and if Kubernetes is the path there I'm all for it. Ideally I want to do something like git clone complete-stack install deps edit server-main.js (or other lang) edit client-main.js (or other lang) deploy --init Then I want edit server-main.js (or other lang) edit client-main.js (or other lang) stage test edit server-main.js (or other lang) edit client-main.js (or other lang) stage test deploy And scale --num-servers=2 I would use it for any web based projects that aren't static servers. I'm told by people who provide tech support for people using Kubernetes that my dream of all of this being provided out of the box is about 10yr out.
- hosh 8y ago
  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.
- ecnahc515 8y ago
  Openshift already provides this experience. It's pretty much your own heroku on k8s.
draw_down 8y ago
I think people can understand one another and still disagree. I think that's okay.
outworlder 8y ago
> If I'm thinking of playing around with a Raspberry Pi or other SBC, do I need to install Kubernetes on the SBC first? No! Although you could deploy it as a docker container easily. Simple heuristic: how many containers and machines am I dealing with? More than one machine and one container? Consider moving to Docker Swarm or K8s. A single container? What is there to orchestrate?
emodendroket 8y ago
> But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! He says it's fine to do it if you want to learn the technology, but points out (rightly, I think) that if your concern is that you might need it at some point down the road, worry about it at some point down the road and not when you're trying to get started.

carlosrdrz 8y ago

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 wrong. I don't think that is wrong. I do think it is probably overkill, and IMO it does introduce operational burden and complexity. That doesn't mean you shouldn't do it, though, if you're interested in exploring the technology, for example.

Draiken 8y ago
I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not. The difference is that if you did build it all by hand as the author said, if it ever scales, you're going to have double the job to make it scale. It's all a question of: do I think my software will succeed? If it's a hobby project that will never get big, it's not worth the hassle. If it actually has a chance of succeeding, the small added complexity of Kubernetes will pay dividends extremely quickly when the system needs to scale. Even with as little as two machines, I'd argue k8s is already adding more value than managing those by hand. People can say otherwise because they're used to it, but being used to it is not the point of the discussion. The author also talks about Ansible which is another piece of complexity that would be comparable with doing it in k8s. I'd argue you have less YAMLs with k8s than with Ansible for a small project. The only argument I see for doing anything by hand today is if it's a play thing.
- carlosrdrz 8y ago
  I see what you mean, but I don't really agree. You can introduce that burden and complexity whenever you want. If you spend the start of your project working on this, you will be prepared for scaling (if you ever need it) but you could have used that time on actually working on the project and checking if you actually will need scale at some point. I don't know about your projects, but I'm my case most (all) of them doesn't really need any kind of scale. Hell, this blog has a tiny 5$ DO machine and is still happily serving traffic from HN. I do understand not all projects are small blog instances, though :) I guess in my case I prefer to just keep it simple and see how far I go with that setup than spending time working on making the perfectly-scalable project that is never serving more than 2 requests per second. If it ever grows, I will need to work to make it scale, sure, but on the other hand that is a good problem to have. Anyway, I understand this is pretty subjective and depends on how you think about your projects and your requirements, so I do understand there will be people both in agreement and disagreement.
  - Draiken 8y ago
    I completely agree it's overkill to run your own cluster. That'd be good for a learning experience, but way too complex to use/maintain otherwise. However I read somewhere you had experience with Kubernetes, right? That means there is no extra work to learn the technology. Now let's take your blog as an example. I'm gonna guess there's an official Docker image for whatever software you use and you could create an image, deployment + service + ingress in less than an hour for it (pretty much every example out there is about how to setup a blog, heh). If you have to do all that manually through SSH, I'd argue it takes pretty much the same time and the complexity is the same. You will simply change the tools/concepts but won't be caught by manual gotchas.

jaxtellerSoA 8y ago

>But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Exactly. Or maybe "I would love to advance my career and work for a larger company that is using Kubernetes, and I can get some hands on experience without breaking the bank."

calgoo 8y ago
FYI the last part of the conclusion mentions this as well: "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! But really, would I do all of this just to run a personal project? No thanks."

geggam 8y ago

Do kubernetes the hard way and soon you might realize its not really a nice shiny machine. Its a complex system which you can put together in a way to help.... or hurt, completely dependent on your abilities. https://github.com/kelseyhightower/kubernetes-the-hard-way https://github.com/kelseyhightower/kubernetes-the-hard-way

shams93 8y ago

Doing a small project is a best way to learn a new system. If you never plan to use Kubernetes then I would agree, why would you use it at all? But if you're exploring it there could be no better way to get your feet wet than with a small project.

wpietri 8y ago

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 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. And again for that developer, they provide very, very small gains. I think the calculus changes if that developer starts to run multiple services on multiple servers, wants to keep doing that for years, and needs high uptime. I have a bunch of personal services I run in VMs with Chef, and I'm excited to convert that over to Kubernetes, as it will make future OS upgrades and other maintenance easier. But my old setup ran for something like 6 years and it was just fine. For hobbyists whose hobbies don't include playing with cluster-scale ops tooling, I think it's perfectly fine to ignore Kubernetes. It's the new hotness, but it doesn't provide much value for them yet. They can wait a few years; by then the tooling will surely have improved for low-end installs.

ehsankia 8y ago
> These are non-trivial things to learn Right, but again I think the point being made is that, if those are skills you do want to learn, or plan on using later down the road, it's worth knowing that you can use K8s even at a small scale. Obviously, in most cases it could be premature optimization, but for some people (including you), it can be fun to learn.
- emodendroket 8y ago
  OK, but this is a point made in the article the comment attempts to refute!
weberc2 8y ago
I think the original article made a good point, and one that seems to be overlooked by pretty much every critical response: if you don't already know standard sysadmin tooling and procedures, then the value proposition for k8s for small projects alone is probably comparable to standard sysadmin tooling. At least with k8s, you can take that knowledge with you when you want to scale. I don't know if I'm totally convinced by that argument alone, but it would be nice if every critical response didn't seem to assume that every hobbyist is born understanding systemd, ansible, packer, qemu, etc.

nebulous1 8y ago

I don't see anywhere that you've explained how the original article "went way over the author's head", and your examples of suitable small project vs non-suitable aren't in the original article at all, you just decided all of that yourself. The original article concludes with "It's my contention that Kubernetes also makes sense for small deployments and is both easy-to-use and inexpensive today". This article contends that it's not at all easy to use and price-wise he hasn't compared like-with-like.

superkuh 8y ago

It is a really weak argument for Kubernetes for personal projects when the only realistic scenario is when the personal project is to learn Kubernetes.

admax88q 8y ago

> 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 side project, then perfect go do that. Otherwise its just a distraction, taking more time away from actually building your side project and putting it into building infrastructure around your side project. If what you really wanted to build is infrastructure, then great, you're doing swell, but if you were really trying to build some other fun side app, Kubernetes is just a time/money sink in almost all cases IMO.

tomnipotent 8y ago
> The state of the art for cluster management will probably something completely different by then Has it not only changed twice in the prior two decades between first VMs and now containers? Don't think this is something you have to worry about long term.
- llama052 8y ago
  Uh I don't think vms or containers are cluster management in itself. They are just technologies. What you use to orchestrate them is entirely different, and yes that has changed over the years many times.
  - tomnipotent 8y ago
    For example? Most early cluster management was found in products doing general fleet provisioning, HPC/HTC in academia, proprietary commercials offerings like relational databases, or proprietary in-house solutions like Google's Borg. I'd describe cluster management as four things - provisioning + configuration, resource management (CPU+RAM+Disk), scheduling (when & where to put things based on availability/resources), and deployment (running things). At least, these are the things I'm concerned about when managing a product that requires a cluster (besides monitoring). Early cluster management tools were often just doing provisioning and configuration (CFEngine). We see Puppet, Chef, and eventually Ansible further refine the solution as we enter the "Bronze Era" where standing up new servers take a fraction of the time. Now we didn't even bother to name each server by hand when we were going through the installation process after booting up the OS - servers had become cattle, and they were tagged appropriately. Around the same time (2003-2006) we see virtual machines begin to catch on, culminating in the 2006 debut of Amazon Elastic Compute Cloud (EC2) and the birth of modern cloud computing. We now had a general purpose mechanism (VMs) to spin up isolated compute units that could be provisioned, configured, and managed using tools like CFEngine & Puppet. IT departments begin spending less on the SANs that dominated the early aughts and shift budgets to AWS or VMWare ESXi. Then in 2006 we see Hadoop spin off from Nutch, and the MapReduce paradigm popularized by Google leads to an optimization of the resource and scheduling problems thanks to YARN and Mesos and related tools. Non-trivial programs and workloads can now be scheduled across a cluster with vastly improved confidence. Distributed programs are now in reach of a much larger audience. Suddenly new Hadoop clusters are springing up everywhere and the "Silver Era" begins. Tools enabling greater efficiency hit the scene like RPC serialization frameworks (Thrift, Protobuf), improved on-disk storage (O/RCFile, Parquet), distributed queues (RabbitMQ, SQS), clustered databases (Cassandra, HBase), and event streaming and processing (Storm, Kafka). Coordination becomes more complicated and essential, so we get ZooKeeper and etcd and consul. Managing passwords and other secure data leads to tools like Vault. Logstash and Graylog make log management less of a nightmare. Solr leads to Elasticsearch leads Kibana and we now have logging and visualization for both server and application monitoring. Developers also begin to take advantage of VMs and it's not long before tools like Vagrant help bridge the gap between development, staging, and production. Our profession takes a collective sigh of relief as getting our distributed programs started on a new developers machine went from three days of trial-and-error to minutes thanks to well-maintained Vagrantfiles. Still, deployment is a big pain point. A single cluster could be home to Hadoop (which benefits from YARN) and thirty other things being run by teams across the organization. One day you discover that your mission critical web app is sharing resources with your BI team after your CEO calls you in a panic to tell you the website is down. Turns out a DBA transferred a 20TB backup across the same switch shared with your customer-facing website because somebody forgot to isolate a VLAN to prevent backups from interfering with other traffic. This doesn't even take into the consideration the abominations we call deployment scripts that developers and DevOps wrangle together to get our programs deployed. Then Docker and containers become a thing. Developers are now able to setup incredibly complex distributed programs with little more than text files. No more coordinating with DevOps to make sure your servers have the latest version of libpng, or spending months fighting to get Java upgraded to the latest version. I shout in glee as I delete Chef from my machine because progress. Then the beer goggles dissipate and the love affair ends and we realize things are shitty in a different way. Docker Swarm and Kubernetes emerge, and that brings us to today which I'll call the "Golden Era". We now have incredible tooling that deals with provisioning and configuration, resource management, scheduling, and deployment. But like any new era there are rough spots, but I'm positive incredible new tech will popup. Throughout all of this, virtual machines and containers were the fundamental building blocks that enabled improved clustering and cluster management. They're inextricably tied together. But all-in-all, things have changed VERY little (couhg LXC cough) in 20 years compared to the rest of the landscape. We're solid for another 10 years before anything like this is going to happen again.

coldtea 8y ago

>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? Well, it shouldn't be used but for very very few (if any) hobbyist projects. Which is closer to this post, than the original article. >But maybe I envision my side project turning into full-time startup some day. Facebook managed this just fine as a simple PHP project on some guys laptop. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

turtlebits 8y ago

Kubernetes is way overkill for personal projects. If a side goal is to learn Kubernetes while deploying your projects, then go for it. If not, docker-compose is good enough and is actually very good for local development.

tokyodude 8y ago

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 versions without down the service), scaling, testing infrastructure both front and backend, staging As such, I have a hacked manual backup for my site. Anytime I want to update my site I have to take it offline for at least a moment. If any users were on it they lose their work. If it ever gets too much traffic I'll have to manually figure out how to scale it. It also took at least a week to get it where it is, as in a week doing stuff not my actual site but just learning how to deploy at all. I can see no reason all of that can't be 100% provided out of the box and if Kubernetes is the path there I'm all for it. Ideally I want to do something like git clone complete-stack install deps edit server-main.js (or other lang) edit client-main.js (or other lang) deploy --init Then I want edit server-main.js (or other lang) edit client-main.js (or other lang) stage test edit server-main.js (or other lang) edit client-main.js (or other lang) stage test deploy And scale --num-servers=2 I would use it for any web based projects that aren't static servers. I'm told by people who provide tech support for people using Kubernetes that my dream of all of this being provided out of the box is about 10yr out.

hosh 8y ago
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.
ecnahc515 8y ago
Openshift already provides this experience. It's pretty much your own heroku on k8s.

draw_down 8y ago

I think people can understand one another and still disagree. I think that's okay.

outworlder 8y ago

> If I'm thinking of playing around with a Raspberry Pi or other SBC, do I need to install Kubernetes on the SBC first? No! Although you could deploy it as a docker container easily. Simple heuristic: how many containers and machines am I dealing with? More than one machine and one container? Consider moving to Docker Swarm or K8s. A single container? What is there to orchestrate?

emodendroket 8y ago

> But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! He says it's fine to do it if you want to learn the technology, but points out (rightly, I think) that if your concern is that you might need it at some point down the road, worry about it at some point down the road and not when you're trying to get started.