OpenFaaS VS docker-swarm-autoscaler

Serverless functions are now offered by many cloud providers, as well as having options like OpenFaaS, Knative, Apache's Openwhisk and more from the open source community that run in environments ranging from one server all the way up to globally replicated private clusters.

OpenFaaS

Did you consider running knative or openfaas? https://github.com/openfaas/faas

Anyone knows other alternatives for Azure Functions, but for DIY hosting? ( eg. OpenFaas - https://www.openfaas.com/ )

Maybe OpenFaaS with grafana and slack notifications for non-200 responses?

OpenFaaS - https://www.openfaas.com

By the way, if your organization is leveraging EKS as a platform and your DevOps team is willing to enable this operator, there's an exciting tool called OpenFaaS. Essentially, it enables you to host your Lambda functions on your own infrastructure instead of relying on the public cloud provider.

This is where I see K8S coming in – teachers can provide dev deployments that are setup for students to learn. Teachers can also provide containers that run automated tests against the student containers for assessment! Plus, we can smooth over some of the git workflow stuff for the ripest of beginners; we can integrate with github to sync their work on our platform to repositories on their github account, so that they can really take ownership of the work they do on the platform. Last, students can graduate their work from development into production very easily, since we can take the base images + student diffs, build a new "prod" image for the student. We can run students' prod work on "serverless" K8S frameworks like fission or OpenFaas to be able to host many low-traffic "production" apps at the same time.

If you want to have some sort of auto scaling, you will need to monitor to some extent though as this will be the signal for scaling up/down. I noticed that https://github.com/jcwimer/docker-swarm-autoscaler already includes the relevant prometheus configs required for just scaling by cpu.

Nomad, Docker Swarm and other solutions support most of these out of the box, Kubernetes is just the most popular and flexible (with which comes a lot of complexity) solution, it seems.

For example, even something as basic as Docker Swarm will see you a lot of the way through.

> How do you implement healthcheck?

Supported by Docker: https://docs.docker.com/engine/reference/builder/#healthchec...

> Does the loadbalancer know how the healthceck is implemented?

When the health checks pass in accordance with the above config, the container state will change from "starting" to "healthy" and traffic will be able to be routed to it. Until then you can have a web server or whatever show a different page/implement circuit breaking or whatever.

> How do you determine it's time to scale?

Docker Swarm doesn't have an abstraction for autoscaling, though there are a few community projects. One can feasibly even write something like that themselves in an evening: https://github.com/jcwimer/docker-swarm-autoscaler

That said, I mostly ignore this concern because I'm yet to see a workload that needs to dynamically scale in any number of private or government projects that I've worked on. Most of the time people want predictable infrastructure and being able to deal with backpressure (e.g. message queue), though that's different with startups.

> How do you implement always-on-process? service unit, initd, cron?

The service abstraction comes out of the box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/se...

You might also want to decide how to best schedule it: wherever available, on a particular node (hostname/tag/...) or on all nodes, which is actually what Portainer agent does! Example: https://docs.portainer.io/start/install/server/swarm/linux

> How do you export the logs?

Docker supports multiple logging drivers: https://docs.docker.com/config/containers/logging/configure/

> How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config?

Docker and Compose/Swarm support environment variables: https://docs.docker.com/compose/compose-file/#environment

If you need config files, you can also use bind mounts: https://docs.docker.com/storage/bind-mounts/

> What about secrets?

Docker supports secrets out of the box: https://docs.docker.com/engine/swarm/secrets/

> Service discovery? Is unbound/bind9?

Docker Swarm supports built in DNS, even allows for multiple separate networks: https://docs.docker.com/engine/swarm/networking/

> These items are best done in a standard way.

Agreed! Though I'd say that the only two options being "running everything on *nix directly" and "running everything in Kubernetes" is a false narrative! The former can work but can also lead to non-standard and error-prone environments with a horrible waste of human resources, whereas the latter can work but can also lead to overcomplicated and hard to debug environments with a horrible waste of human resources.

The best path for many folk probably lies somewhere in the middle, with Nomad/Swarm/Compose/Docker, regardless of what others might claim. The best path for folks interested in a DevOps career is probably running on cloud managed Kubernetes clusters and just using their APIs to lots of great results, not caring about how expensive that is or how easy it would be to self-host on-prem.