Taming your application’s environments Marcos & Mauricio https://github.com/salaboy/kubecon-2024-na

Intro + Agenda - What is an environment? - Making your applications cross-environment - Delivering unified user experience that works in all environments

Before we start… Application Development Working Group Survey

What is an environment?

Are these environments? - Is my local machine an environment? - Is Docker Compose an environment? - Is my KIND Cluster an environment? - Is that VM over there an environment? - Is that CI pipeline an environment? - Is a Pull Request an environment?

Yes, maybe? 😐

The app running locally

A CI Pipeline running the app

The app running on Kubernetes

What do all these environments share in common? - Must provide an application runtime - Must provide all the application infrastructure required by our apps - Someone must configure all this infrastructure - Orchestrate their lifecycle (create, deploy, tear-down, etc) - No matter the shape or size, how can we simplify the experience when interacting with these environments??

Let’s ask to an LLM… - Create a workflow to build, test and package a Java application in a Container that needs to work locally, in CI and in a Kubernetes cluster. - Tons of non-reusable boilerplate - Hard to verify the output correctness (hallucinations) - Mix of new and outdated practices - LLM’s are not good at creating abstractions (yet).

Making your applications cross-environment with … APIs

24k GitHub Stars 7.7k Discord Users 1M Pulls/month 3.7k Contributors 14/173 CNCF Projects 300k Doc views/month

Runtime freedom with Dapr

Dapr -> Runtime independence from the env

Dapr -> Runtime independence from the env

APIs to decouple our cloud native apps from envs - Dapr exposes a set of high-level APIs that decouple infrastructure and common cloud native challenges from applications - This enables resiliency and observability out of the box for our apps - Environments can be configured uniformly for local, remote and CI pipelines

Delivering unified user experience that works in all environments

Software delivery process

Software delivery process - Push and pray 🙏 - One toolchain per team 🔧 - It works in Dev, why is CI failing? 😐

Today’s CI/CD problems… …look a lot like old application problems

Software delivery process DAGGER DAGGER

Dagger 101 FROM golang:1.19 as build WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY *.go ./ RUN CGO_ENABLED=0 GOOS=linux go build -o /app EXPOSE 8080 CMD ["/app"] Dagger Dockerfile func Build(src *dagger.Directory) *dagger.Container { return dag.Container().From("golang:1.19"). WithWorkdir("/app"). WithDirectory(".", src, Include: []string{"go.mod", "go.sum"}). WithExec([]string{"go", "mod", "download"}). WithDirectory(".", src). WithEnvVariable("CGO_ENABLED", "0"). WithEnvVariable("GOOS", "linux"). WithExec([]string{"go", "build", "-o", "/app"}). WithDefaultArgs([]string{"/app"}) }

Dagger 101 Dagger factory test: docker compose up -d ./wait-for-everything-ready.sh - DB_URL=localhost:5432 go test \ -coverprofile cover.out ./... ./more-scripts-to-handle-report.sh Makefile factory func (m *Module) Test() *myorg.AppTestResult { report, error:= m.Base(). WithServiceBinding(“db” dag.Postgres()). WithEnvVariable(“DB_URL”, “db:5432”). WithExec([]string{“go”, “test”, “-coverprofile”, “cover.out”, “./..."). File(“cover.out”) return &myorg.AppTestResult { Report: report Error: err } }

Demo

Takeaways - Environments can take very different shapes and forms - Think about APIs and interfaces, that will allow to design your factory and applications better - Software Delivery pipelines are applications, treat them as such - Adapt the tools to your needs, not the other way around - Have fun while building, it’s ok to brag a bit about it.

Thanks! https://github.com/salaboy/kubecon-2024-na Marcos Lilljedahl @marcosnils @dagger_io https://dagger.io. (Booth #Q18) Mauricio Salatino @salaboy @daprdev https://dapr.io (Booth #R14)