3 ms·

I'm getting tired of these "you don't need k8 posts". Sure, if you have a simple web application with a REST API, don't use k8, unless it's for learning purpose

I'm getting tired of these "you don't need k8 posts". Sure, if you have a simple web application with a REST API, don't use k8, unless it's for learning purposes. But nobody does that anyway. If you have something more complex with many moving parts that are separate services, k8 is a great option. I've been using it in production for close to 2 years now - not a single service downtime, great fault-tolerance, and absolutely zero management effort. Deploying complex applications, databases, and monitoring systems is easier than ever before. I don't think using k8 is overly complex. Yes, you need to invest some time to learn it, but that's the case for every new technology.

FlyingSnake 7y ago
> But nobody does that anyway. Please speak for yourself. In my experience, most of the software that's written using k8s/µServices could've been written using a simple Flask+Nginx+monitoring on a DO Droplet. K8s and the extra overhead leads to extra efforts in developement and testing, and many software teams are perennially behind schedule on delivering features. There are ways to achieve fault tolerence without tying in to the complex ecosystem of K8s.
vincnetas 7y ago
"But nobody does that anyway." You'd be surprised, but they do. EDIT. I work at company with < 5 devs and we are in progress of moving our services to k8s. Will se how it goes.
onion2k 7y ago
Practically every SaaS business could be built as a single application or a set of services, especially at the beginning when all the traffic could be handled on one server. So whether or not k8s is appropriate isn't driven by your business's complexity but rather by your architecture choices. Choosing to build microservices is what adds complexity and makes tools like k8s necessary, not the business. That complexity can be useful. It can mean you don't need to build a simple version and a more scalable version later. It means you can replace parts as the business grows rather than the entire thing. You can outsource or buy some services. These are benefits, but they are also choices, and all of them increase the time it takes to get to market. In a very well funded startup that has years of runway sometimes choosing microservices makes sense. In most small startups that are just proving their model they'd be much better off hacking something together that they'll throw away later in order to validate the business idea. Finding out that your business doesn't work as a business is far more useful than building something that can scale just in case it does. The real difficulty in that is accepting that the idea you have might not actually work.
bertil 7y ago
We have a possible counter-example: our service is computing AB-test results (essentially reading from a database, processing totals, writing significance back). It have no non-system users, no dependencies, etc. All the test and strangeness is handled internally. We use k8s which is indeed over-engineered — it ran fine as a reminder and a local script for years. But the rest of the company has a release process that they like. We just integrate to it. Our service has a name in that space, ressources, a schedule that other engineers can read. Our description looks a little… film-school-credit-rolly because my name appears as the lead, architect, project, emergency contact, etc. I think the main oversight of those “you don’t need k8s” is that most projects are part of a system and fitting in that system gives you legibility to your peers that a nginx might not.
- p_l 7y ago
  I have ~62 apps (that's applications, not instances) deployed on kubernetes right now, for single client. It started out on 2 VMs with I think 2-4 cpus, already running kubernetes. The actual containers inside ran lighttpd and served static files while we fixed up the sites that we have mirrored as static to run in containers. If we had to run one, or maybe few of those sites, it would have been easy to run a single Apache + mod_php + vhost. We would have some annoying work to do on monitoring and logging side. But we have 62. Some of them are mutually incompatible to run on "standard" distro, as they have mutually exclusive dependencies (for example, PHP versions). This meant we ended up with containers to manage this in somewhat doable way (we are two people). We can't expend manpower to do a complete redo of the apps, though we have ideas on that (to go to single common CMS system for all of them). K8s saved our sanity. Because those "simple apps" altogether made for hard to manage setup, and the client doesn't like when they are not available, so we brought up HA as well. Doing this as separate VMs would be hard and expensive. Doing it on Heroku is expensive - I made a calculation, and our original setup would result in somewhere around ~1800 USD a month. Our 2016-2017 spend on GCP (GKE, Cloud SQL, a VM to host Gitlab + network traffic and DNS) was around 1000/month.
  - earthboundkid 7y ago
    Do they need to be 62 though? Without having looked, my ignorant guess is that it could be reduced by an order of magnitude, it's just that doing so would take time that no one has, so the simpler choice is just to shovel the complexity into K8 instead of dealing with the complexity of reducing the number of apps.

FlyingSnake 7y ago

> But nobody does that anyway. Please speak for yourself. In my experience, most of the software that's written using k8s/µServices could've been written using a simple Flask+Nginx+monitoring on a DO Droplet. K8s and the extra overhead leads to extra efforts in developement and testing, and many software teams are perennially behind schedule on delivering features. There are ways to achieve fault tolerence without tying in to the complex ecosystem of K8s.

vincnetas 7y ago

"But nobody does that anyway." You'd be surprised, but they do. EDIT. I work at company with < 5 devs and we are in progress of moving our services to k8s. Will se how it goes.

onion2k 7y ago

Practically every SaaS business could be built as a single application or a set of services, especially at the beginning when all the traffic could be handled on one server. So whether or not k8s is appropriate isn't driven by your business's complexity but rather by your architecture choices. Choosing to build microservices is what adds complexity and makes tools like k8s necessary, not the business. That complexity can be useful. It can mean you don't need to build a simple version and a more scalable version later. It means you can replace parts as the business grows rather than the entire thing. You can outsource or buy some services. These are benefits, but they are also choices, and all of them increase the time it takes to get to market. In a very well funded startup that has years of runway sometimes choosing microservices makes sense. In most small startups that are just proving their model they'd be much better off hacking something together that they'll throw away later in order to validate the business idea. Finding out that your business doesn't work as a business is far more useful than building something that can scale just in case it does. The real difficulty in that is accepting that the idea you have might not actually work.

bertil 7y ago

We have a possible counter-example: our service is computing AB-test results (essentially reading from a database, processing totals, writing significance back). It have no non-system users, no dependencies, etc. All the test and strangeness is handled internally. We use k8s which is indeed over-engineered — it ran fine as a reminder and a local script for years. But the rest of the company has a release process that they like. We just integrate to it. Our service has a name in that space, ressources, a schedule that other engineers can read. Our description looks a little… film-school-credit-rolly because my name appears as the lead, architect, project, emergency contact, etc. I think the main oversight of those “you don’t need k8s” is that most projects are part of a system and fitting in that system gives you legibility to your peers that a nginx might not.

p_l 7y ago
I have ~62 apps (that's applications, not instances) deployed on kubernetes right now, for single client. It started out on 2 VMs with I think 2-4 cpus, already running kubernetes. The actual containers inside ran lighttpd and served static files while we fixed up the sites that we have mirrored as static to run in containers. If we had to run one, or maybe few of those sites, it would have been easy to run a single Apache + mod_php + vhost. We would have some annoying work to do on monitoring and logging side. But we have 62. Some of them are mutually incompatible to run on "standard" distro, as they have mutually exclusive dependencies (for example, PHP versions). This meant we ended up with containers to manage this in somewhat doable way (we are two people). We can't expend manpower to do a complete redo of the apps, though we have ideas on that (to go to single common CMS system for all of them). K8s saved our sanity. Because those "simple apps" altogether made for hard to manage setup, and the client doesn't like when they are not available, so we brought up HA as well. Doing this as separate VMs would be hard and expensive. Doing it on Heroku is expensive - I made a calculation, and our original setup would result in somewhere around ~1800 USD a month. Our 2016-2017 spend on GCP (GKE, Cloud SQL, a VM to host Gitlab + network traffic and DNS) was around 1000/month.
- earthboundkid 7y ago
  Do they need to be 62 though? Without having looked, my ignorant guess is that it could be reduced by an order of magnitude, it's just that doing so would take time that no one has, so the simpler choice is just to shovel the complexity into K8 instead of dealing with the complexity of reducing the number of apps.