greptimedb VS pipeline

GreptimeAI, built upon the open-source time-series database GreptimeDB, offers an observability solution for Large Language Model (LLM) applications, currently supporting both LangChain and OpenAI's ecosystem. GreptimeAI enables you to understand cost, performance, traffic and security aspects in real-time, helping teams enhance the reliability of LLM applications.

Continuing to work hard on a new MetricEngine in GreptimeDB. BTW, If you have a keen interest in Rust or database development, GreptimeDB might be a good starting point. Check it out for some good first issues here.

Since the very first day of GreptimeDB going open-source, it embraced the automated software building process with GitHub Actions, and leading to the inaugural Release Pipeline.

Born from the open-source project GreptimeDB, GreptimeCloud serves as a fully-managed, serverless cloud backend for Prometheus, offering integrated support for remote read/write protocols and PromQL as one of our primary query languages.

Recently, while working on our GreptimeDB project, we encountered an issue with calling asynchronous Rust code in a synchronous context.

To explore data stored in GreptimeDB through PromQL, GreptimeDB needs to provide the ability to parse the query into AST (abstract syntax tree), and retrieve data from memory or disk via logical and physical plans. Since there is no ready-to-use PromQL Rust Parser, our team decides to develop it by ourselves. We’re glad to announce that promql-parser v0.1.0 is now available.

This is truly a fantastic combination -- implement the logic in Rust and use it in Python. GreptimeDB also implements a similar functionality that allows writing Python script to do post-process of SQL query results, with the help of RustPython and Arrow. Maybe this combination can bring a sweet point between performance and efficiency.

docs: https://docs.greptime.com/user-guide/coprocessor-and-scripti...

code: https://github.com/GreptimeTeam/greptimedb/tree/develop/src/...

Tekton

Tekton is an open-source framework for creating efficient CI/CD systems. This empowers developers to seamlessly construct, test, and deploy applications across various cloud environments and on-premise setups.

Despite other alternatives like Circle CI, Travis CI, GitLab CI or even self-hosted options using open-source projects like Tekton or Argo Workflow, the reason for choosing GitHub Actions was straightforward: GitHub Actions, in conjunction with the GitHub ecosystem, offers a user-friendly experience and access to a rich software marketplace.

[2]: https://github.com/tektoncd/pipeline/issues/5507#issuecommen...

Drone, or Tekton, Argo Workflows if you’re on k8s

If you want a step up, I would recommend trying out Tekton Pipelines. It’s a very popular ci tool, and it runs on Kubernetes. Yes, this would involve setting up a Kubernetes cluster but please don’t run for the hills! You can setup a Kubernetes cluster and install Tekton on top of it with minimal setup using minikube (see here. This would be a great joint exercise as it will give you a bit of Kubernetes understanding alongside it, and the mechanisms of Tekton are a little trickier than GitHub actions imo. It’s all much the same though.

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?