[speedplane]

> I've finished constructing a small repository which runs the following in order to setup a cluster: Bazel, Terraform, Packer, Ansible (which'll run `kubeadm init`), Docker, Kubernetes, Openssl, Jsonnet.

It's pretty sad that in 2019, to setup a web app that can properly scale you need to understand and use so many technologies. Developing a scalable website in 2013 was a lot easier than in 2019. Back then PaaS was all the rage (Heroku, Google App Engine, Amazon Elastic Beanstalk). Since then, things have gotten much harder.

I suspect that this development has less to do with technical challenges and more to do with revenue. Cloud providers now provide all of these services, and they make little money getting small folks up and running with something that "just works". The real money is going after enterprise clients that need to tweak every detail and have the resources to devote to all of these technologies.

There have been so many platforms and libraries that have come out over the past 10 years, the industry is more than ready for a period of consolidation.

[journalctl]

Except you need approximately zero of those things (especially Bazel. Jesus, who would pull in Bazel for this?) To run a website in 2019, you need:

1. Server 2. nginx 3. A certificate 4. DNS

The vast majority of people don’t actually need to scale at all. I got HN hugged once and my little Digital Ocean droplet with nginx performed just fine. Granted, it was a static site. But scalability is one of those things that everyone says they want, but probably don’t actually need (or haven’t really profiled to see if scaling horizontally would help).

I’ve been burned too much by devs using Docker and Kubernetes and all of this other nonsense just to host basic web backends, because I’m always the one who has to clean up the mess when it shits the bed. Web hosting needn’t be difficult, but we keep making it difficult.

[speedplane]

> To run a website in 2019, you need: 1. Server 2. nginx 3. A certificate 4. DNS

I wasn't talking about building a static website, I was talking about building a scalable web app. You can start a project as a hobby, but if you every hope to dream of doing something larger, you should at very least consider a path to expansion. This shouldn't mean jumping into Docker and Kubernetes, which are pretty complex. There should be platforms that handle database and instance scaling automatically. When you start off, you only need one or two instances, and as you grow, new instances get automatically added.

Back in the old days of 2013, this was super easy, no Dockerfile or Kubernetes yaml files were needed. Now, you need to configure every single tiny variable for every operation. This is great for large enterprises, but miserable for small companies that want to get started.

[outime]

>It's pretty sad that in 2019, to setup a web app that can properly scale you need to understand and use so many technologies. Developing a scalable website in 2013 was a lot easier than in 2019. Back then PaaS was all the rage (Heroku, Google App Engine, Amazon Elastic Beanstalk). Since then, things have gotten much harder.

Is there anything stopping you from using these? Because they're well maintained and even better than before. In fact, many companies and individuals are still using them. And if you have different needs, it's good that there are more flexible alternatives, no?

[OzzyB]

I get your point, but your looking at it backwards now, we're past the days of PaaS because we now know were it all leads: lock in -- and I say this as an early adopter of GAE and watched it turn from "something that does all you need out of the box to run an app" to something that nickel and dimes you at every turn and then presents you with a nice fat $bill if you do anything serious on the platform (just look at the bandwidth charges ffs!).

If by lock-in that means higher margins for these major cloud providers then the only remedy is to have a free market, and the only way to achieve that is for us to have the ability (or at least the threat) to take our stuff and run.

In short, the word is out now that there is no "free cloud lunch" they're making $billions off of us for what we once called hosting (clever trick!). Yes, we want the promise of "Cloud" but not all of us are SnapChat and/or willing to pay the high premium for it.

[speedplane]

> I get your point, but your looking at it backwards now, we're past the days of PaaS because we now know were it all leads: lock in ... I say this as an early adopter of GAE and watched it turn from "something that does all you need out of the box to run an app" to something that nickel and dimes you

Lock-in is fine when you're small, it only becomes problematic when you're big. PaaS platforms are not well suited for big organizations for precisely this reason. However, they're great for trying out something new quickly and having it scale without thinking about it. But Google (and others), realized the real money is not in startups wanting a PaaS platform, but in large enterprises, which are far more sensitive to lock-in.

In the ideal world, they'd provide systems like GAE and make it easy to later convert each service (e.g., database, memcache, tasks, email) to a finely tuned system.

[tybit]

It seems to vary based on your tech stack. I’ve found the serverless framework with Lambda to be quite straight forward.

[speedplane]

> I’ve found the serverless framework with Lambda to be quite straight forward.

Lambdas are great, and they do borrow much from the ideals of PaaS, including the lack of load balancing or HTTP servers. However, there are so many other extremely common services that Lambdas don't cover, for example: email, background tasks, memcache, databases, search engines, security, and so much more. Nearly every web app needs all of these services, but no one is building a single platform that does all of these things decently well out of the box. Instead, you're pushed towards using a different tool for each one. These custom tools certainly offer more power and control, but having to go chase and evaluate each one is a huge road-block for smaller projects that just want to get off the ground.

[researchiteng]

We also think the future directions are Serverless (Knative based) and Istio. They can be added using their helm charts either post install or via the addons.yaml The idea of this project is to prepare the k8s base for deploying either of them quickly, building on top.