I would argue that small to medium web services don’t need Kubernetes nor serverless. It doesn’t even need to be split into services. Build a tidy monolith and see how far that takes you first. Have less moving parts.
Yes, serveless ties you in to platform specifics but in their nature the functions you create should be small and easy to reimplement elsewhere.
Kubernetes on the other hand is arguably also a certain lock-in, by virtue of being complicated. No wonder vendors love it, it’s an offering that is hard to do right in-house. And when Kubernetes releases updates only the most seasoned in-house teams will be able to keep up. It creates job security by being a lot to learn and manage. Yes there are good abstractions but when something breaks you’ll need to delve into that complexity below. (Makes me think of ORM abstractions vs SQL.)
Yes, Kubernetes is an awesome vehicle for orchestrating a swarm of containerized services. But when you’re not Netflix or Twitter scale it’s ridiculous to worship this complexity.
Frankly I keep coming back to appreciate Heroku's abstractions and its twelve factor app philosophy https://12factor.net/. Heroku runs on AWS but feels like a different world than AWS to develop on. I can actually get projects flying with a 2-3 person team me included.
Actually 'serverless' is where small shops might want to start.
A single Lambda can encompass a whole variety of functions, and if you're using a datastore that scales as well, you don't need to worry about much. Once it's set up, it should be very easy to monitor and change.
I'd rather a simple Lambda than managing a couple of EC2's with failover scenarios and the front end networking pieces for that.
Also small scale is where lambda really shines in terms of costs. If you have some api endpoint that gets a hit 100 times per hour and does some execution then this is actually way cheaper then even the cheapest ec2 instance in a production setup with ELB.
There's a world of organizations between Netflix and Twitter scale and small startups with 2-3 person infrastructure teams in which Kubernetes makes good sense.
At some point, it becomes cost effective to have a two-pizza team of engineers dedicated to it. Once an org hits that level, then the scale that can be achieved with Kubernetes is pretty immense.
I'm using k8s for a side project on Digital Ocean. I'm familiar with k8s, and deployment and maintenance are easy. The only devops I've gotten into so far is setting up DNS for the external load balancer. I think people are mistaken when they say k8s is too complex for the smallest apps.
Yes, serveless ties you in to platform specifics but in their nature the functions you create should be small and easy to reimplement elsewhere.
Kubernetes on the other hand is arguably also a certain lock-in, by virtue of being complicated. No wonder vendors love it, it’s an offering that is hard to do right in-house. And when Kubernetes releases updates only the most seasoned in-house teams will be able to keep up. It creates job security by being a lot to learn and manage. Yes there are good abstractions but when something breaks you’ll need to delve into that complexity below. (Makes me think of ORM abstractions vs SQL.)
Yes, Kubernetes is an awesome vehicle for orchestrating a swarm of containerized services. But when you’re not Netflix or Twitter scale it’s ridiculous to worship this complexity.
Frankly I keep coming back to appreciate Heroku's abstractions and its twelve factor app philosophy https://12factor.net/. Heroku runs on AWS but feels like a different world than AWS to develop on. I can actually get projects flying with a 2-3 person team me included.