wg-serverless VS testkube

Check out CNCF Projects. Contributing to some of these open source projects is a great way to gain skills and land a job.

would indicate if your cluster could retrieve content from cncf.io or if cncf.io is up.

This solution builds upon well-established Cloud Native Computing Foundation (CNCF) open source projects like Thanos and Prometheus,together with a new managed services, Azure Managed Grafana, recently released in public preview. It allows for ephemeral clusters to still have updated metrics without the 2-hours local storage of metrics in the classic deployment of Thanos sidecar to Prometheus.

Not ELI5 but see https://github.com/cncf/wg-serverless/tree/master/whitepaper...

Some people go monolithic app but best practice is usually one function per route.

Traditional servers come with management overhead (e.g. defining/managing/monitoring scaling) and by using Serverless servers you avoid that overhead and optimize for good engineers which are almost always your bigger cost center.

github.com/cncf/wg-serverless/blob/master/w..

As stated in a white paper by the CNCF serverless working group, there are two primary serverless personas:

The CloudEvents specification is under the CNCF Serverless working group since 2018. The spec's purpose is describing event data in a common way. This is useful in many scenarios, for example, routing events to the appropriate subscribers depending on the type of the event. Since applications can use a lot of different transports to send and receive events, the CloudEvents spec is protocol-agnostic so it defines protocol bindings in order for the metadata to be correctly mapped for HTTP, AMQP, Kafka, etc.

Testkube is an open-source project, part of the CNCF landscape, and testing framework designed for testers and developers who use Kubernetes. It integrates test orchestration and execution into Kubernetes and your CI/CD/GitOps pipeline. You can automate the execution of your tests, regardless of the testing framework, by using Testkube's executors or creating your own.

For tips from other DevOps and GitOps enthusiasts, check out our active Discord or find our entire open source project on GitHub! We’re also on Twitter (@testkube_io), where we’re always sharing the latest news in our journey to become the most complete and beloved Kubernetes-native testing framework.

With Testkube, you would do it by:

Download the latest release on GitHub

If you’re interested in the code of our test, feel free to check it here (just import file as Postman collection) it’s just exported Postman collections JSON file that tests against our Testkube API defined in OpenAPI spec

TestKube documentation

What runs the tests is something called executors, currently the project already has Cypress, Postman & k6 executors and it's very easy to write new ones. You can open a github issue asking for a new executor that you would like to have (or you can also contribute it yourself if you are into that 😋)

Currently in all projects on which I'm working on using REST-based API defined by OpenAPI spec v3. It feels natural and widely adopted in all communities. The project is open-source (kubeshop/testkube) and the main goal is to simplify testing in the Kubernetes world - where RESTful APIs (probably) is the first technology that comes to your mind when starting such a project.