helm-charts VS pack

The go to solution for a k8s monitoring setup is https://github.com/prometheus-community/helm-charts/tree/mai...

That's why Kube-Prometheus-Stack was created. It installs a collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules, providing an easy-to-operate, end-to-end Kubernetes cluster monitoring solution with Prometheus using the Prometheus Operator.

Step 1: Installing Kube-prometheus-stack

Kubernetes Documentation: https://kubernetes.io/docs/home/ Kubernetes Tutorials: https://kubernetes.io/docs/tutorials/ Kubernetes Community: https://kubernetes.io/community/ Prometheus: https://prometheus.io/ Grafana: https://grafana.com/ Elasticsearch: https://www.elastic.co/elasticsearch/ Kibana: https://www.elastic.co/kibana Helm: https://helm.sh/ Prometheus Helm Chart: https://github.com/prometheus-community/helm-charts/tree/main/prometheus Grafana Helm Chart: https://github.com/grafana/helm-charts/tree/main/grafana Elasticsearch Helm Chart: https://github.com/elastic/helm-charts/tree/main/elasticsearch Kibana Helm Chart: https://github.com/elastic/helm-charts/tree/main/kibana RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/ StatefulSets: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ DaemonSets: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/ Taints and Tolerations: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Custom Resource Definitions (CRDs): https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ Operators: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

Installation example for prometheus:

Prometheus can be deployed using the Prometheus Helm Chart. This helm chart contains a lot of features such as the already mentioned Push Gateway, Alert Manager and so on. For simplicity reasons of this tutorial I will not show all the Helm chart configuration but you can see a real example used by me here.

Building upon Bartłomiej Płotka's insightful blog on Prometheus and its passthrough agent mode, this post dives into implementing multi-cluster Prometheus support. Notably, the official inclusion of support in the widely-used kube-prometheus-stack came with the release in July 2023, making it easier to extend Prometheus monitoring across clusters.

The first thing you'll need, of course, is at least one backend to store metrics. So install Prometheus now:

The other way to run a containerized app on GCR is to not use Docker explicitly. If the Dockerfile is missing, Cloud Build uses Buildpacks, a tool built on open standards that automatically inspects application files and dynamically determines the best way to build & containerize apps. This is clearly the option for those new to Docker, don't know Docker, want to avoid Docker, or don't even think about containers. More specifically, Buildpacks adopted by Google is how images can be built & deployed on GCR without Docker.

What if I tell you that you can create a Docker image without creating a Dockerfile? We can build docker images directly from the Gralde or Maven plugin using Cloud Native Buildpacks. Some platforms (like Heroku or Cloud Foundry) use Buildpacks to convert provided jar files into runnable images.

Docker containers do not fit perfectly into ensuring the secure development of your AI project because they cannot track the model and data lifecycle. However, you can use other container-based technology tools like Buildpacks or KitOps to package your AI project and transform it into container images or open container initiative (OCI) artifacts.

Part of a platform engineering strategy is assembling a bunch of bricks to provide a well-rounded developer experience. In this article, I will explore how packaging applications using open-source Cloud Native Buildpacks can become a core element of that platform engineering toolkit by offering advanced application packaging features. Let's dive in!

For example, with BuildPacks developers don't even need to make a Dockerfile anymore. When integrated into a GitOps pipeline, serverless development becomes a breeze.

I've recently found this quote by Kelsey Hightower:

"I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them."

Source: https://twitter.com/kelseyhightower/status/85193508753294540...

In the last few weeks, I've experimented a bit with Flux (https://fluxcd.io/), Tekton (https://tekton.dev/) and Cloud Native Buildpacks (https://buildpacks.io/) on how to provide K8s powered git push deployments without using a dedicated CI/CD server.

My project is still in early alpha stage and just a proof of concept :-) My vision is to expand it into an Open Source PaaS in the future.

Do you think the above quote is true? What does an open source PaaS need to be like in order to be accepted by software developers?

Some other projects have been discontinued in the past (like Flynn or Deis) or were created before the Kubernetes era.

Is it the right direction to provide a Heroku like solution based on K8s or is it better to provide an Open Source Infrastructure as Code library with building blocks to avoid everything from scratch?