31–40 of 180 posts
Once that feels too little, I would start looking at docker, and only when docker feels again too little, to kubernetes.
So in essence, for 95% of the apps/people, the answer is no.
It all started with Ruby. Ruby's syntactic sugar inspired the "syntactic sugar" of tooling, primarily Bundler and Rspec. Tooling, for what felt like the first time, became a first class citizen. Ruby's tooling made Heroku possible: ie, reproducible builds across; dev, testing, staging and production environments. Heroku's success was based on the primitives of the Twelve-Factor App[1]. The 12 factors (and therefore Heroku) were fundamentally designed around the already-old lightweight virtualisation technology of LXC. The success of Heroku paved the way for Docker. The success of Docker created the world in which Kubernetes makes sense.
To be blunt: if you don't understand the relevance of Kubernetes, or whether it's relevant to you, you don't understand the benefits of the 12 factors in their broadest sense. The 12 factors are much, much more than just "How To Deploy On Heroku".
Copypasting the 12 factors:
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
No
Exactly! Betteridge’s law of headlines: Any headline that ends in a question mark can be answered by the word no. ⌘ https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
As somebody who's pretty skeptical about onboarding the big lump of complexity that is k8s, I really appreciated the information in the article.
I work for a startup whose product is small (half a dozen servers, if relatively beefy ones) clusters that will be run on-prem by customers, at least sometimes in a low-to-no-touch capacity. Most of our application components are micro-ish services that are run on all hosts in the cluster for either extra capacity or fault tolerance. We currently run everything on mesos/marathon, but are looking to switch away from i…
For small apps and projects that continuous delivery is not required I would start with lxd. I think it's the easiest way to containerize an app. Once that feels too little, I would start looking at docker, and only when docker feels again too little, to kubernetes. So in essence, for 95% of the apps/people, the answer is no.
Here's a quick reference: 1) Are you on AWS? Then you don't need Kubernetes. Use Fargate. 2) Are you on Google Cloud? Then you don't need Kubernetes. Use Cloud Run. 3) Are you on Azure? Then you don't need Kubernetes. Use Azure Container Instances. 4) Are you on a PaaS like Heroku? Then you don't need Kubernetes. 5) Are you on a random VPC provider / bare metal machines? You could probably still do without Kubernetes…
Also at this point there is a ton of stuff out there that assumes you are deploying to kubernetes and makes that the path of least resistance.
Not a single mention of elastic beanstalk or App Engine? The best middle ground for small teams who just want one reliable website with minimal scaling (and who can't just choose a nom-aws service).
I work for a startup whose product is small (half a dozen servers, if relatively beefy ones) clusters that will be run on-prem by customers, at least sometimes in a low-to-no-touch capacity. Most of our application components are micro-ish services that are run on all hosts in the cluster for either extra capacity or fault tolerance. We currently run everything on mesos/marathon, but are looking to switch away from i…
It helps abstract out everything in the stack below your app and easier conceptually on everybody; now the clients can train in k8s and use same set of tooling like prometheus/grafana etc that usually go with k8s, same or similar RBAC access etc.
OTOH realistic expectations need to be set; not because it's k8s there's going to be no problems or the learning/adaptation won't come without some pain. I suggest writing down some standard procedures for your clients like upgrades etc, pick same set of tooling for all of them (like same dashboard, same logging/monitoring/alerting etc) as a way to homeganize ("standardize") all of them.
Feel free to email me.
Earlier quoted context omitted.
I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.
Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'…
Here's a quick reference: 1) Are you on AWS? Then you don't need Kubernetes. Use Fargate. 2) Are you on Google Cloud? Then you don't need Kubernetes. Use Cloud Run. 3) Are you on Azure? Then you don't need Kubernetes. Use Azure Container Instances. 4) Are you on a PaaS like Heroku? Then you don't need Kubernetes. 5) Are you on a random VPC provider / bare metal machines? You could probably still do without Kubernetes…