The decision gets interesting when you ask a different question: who holds the environment, and who does it answer to? Bunnyshell delivers environments to you as a service from its own cloud. Okteto gives you an environment platform that lives inside your infrastructure. That single difference propagates into where your configuration is stored, what access your cluster has to grant, how the platform bills you, and what happens when AI agents start asking for environments too. This guide walks through it.

Understanding the Shared Challenge​

Modern cloud-native development is complex. Your applications aren't just code anymore. They're code plus configuration, runtime dependencies, network policies, secrets, and interactions across dozens of microservices. Developers can't gain real confidence that their changes work by running unit tests on a laptop. They need access to realistic environments that reflect production complexity.

Both Okteto and Bunnyshell recognize this challenge, and both were built to end the queue for a shared staging environment. Bunnyshell's own documentation opens on exactly that pain: only one engineer at a time can deploy to staging, so everyone else waits or competes for access. That is a real problem, and it is worth solving.

The two platforms diverge on where the solution should live. That is the part worth understanding before you commit.

How Bunnyshell Works​

Bunnyshell describes itself as an Environments as a Service platform. You connect a Kubernetes cluster and a Git provider, and Bunnyshell orchestrates full-stack environments inside your cluster on demand or automatically from pull requests.

The model is genuinely capable. You define an environment as a set of components, and those components can come from Docker Compose files, Helm charts, raw Kubernetes manifests, Terraform modules, prebuilt Docker images, or your own scripts. First-class Terraform components are a real strength if your environments include cloud resources alongside containers. Container images build inside a Kubernetes cluster using Kaniko or BuildKit, either yours or one Bunnyshell manages. Dependencies between components are declared with dependsOn, and anything without a dependency deploys in parallel. Bunnyshell installs webhooks in your Git provider, so opening a pull request clones a designated primary environment with the branch swapped, and closing or merging the pull request destroys it. Git ChatOps lets developers drive environments from pull request comments, which is a nice touch we do not have an equivalent for.

The architectural detail that matters most is how Bunnyshell reaches your cluster. It connects from the outside, to your Kubernetes API server, using credentials you provide. Its documentation is direct about the consequence: clusters "need to either be publicly exposed, or have Bunnyshell IPs whitelisted." Its guidance for private and air-gapped clusters says the same thing, and states plainly that without API access, Bunnyshell cannot create, monitor, or destroy environments. The environment definition itself, bunnyshell.yaml, is held by the platform rather than your repository. Their docs note it is stored "for now" exclusively in Bunnyshell.

For teams whose main pain is the staging queue, and whose clusters can accept an external control plane, this is a coherent and well-built answer.

How Okteto Works​

Okteto starts from a different premise: the environment platform should be a component of your infrastructure, not a service that reaches into it.

You install Okteto inside your own Kubernetes cluster with our Helm chart, or you run it as Bring Your Own Cloud, where we operate the platform inside your cloud account while you keep ownership of the account and the data. Nothing outside your perimeter needs a route to your Kubernetes API. Air-gapped installation is documented end to end, including mirroring the platform and CLI images into your private registry and disabling telemetry, so a cluster with no internet access at all can still run the full platform.

Your environment definition, okteto.yaml, is a file in your repository. That is not a filing detail. It means environment changes arrive as pull requests, get reviewed, carry history, and roll back like any other code. It also means one definition serves every consumer: the CLI a developer runs, the Preview Environment built for a pull request, the test containers okteto test executes, and the AI agent working on a ticket all read the same file.

That manifest sits on top of what you already have rather than replacing it. Okteto implements and extends the Compose Specification, so a docker-compose.yaml deploys to Kubernetes as written, and Helm charts and raw Kubernetes manifests work the same way. For the parts of your stack that are not containers, the manifest's external section pulls cloud resources into the environment, so an RDS database, an S3 bucket, a Lambda function or a LaunchDarkly environment is created alongside it, shown in the dashboard, garbage-collected with it, and torn down by okteto destroy. Provisioning tooling stays your choice, because deploy commands run whatever you point them at, Terraform included. And since those commands can run remotely, your developers do not need Helm, kubectl or Terraform installed locally at all.

Okteto is also built on the premise that different environment types exist to serve different workflows, and a platform should be optimized for each workflow's specific job.

Dev Environments are optimized for iteration speed. File sync and live updates, hot reload, remote debugging, port forwarding for IDE integration, hybrid mode for running one service locally against the rest in the cluster, and Volume Snapshots, which seed a new environment's database from a snapshot of real staging or production data, so dev and preview environments come up populated instead of empty.

Preview Environments are optimized for collaboration and validation, with auto-deploy on pull requests, shareable URLs, and automatic cleanup. The job is letting PMs, designers, QA, and stakeholders validate a change with no technical setup.

Test Environments are optimized for consistency. Okteto Test runs unit, integration, and end-to-end tests inside the cluster rather than on a separate CI virtual machine, with the same runtime as production and access to private services.

Agent Environments give AI coding agents the same isolated, production-like environment a developer gets, driven by the same CLI and manifest, so an agent can deploy its change, run the tests, hit the live endpoints, and read the logs before a human reviews anything.

Quick Comparison​

Eight differences that decide most evaluations. The rest of this guide explains why each one matters.

• Stack support: both read Docker Compose, Helm charts and Kubernetes manifests. Bunnyshell adds a declarative Terraform component type, which Okteto does not have; with Okteto you run Terraform from a deploy command and register what it creates in the manifest's external section.
• Where the platform runs: Okteto installs inside your infrastructure, Self-Hosted or BYOC. Bunnyshell runs an external control plane that needs to reach your Kubernetes API, or your cluster whitelisting its IP ranges.
• Where the environment is defined: okteto.yaml lives in your Git repository and is reviewed like code. bunnyshell.yaml is stored in the Bunnyshell platform.
• What an AI agent gets: with Okteto, the same production-like environment a developer gets, with real services and data. With Bunnyshell, a separate sandbox service with an isolated scratch filesystem.
• Environment types: purpose-built dev, preview, test and agent environments on one platform, against primary, ephemeral and preview environments that are clones of one pattern.
• Development container fidelity: Okteto's inherits the real Deployment config, including service account, secrets, volumes and sidecars. Bunnyshell's Remote Development strips the Kubernetes health probes and syncs through a third-party tool.
• Testing: in-cluster execution via Okteto Test with production parity, against no dedicated test product and a reliance on your external CI.
• Pricing model: per seat with unlimited environments and agents per seat, against $0.007 per minute for every active environment.

The Philosophical Divide: A Service You Consume vs a Capability You Own​

Here is the distinction that explains almost every other difference between these platforms.

Bunnyshell treats environments as a service delivered to you. The provider holds the control plane, holds the environment definition, reaches into your cluster to act, and meters what you consume. That is a legitimate model, and it is the same model behind most of the SaaS you already buy. It has a real benefit: there is very little for you to operate.

Okteto treats environments as a capability you own. The platform runs inside your boundary, the definition lives in your repository, and the same substrate serves developers, CI, and agents. There is a little more for you to own, and in exchange the environment layer becomes part of your infrastructure rather than a dependency on someone else's.

Neither answer is universally right. But the second one holds up better under three specific pressures: security review, GitOps discipline, and agent scale. The rest of this guide is about those three.

Architecture Matters: Where the Control Plane Sits​

Your cluster does not have to be reachable​

This is the difference that most often decides an enterprise evaluation. With Bunnyshell, your Kubernetes API server has to be reachable by an external service, whether by public exposure or by whitelisting its published IP ranges, and it has to accept credentials with enough authority to create and destroy workloads across namespaces. Their private-cluster guidance requires exactly this, which means a cluster with genuinely no inbound path cannot be onboarded.

With Okteto, the platform is a workload inside the cluster. There is no external control plane to admit, no IP range to allow, and no standing credential held outside your boundary. If your security team's position is that nothing outside the perimeter gets an authenticated path to the Kubernetes API, that position stays intact.

Your environment definition is a file in your repository​

When configuration lives in the platform rather than the repo, ordinary engineering practice gets harder. You cannot review an environment change in a pull request, cannot diff what changed between two weeks, cannot revert by reverting a commit, and cannot reconstruct the environment from the repository alone. Bunnyshell mitigates this in part: custom templates can be stored in Git repositories you choose, and its CLI can fetch and decrypt definitions. But the environment definition, by their documentation, sits in the platform.

Okteto's okteto.yaml is versioned with the code it describes. This also matters for a reason that was not obvious two years ago: it is how an AI agent learns your environment. The agent reads the manifest out of the repository, discovers your services from it, and runs the same commands a developer would.

Your development container inherits real production configuration​

Both platforms let you write code locally and run it in the cluster. The mechanics differ in ways worth knowing.

Bunnyshell's Remote Development prepares the target component by adding init containers and a persistent volume for your code, installing an SSH server, syncing files with Mutagen, and overriding the container's command. It also removes the Kubernetes livenessProbe, readinessProbe, and startupProbe, overwriting them with null for the duration of the session, because development containers usually don't start the same processes production ones do.

Okteto's okteto up creates a development copy of the Deployment that inherits the original manifest. Per our documentation, the development container uses the same service account, environment variables, secrets, volumes, and sidecars as the workload it stands in for. We override container-level configuration too, primarily to swap in a development image, so this is a difference in degree rather than kind. But the degree is the point: the closer the development container sits to the real Deployment, the fewer bugs wait until production to introduce themselves.

What Changes When Agents Enter the Picture​

This is where the two platforms diverge most sharply, and it is the newest part of the comparison.

Bunnyshell's answer for AI is a separate sandbox service, marketed alongside the platform rather than built into it. It provisions an isolated micro-sandbox in roughly 100 milliseconds, with its own filesystem and network namespace, sized in their published example at half a CPU and 512Mi of memory, and it is designed for running untrusted code. It is a good primitive, and for tasks like executing a model's generated snippet it is the right tool. What it is not is your application. We went deeper on that distinction in Sandboxes vs. Environments. There is no service graph in it, no real database, no message queue, none of your configuration. Their in-platform AI feature, Workspaces, is a persistent virtual machine on KubeVirt with a preinstalled toolchain, aimed at connecting Cursor, Windsurf, Copilot, or JetBrains Gateway over SSH. That is a cloud development machine, which is useful, but it is still not your running system.

The distinction decides what an agent can actually prove. An agent with a scratch filesystem can write code and run whatever tests need nothing but the language runtime. An agent with a real environment can deploy the change, watch the dependent services respond, run the integration suite against a real database, curl the live endpoint, read the logs, and fix what broke. Only the second one produces a change that has been verified rather than merely written, and the review burden on your engineers is completely different in each case.

Okteto gives the agent the developer's environment. You install the plugin in one command, and Claude Code, Cursor, Codex, Copilot, or anything else that reads the open Agent Skills format learns your CLI and your manifest. Agents work in one of two modes: collaborative, where you hold the dev session and the agent runs commands inside it, or autonomous, where the agent deploys the environment, implements the change, runs the test containers, smoke-tests the endpoints, checks the logs, and opens a pull request when everything passes.

Then there is the bill. Bunnyshell's published Startup rate, as of September 2026, is $0.007 per minute per active environment, which is $0.42 an hour. For short-lived human previews that is a sensible way to charge. Agents invert the assumption, because they hold environments concurrently and for longer stretches than people do. A hundred concurrent environments running eight hours a day, twenty-one days a month, comes to roughly $7,000 a month in platform fees before a cent of your own cloud spend. Okteto bills per seat annually and charges nothing per environment or per agent: one seat can run as many of both as your infrastructure supports, and an Enterprise license covers every cluster in your fleet with only unique seats counted. What is left to optimize is your own infrastructure, which the Garbage Collector and Resource Manager exist to do. That model is also why your bill tracks your team rather than your machine time, so it stays predictable as your agent count climbs. For the number itself, our team can put together a real quote, sized to your team, your cluster footprint, and the agent concurrency you expect.

Platform Engineering Enablements​

For platform engineering leaders, the question isn't just "which tool helps developers code faster?" It's "which platform helps me build and scale a developer experience function?"

Both products give you instrumentation, though they measure different things, and it is worth being precise about the difference. Bunnyshell reports DORA-style Engineering Metrics derived from your Git history, with average cycle time broken into coding, pickup, review, and deploy intervals, plus deployment frequency, and it integrates Kubecost for cloud cost reporting grouped by project, environment, cluster, template, or user. If what you want is delivery-flow reporting, that is a solid offering, and if DORA reporting to leadership is a hard requirement this quarter, weigh it honestly. Okteto Insights measures the platform rather than the Git graph, and it exports its metrics, so you can join them to whatever already tracks your delivery flow.

Okteto instruments the platform itself:

Okteto Insights gives you dashboards for build duration, deploy times, test results, node and pod utilization, and platform adoption, and the metrics can be consumed from your own observability tooling.

Okteto Catalog lets platform teams define standardized, compliant environment templates, managed from the Admin Dashboard or declared as Custom Resource Definitions so they live in your GitOps repo. Developers get self-service access to approved configurations without the platform team becoming a bottleneck.

Resource Manager right-sizes CPU and memory requests from observed usage, and the Garbage Collector applies sleep and delete policies to idle namespaces and Preview Environments. These are remediation, not just reporting: they act on the cost rather than charting it.

Unified manifest with build, dev, test, and deploy sections gives you one configuration model across every environment type, in your repository.

Enterprise readiness: SSO, RBAC, audit logs, private endpoints, and SOC 2 Type 2 compliance, without tier gating that depends on your headcount.

One practical note on tiering, since it affects evaluation. Bunnyshell's published plans put DORA metrics, cloud cost reporting, and advanced RBAC on the Scaleup plan, which carries a twenty user minimum, and the audit log on Enterprise. Worth checking against your own team size and compliance requirements early rather than late.

Choosing the Right Platform for Your Team​

Both platforms solve real problems. The right choice depends on your organization's context, not which platform has more features.

Okteto fits best if:

• Your security posture will not grant an external control plane an authenticated path to your Kubernetes API, or you operate air-gapped
• You want environment configuration versioned in Git and reviewed like code
• You are putting AI agents to work and need them verifying changes against real services and data, not writing code in a scratch sandbox
• You expect environment and agent counts to grow and do not want platform cost to track machine time
• You need different workflows optimized for different jobs: developer velocity, stakeholder review, test reliability, agent autonomy
• You are building or scaling a platform engineering function and want telemetry on the platform, plus automated cost remediation
• You have existing production pipelines such as ArgoCD and need a platform that integrates rather than replaces

Bunnyshell may fit if:

• Your primary pain is the shared staging queue, and a full-stack environment per pull request is the whole requirement
• Your clusters can accept an external control plane, and a managed control plane is an advantage rather than a constraint
• You want delivery-flow DORA reporting out of the box
• Your consumption is genuinely bursty and short-lived, which is where pay-per-minute is cheapest
• You want driving environments from pull request comments via ChatOps

The Platform Engineering Perspective​

If you are a platform engineering leader evaluating these solutions, the strategic question is this: are you buying an environment service, or building an environment capability?

Bunnyshell answers the first. It hands you on-demand environments with very little to operate, and for a team whose constraint is the staging queue, that is a fast win.

Okteto answers the second. The platform runs inside your boundary, the definition of an environment lives in your repository, and the same substrate serves developers, CI, and now agents, under governance you set. That matters more every quarter, because the number of things asking your platform for a production-like environment is going up, and most of them are not people.

If your organization has committed to Kubernetes, and your constraint is verified velocity across humans and agents rather than the absence of a staging environment, Okteto is purpose-built for that outcome.

Those are not the same problem. The solutions aren't either.

How the sandbox conversation started​

The sandbox model made a lot of sense when the original problem was straightforward. Developers on microservices teams were blocked waiting for shared environments. If you could spin up a lightweight copy of just the service you were touching and route traffic to it for testing, you could unblock the team without duplicating the entire cluster. Fast, cheap, and easy to explain to anyone who'd ever waited three hours to get a staging slot.

For teams running primarily HTTP services, sandboxes still do that job well. The concept is immediately legible to engineering teams, the economics are compelling, and the time-to-working-demo is fast.

The issue is that "sandbox" has become the default vocabulary for any kind of isolated development environment. And those two things, a routing overlay for a specific service versus a fully isolated environment, are meaningfully different.

What breaks when AI enters the loop​

Engineering teams are discovering that AI agents have a different profile of requirements than human developers. Humans working in a constrained environment can adapt. They notice that a network path isn't supported, file a ticket, adjust the workflow. They can read documentation and make configuration changes to work around a routing limitation.

AI agents can't. They require environments that are complete, where the full build, deploy, and verify loop runs without workarounds.

In conversations with platform engineering teams over the past several months, three failure modes keep surfacing.

The build gap. Closing the loop in agentic development means the agent tests its change, receives feedback, iterates intelligently on that feedback, and produces a PR that will pass CI, without a human stepping in. An agent that can write code but can't build it inside its own environment can't do that. The code gets written and pushed, but the agent has to wait for an external build to surface errors, which can take minutes or hours. Every iteration cycle is slowed by that wait. The agentic development loop breaks at exactly the point it was supposed to accelerate things. The velocity benefit teams are expecting doesn't materialize when a human or a separate CI system still has to close the loop.

The environment scope gap. A sandbox is a routing overlay, not a complete environment. An agent working in a sandbox has a scoped view: it can route traffic to a specific service, but the rest of the stack, filesystem state, queue consumers, deployment configuration, the full service graph, is shared and outside the agent's control. Agents don't just touch traffic endpoints. They write code that interacts with everything. When the environment doesn't encompass that full scope, changes that appear to work within the sandbox may behave differently when they interact with parts of the stack that were never isolated. Full-context environments give agents a complete, isolated namespace. Everything the agent needs is within its scope, under its control.

The governance gap. This is the one that keeps platform engineering leads up at night, and it's the one that's been slowest to get architectural attention. When AI agents create environments at scale, spinning up, modifying, and tearing down infrastructure in response to code commits, platform teams need visibility. Which agents created which environments? What did they access? What did it cost? Who authorized it? Without an audit trail and a policy layer, AI-at-scale becomes an unmanaged black box. Security reviews stall. Budget conversations get difficult. The platform team, which was supposed to be an enabler, becomes a blocker.

Why this matters specifically for enterprise teams​

For a small team running HTTP microservices, sandboxes are probably enough. The networking requirements are simple, governance is informal, and the per-service economics make sense.

For an enterprise team, 200 to 1,000+ developers, complex networking, formal security reviews, platform engineering teams with compliance and cost accountability, the requirements are structurally different. The platform team needs to approve the tooling. Security needs identity integration (SSO, SAML, SCIM). Compliance may need audit trails. And the development workflow needs to support the full stack, not just a routing layer.

The teams that move fast on sandbox tools in early evaluation often hit these walls at the platform engineering review. "We were making too many compromises" is a phrase that shows up more than once when teams describe why a tool that worked in demos didn't make it through a real implementation.

The right frame: governed agentic development​

The productive frame isn't "sandboxes are bad." It's that sandboxes were designed for a specific problem, and that problem has grown. As AI agents take on more of the development loop, the infrastructure underneath them needs to grow with it.

That means build systems agents can operate natively. Full-stack environment isolation so agents work in a complete, controlled context. Enterprise auth that integrates with how the rest of the organization manages access. And a governance layer that creates audit trails and policy enforcement for everything agents do, so platform teams can approve AI tooling for production use and developers can trust that what agents build actually works end to end.

The teams asking the right questions right now are the ones separating "can we demo this?" from "can we run this in production at enterprise scale?" Sandboxes are a starting point. Governed environments are the destination.

AI agents are quickly becoming first-class contributors to enterprise codebases, generating pull requests and refactoring systems at scale. Yet there's a growing disconnect between what agentic development demos promise and what engineering teams experience in practice.

The gap isn't model intelligence or prompt sophistication. It's something more fundamental: agents lack access to the runtime feedback loops that human developers rely on constantly. Without the ability to run and observe their code in realistic conditions, agents remain stuck optimizing for syntax rather than behavior.

The solution lies in extending on-demand development environments to support agentic workflows. When agents can validate changes against real dependencies and iterate based on runtime behavior, the quality ceiling disappears.

Why Code-Only Validation Fails Modern Development​

Modern applications depend on complex webs of infrastructure, external services, and runtime configurations. A microservice might interact with Kubernetes clusters, Redis caches, PostgreSQL databases, and third-party APIs while respecting network policies that exist only in deployed environments.

Human developers understand this intuitively. We write code, then immediately run it. We spin up environments, test edge cases, and iterate until reality confirms our assumptions.

Agents can't do this yet.

Most current workflows stop at code generation and unit testing, leaving agents to guess whether their output works in real systems. They're essentially coding blind, optimizing for patterns rather than measurable outcomes.

The Runtime Feedback Problem​

This constraint creates a recognizable pattern: agents that look impressive in isolated demos but produce brittle code in production. Generated code follows correct patterns and passes basic tests, but subtle integration failures accumulate over time.

The broken feedback loop follows this sequence:

• Generate code based on static analysis
• Unit test against isolated cases
• Submit changes and hope they work
• Discover runtime issues post-deployment

Without runtime validation, agents can't distinguish between code that compiles and code that actually works. They can't observe whether database migrations handle production data volumes or whether API changes maintain backward compatibility with existing clients.

Quality plateaus because agents lack the iterative validation that drives improvement in human development workflows.

Development Environments Close the Loop​

The solution requires completing the feedback cycle that produces high-quality software: generate → run → observe → refine.

This means providing agents with ephemeral development environments where they can:

• Execute code against realistic dependencies
• Observe actual behavior and performance
• Iterate based on concrete outcomes
• Test integration points safely

Self-service environment provisioning becomes crucial. Agents working on different system components need dedicated environments where they can validate changes without coordination overhead or resource conflicts.

This infrastructure transforms agentic development from speculation-driven to validation-driven. It shifts their reality from "does this code look right" to "what happens when this code runs". In turn, agents generate verified code backed by concrete evidence of runtime behavior.

Enterprise Requirements: Inside the Firewall​

Enterprise adoption faces an additional constraint: agents need access to internal services, proprietary data, and real configuration systems (all while maintaining security boundaries).

Most enterprises won't allow agents to modify systems without understanding how changes interact with internal APIs, database schemas, and security policies that exist only within their infrastructure perimeters.

Cloud development environments solve this by bringing computation inside the enterprise firewall while maintaining the isolation and on-demand provisioning that agents require. Organizations can run agents within their own Kubernetes clusters, connected to internal services but isolated in ephemeral environments that prevent unintended side effects.

This approach scales with agentic workflow adoption without requiring manual platform team intervention.

The Future: Every Agent Gets an Environment​

Looking ahead, successful agentic development will require infrastructure parity between human and artificial contributors. Just as every developer expects access to development environments, every agent will need similar runtime resources.

This represents a fundamental shift in how we approach code quality:

• Before: Static analysis → code review → post-deployment monitoring
• After: Continuous runtime validation throughout development

Agents won't just run unit tests or push changes blindly to CI. Agents will spin up environments, run integration tests, measure performance impacts, and iterate based on observed behavior before submitting changes for review.

Okteto's Competitive Advantage in Agentic Development​

Okteto has spent years solving a hard infrastructure problem: how to provision development environments that are fast, accessible, and enterprise-ready.

We built our platform for the reality of modern development. Complex, distributed systems require runtime validation that unit tests simply can't provide. Others in the space treat environments as deployment destinations. We designed them as development infrastructure from the ground up.

This foundation becomes essential as agents take on sophisticated architectural changes that demand real-time feedback. While others are retrofitting deployment tools for development workflows, we're extending proven development infrastructure to support agentic workflows.

Ready to Enable Agentic Development?​

The infrastructure for autonomous development isn't a future problem (it's an opportunity available today). Organizations that extend their development environment strategies to include AI contributors will unlock more sophisticated agentic workflows while maintaining security and quality standards.

See how Okteto's on-demand development environments provide the runtime feedback infrastructure your agents need to deliver production-ready code.

The Bottom Line​

Agentic development won't reach its potential through better models alone. The breakthrough comes when agents gain access to the same runtime feedback loops that human developers rely on for building reliable software.

Development environments (ephemeral, enterprise-ready, and optimized for continuous validation) are the missing infrastructure layer that will unlock this potential. The future belongs to agents that can validate their decisions against runtime reality, not just static analysis.

This is the ingress controller that ships as the default in most Kubernetes distributions. It's what countless tutorials recommend. It's probably what you're running in production right now. In three months, it stops receiving security patches, bug fixes, and compatibility updates.

We've been evaluating what this ingress nginx deprecation means for Okteto and the broader Kubernetes ecosystem. Here's our analysis and a decision framework that might help if you're navigating this transition.

What's Actually Happening with the Ingress NGINX Deprecation​

The Kubernetes Ingress API itself is not being deprecated. You can still create Ingress resources. What's being retired is the specific NGINX-based controller that implements that API.

This Ingress NGINX Controller retirement creates three critical operational risks:

Security vulnerabilities won't receive patches. After March 2026, CVEs discovered in the Ingress NGINX Controller won't be fixed upstream. You'll need to maintain your own fork or accept the security exposure.

Bug fixes end permanently. When ingress routing breaks or behaves unexpectedly, there's no upstream maintainer to file issues with or expect resolution from.

Kubernetes compatibility will degrade over time. New Kubernetes releases will introduce changes that the deprecated controller can't handle. It might function with Kubernetes 1.32, but will likely fail with 1.35 and beyond.

Important distinction: This deprecation affects only the kubernetes/ingress-nginx project. NGINX Inc.'s commercial ingress controller (now part of F5) remains actively maintained and supported. It's a completely separate codebase with its own lifecycle.

Why Kubernetes is Moving to Gateway API​

The Ingress API served the ecosystem during Kubernetes' early years, but its design assumptions no longer match how production platforms operate. Three fundamental limitations drove the need for a replacement:

Annotation-based configuration creates vendor lock-in. Configuring request timeouts requires nginx.ingress.kubernetes.io/proxy-read-timeout on NGINX controllers but traefik.ingress.kubernetes.io/service.serversscheme on Traefik. Every controller implements essential features through proprietary annotations. Switching controllers means rewriting all your routing configuration.

Role boundaries don't exist. Platform operators, application developers, and security teams all modify the same Ingress resources with identical permissions. A developer adding a hostname shouldn't need cluster-admin rights, but the Ingress API provides no mechanism for granular access control.

Traffic management capabilities are severely limited. Modern applications need canary deployments with traffic splitting, header-based routing decisions, request mirroring, and sophisticated load balancing. The Ingress API can't express these patterns. Each controller invents proprietary extensions that don't work anywhere else.

Gateway API addresses these architectural problems systematically. It provides role-separated resources (Gateway for infrastructure teams, HTTPRoute for developers, GatewayClass for platform vendors), controller-portable configuration that works across implementations, and comprehensive traffic management built into the specification.

The ecosystem has already committed to this direction. Istio, Contour, Traefik, Envoy Gateway, and every major ingress controller supports Gateway API today. This represents alignment with Kubernetes' established roadmap, not speculation about future possibilities.

Real-World Migration Strategy: How We're Approaching This at Okteto​

Okteto's platform depends on ingress infrastructure for generating HTTPS endpoints, routing development environment traffic, and implementing private networking security. This deprecation directly affects our core functionality.

We analyzed three Kubernetes Gateway API migration strategies:

Replace NGINX with another Ingress controller. This minimizes immediate disruption but perpetuates the same architectural problems. We'd remain dependent on annotation-based configuration and controller-specific behaviors. Most problematically, we'd face identical migration pressure when the replacement controller reaches end-of-life.

Migrate completely to Gateway API with Ingress compatibility layers. This aligns with Kubernetes' long-term direction but requires building complex translation mechanisms between networking models. We'd need to handle edge cases where Ingress semantics don't map to Gateway API primitives while supporting both during transition.

Implement hybrid support for both networking models. Maintain Ingress functionality for existing workloads while building new features on Gateway API foundations. This enables incremental modernization without disrupting operational systems.

We chose the hybrid approach because it balances technical debt reduction with platform stability.

The architectural principle guiding our decision: depend on APIs, not implementations. Platform resilience comes from abstractions that multiple controllers can satisfy, not tight coupling to specific controller behaviors.

Gateway API provides exactly that abstraction layer. We can implement features once and support customer choice in underlying networking infrastructure.

Practical Next Steps for Platform Teams​

This decision framework applies regardless of whether you're running Okteto or managing your own Kubernetes infrastructure:

Inventory your annotation dependencies immediately. Every nginx.ingress.kubernetes.io/* annotation represents technical debt requiring migration. Create a comprehensive catalog of controller-specific configurations in your manifests. Focus on annotations that implement business logic rather than basic routing (those represent the highest migration complexity).

Assess your controller's Gateway API maturity. Controllers without Gateway API support signal questionable long-term viability. You don't need immediate migration, but understanding your options prevents crisis-driven decisions. Proven Gateway API implementations include Istio Gateway, Contour, Traefik v3, and Envoy Gateway.

Evaluate whether bundling controllers still makes sense. If your platform ships with embedded ingress controllers, reconsider that architectural choice. Every bundled controller creates ongoing CVE tracking, compatibility testing, and support obligations. Letting customers provide their own networking infrastructure while you deliver higher-level abstractions often proves more sustainable.

Design for portability over convenience. Build platform features that work regardless of which Gateway API controller customers deploy. This architectural discipline creates resilience against future infrastructure changes while reducing your maintenance burden.

What This Means for Okteto Users​

We're treating this transition as an opportunity to strengthen our networking architecture. The migration prioritizes continuity (your development environments maintain their endpoints, TLS certificates continue automatic provisioning, and private networking remains fully functional). Behind the scenes, we're implementing Gateway API support for new capabilities while preserving existing workflows during the transition.

Infrastructure Evolution as Platform Opportunity​

The Ingress NGINX Controller deprecation represents natural ecosystem maturation rather than arbitrary disruption. Kubernetes networking is evolving from early-adoption defaults toward sophisticated, portable abstractions that serve diverse production requirements better.

For platform teams, this creates an opportunity to reduce technical debt, improve operational flexibility, and align with Kubernetes' architectural direction. The migration investment pays returns through reduced vendor coupling, enhanced multi-cloud portability, and more predictable upgrade experiences.

If you're navigating this Kubernetes ingress controller replacement, we'd value learning about your approach. Migration challenges are similar across platforms. Sharing experiences with both successful strategies and unexpected obstacles benefits the entire community.

The March 2026 deadline might feel aggressive, but it's accelerating the ecosystem toward more maintainable infrastructure patterns. That makes the migration effort worthwhile.

“How do you handle development environments? I’ve tried many tools, but they all fall short at some point.”

I'm sure this resonated with so many people tuning in.

Every dev environment solution does fall short eventually. And that’s not a sign they’re broken. It’s a sign the problem is harder (and more contextual) than most people realize.

Here are a few follow up thoughts on the subject of environment pitfalls with lessons we’ve learned from helping platform teams design their environment strategies over the years.

Dev environments shouldn’t “work out of the box”​

There’s this widespread hope that dev environments will one day “just work” for everyone, in every architecture, with zero setup. That sounds amazing.

But it’s not realistic, at least not for teams building real-world software at scale.

At Okteto, we’ve been working on this problem for 6+ years. We’ve learned that dev environments aren’t something you install and forget. They’re a system you design, evolve, and constantly refine as your stack, team, and goals change.

Think in terms of systems, not just tools​

One thing I see all the time: teams blame their dev environment tooling when what they’re really running into is a system-level tradeoff.

Let’s say you’re spinning up dozens or even hundreds of microservices and multiple databases for every developer. That can work. In fact, for some teams, it’s the best way forward. It’s simple, consistent, and isolates every dev experience.

But that model also comes with a literal cost. Running full replicas of complex systems for every developer can get expensive, especially as your team grows. And maintaining that level of scale, performance, and cleanup across environments becomes an operational challenge of its own.

The hard truth is that there is no universally right answer. Some teams prioritize speed and simplicity and are fine paying more to cloud providers. Others invest in alternate environment strategies like sharing infrastructure, selectively isolating services, or adopting stronger control policies to address budget and complexity needs over time.

Either path can work. But the point is that you need to be intentional about the tradeoffs you’re making and revisit them as your architecture evolves.

Local dev isn’t the future​

I still hear people say, “I just want to run everything locally.” And look, I get it. I’ve been there too. There’s a certain comfort in having control of running things on your machine.

But I’ll be honest…local dev isn’t the future.

As architectures shift toward microservices, cloud-managed dependencies, and event-driven systems, local environments start breaking down. They're brittle, inconsistent, hard to replicate and impossible to scale in any realistic way.

“You can’t run a distributed monolith on your laptop. You can run it in the cloud and start fixing what’s broken.”

This is where the industry is headed. Modern cloud-native architectures aren’t designed to run locally. They’re designed for platforms like Kubernetes. Trying to emulate that locally, or stitching together remote services with a mostly-local workflow, becomes a fragile patchwork.

To truly test and iterate the way your app behaves in production, you need to run in Kubernetes not just redirect traffic to it. That’s how you close the gap between dev and prod, and build confidence into every commit.

Remote environments doesn’t always mean full replication​

Another common misconception is that every developer always needs a fully isolated copy of the entire stack. But as your team grows and your architecture becomes more complex, replicating everything from databases, services, dependencies, for each individual developer can become slower, expensive to scale, and difficult to manage.

This is where flexibility of choice becomes important in your environment strategy. The ability to use the right environments for the right scenarios makes a big difference.

Many teams are adopting a hybrid approach that combines shared resources with selective isolation. At Okteto, we call this feature Divert. Instead of full replication for each developer, Divert allows you to create lightweight development environments that include only the services you are actively working on while leveraging an existing shared environment for all other microservices. At large scale, these environments become faster to spin up, more cost-efficient, and still gives you realistic, production-like context.

And of course, there are times when a fully replicated environment is the right choice, like end-to-end testing, or when debugging issues that span across multiple services. The key is having the flexibility to choose the right model for the job, and to shift as those jobs change.

“There’s no one-size-fits-all. The best environment strategies evolve with your architecture and your team’s needs.”

Optimize environments for the team, not just you​

Here’s one of my hotter takes: sometimes, a dev environment feels like it’s slowing you down, but it’s actually speeding up the whole team.

And at the end of the day, that’s what matters.

If we’re optimizing for individual convenience, we end up with silos and snowflake setups. But if we’re optimizing for team throughput—collaboration, testing, deploy velocity—that’s where the real value shows up.

What’s the “right” dev environment strategy?​

There isn’t one. That’s the truth.

What works for your team depends on your goals, your architecture, and your appetite for change. Some teams need isolated cloud environments. Others might get by with remote-local setups. Many land somewhere in between.

The most successful teams aren’t chasing the perfect dev environment. They’re building systems that adapt. They’re flexible. They revisit their environment strategy often and as their architecture changes. They’re not afraid to experiment, iterate, or even switch tools when the context demands it.

“The best dev environments aren’t perfect—they’re adaptable. You need something that grows with your architecture, not fights against it.”

Whether you’re wrangling a distributed monolith or just trying to spin up isolated previews, the goal isn’t perfection. It’s progress. Ultimately, it’s making sure your dev environment is working for your team, not slowing them down.

Final thought​

If you’ve ever felt like your dev environment is falling short, you’re not alone. That’s exactly where every team starts.

What matters is whether you’re building a system that adapts. One that helps your team ship faster—not just work harder.

If you want to talk more about environments or developer experience, I’m always up for it. Reach out here →

Understanding the Shared Challenge​

Modern cloud-native development is complex. Your applications aren't just code anymore. They're code plus configuration, runtime dependencies, network policies, secrets, and interactions across dozens of microservices. Developers can't gain real confidence that their changes work by running unit tests on a laptop. They need access to realistic environments that reflect production complexity.

Both Okteto and Qovery recognize this challenge. Both aim to give developers better environments than local development that can't match production's complexity. But they approach the problem from different starting points, and those starting points shape everything about how each platform works.

How Qovery Works​

Qovery positions itself as a DevOps automation platform. Its core promise is to give teams Heroku-like simplicity while running on their own cloud infrastructure. When you use Qovery, the platform provisions complete, standalone copies of your infrastructure for each environment: development, staging, production.

This approach has clear appeal. Teams migrating from Heroku or Elastic Beanstalk get a familiar abstraction layer. Organizations without deep Kubernetes expertise can deploy to Kubernetes without learning Kubernetes. The platform handles infrastructure provisioning and deployment, prioritizing abstraction over daily developer experience.

Qovery's architecture creates full infrastructure copies for each environment. For example, when you spin up a preview environment, you get a complete replica of your services, databases, and dependencies. This provides high fidelity but comes with tradeoffs: longer spin-up times (minutes rather than seconds), higher infrastructure costs (full resource duplication per environment), and costs that scale linearly with environment count. You'll also need to translate your existing deployments into Qovery's configuration model rather than using your native Kubernetes manifests.

The focus is on deployment automation and infrastructure abstraction. Qovery aims to eliminate the need for DevOps expertise by handling the complexity behind a simplified interface.

How Okteto Works​

Okteto takes a different architectural approach, starting from a different premise about what developers actually need.

Instead of creating infrastructure copies, Okteto runs your development process directly in Kubernetes, in actual pods within your cluster. When you develop with Okteto, your code executes in the same runtime environment where it will eventually run in production: same service accounts, same environment variables, same security configurations, same volumes, same sidecars. Changes sync in real-time, with feedback loops measured in seconds rather than minutes.

But the deeper difference isn't just architecture. It's philosophy.

Okteto is built on the premise that different environment types exist to serve different workflows and use cases, and a platform should be optimized for each workflow's specific job. A dev environment isn't a small staging environment. A preview environment isn't a temporary production replica. Each environment class has a distinct purpose and requires distinct capabilities.

This "environments have different jobs" philosophy shapes everything about how Okteto works:

Dev Environments are optimized for iteration speed. Real-time file sync, hot reload, bidirectional synchronization, remote debugging, port forwarding for IDE integration, and volume snapshots to quickly restore state. The job is all about helping individual developers move fast.

Preview Environments are optimized for collaboration and validation with auto-deploy on pull requests, shareable URLs and automatic cleanup on merge. The job is enabling PMs, designers, QA, and stakeholders to validate changes before they're merged, without any technical setup required.

Test Environments are optimized for consistency and reliability. Tests run inside the Kubernetes cluster, not on a separate CI virtual machine. They have the same runtime as production, access to private services and reduced latency. The job is ensuring your entire pipeline, from dev through CI, runs on Kubernetes to eliminate "works in CI but not in prod" surprises.

Agent Environments give AI coding agents a place to build, test, and validate code. AI agents need production context the same way developers do. They need safe, secure, production-like environments to build, deploy, and verify code end-to-end, not just suggest changes. Each agent gets its own isolated, ephemeral environment with full access to code, infrastructure, and tests. The job is enabling teams to run fleets of agents in parallel, each working independently on different tasks, with the security and observability enterprise teams require.

Quick Comparison​

The table shows what each solution offers. The rest of this guide explains why those differences matter for your decision.

The Philosophical Divide​

Here's the core distinction that explains most of the differences between these platforms:

Qovery takes a generic approach to environments. Every environment is an infrastructure copy with different sizing and lifecycle rules. This works if your needs are straightforward, but it means the platform can't optimize for what each workflow actually requires.

Okteto takes a purpose-built approach. Each environment type is designed around its specific job because those jobs are fundamentally different.

The result isn't more complexity for developers. It’s that developers (and PMs, QA, agents, etc.) get better outcomes because the environment is optimized for what they're actually trying to accomplish, rather than forcing everyone to use a generic infrastructure copy.

Architecture Matters: Where Your Code Actually Runs​

The philosophical difference manifests in a concrete technical distinction: where your code actually runs during development.

With Qovery, you get a complete, isolated replica of your services, but you're working with deployed containers, not an interactive development experience.

With Okteto, your development process runs in actual Kubernetes pods, inheriting your production configuration automatically. You're not developing in something that looks like production. You're developing in production's twin.

This matters for several reasons:

You get true production parity​

Okteto eliminates the "works on my machine" problem at the root. If it works in your dev environment, it works in production, because they're the same runtime. Integration issues surface during development, not after deployment. Configuration drift between environments disappears because there's only one environment configuration.

Your Feedback Loops Drop to Seconds​

Code changes sync in under 3 seconds. You write code, save the file, and see results immediately. Developers aren't waiting on container builds, image pushes, or long deployments. Seconds vs. minutes adds up. A developer iterating 50 times a day saves over 2 hours with a 3-second loop instead of a 3-minute deploy. Multiply that across your team and the year, and you're recovering thousands of engineering hours.

You Debug Directly in Kubernetes​

Attach your IDE's debugger directly to code running in Kubernetes, setting breakpoints, inspecting variables, and stepping through execution against realistic services and data. Instead of adding log statements, redeploying, and waiting, you can pause execution and inspect state in real time. You're debugging against actual dependencies, actual data flows, and actual network conditions. For complex bugs that only manifest in production-like environments, this cuts investigation time dramatically.

Your Costs Don't Scale Linearly​

Environments share cluster resources intelligently, so costs don't scale linearly with team size. With infrastructure-copy approaches, ten developers mean ten full environment replicas, and fifty developers mean fifty. Okteto's architecture lets teams share baseline resources while isolating only what each developer is actively changing. The result is predictable costs that don't balloon as your team grows.

Platform Engineering Enablements​

For platform engineering leaders, the question isn't just "which tool helps developers code faster?" It's "which platform helps me build and scale a developer experience function?"

Okteto provides the infrastructure platform teams need:

Okteto Insights gives you visibility into your developer experience by tracking build duration trends, deploy times, test success rates, and platform adoption metrics. This is the data you need to understand how your platform serves developers and where to improve.

Okteto Catalog lets platform teams define standardized, compliant environment templates. Developers get self-service access to approved configurations, and platform teams maintain governance without becoming a bottleneck.

Resource Manager provides cost visibility and optimization across namespaces, while Garbage Collector sets sleep and delete policies for automatic cleanup. Know what you're spending, where to optimize, and let smart policies handle the rest.

Unified manifest with build, dev, test, and deploy sections provides consistent governance across all environment types. One configuration model for your entire development lifecycle.

Enterprise readiness: SSO, RBAC, audit logs, and the compliance features (SOC 2 Type 2) that enterprise organizations require.

Choosing the Right Platform for Your Team​

Both platforms solve real problems. The right choice depends on your organization's context, not which platform has more features.

Okteto fits best if:

• Your organization has already committed to Kubernetes and is experiencing developer productivity pain
• You want developers working in environments that truly mirror production to eliminate environment skew
• You need to support different workflows for different teams (dev velocity, stakeholder review, test reliability)
• You're building or scaling a platform engineering function
• You have existing production deployment pipelines and need a solution that integrates rather than replaces
• You care about enabling your entire product team, not just developers
• You want visibility into platform adoption and developer productivity metrics

Qovery may fit if:

• You're building greenfield infrastructure without existing Kubernetes expertise
• You want a single vendor for dev through production because infrastructure management is your primary pain point, not developer velocity
• You're migrating from Heroku or similar PaaS and want familiar abstractions

The Platform Engineering Perspective​

If you're a platform engineering leader evaluating these solutions, here's the strategic question: Are you trying to automate infrastructure, or are you trying to accelerate your entire product team?

Qovery answers the first question. It automates DevOps so you don't have to hire for it. That's valuable for organizations at a certain stage.

Okteto answers the second question. It gives developers sub-3-second feedback loops, gives PMs and designers shareable preview URLs, gives QA on-demand test environments, and gives you the visibility to continuously improve. It treats each workflow stage as a distinct problem worth solving well.

If your organization has committed to Kubernetes and your constraint is developer velocity, not deployment automation, Okteto is purpose-built for that outcome.

See the Difference​

Ready to see how purpose-built development environments can accelerate your team?

Our team has helped organizations from 20 to 2,000+ developers build platforms that actually scale. We'll walk through your specific environment strategy and show you how Okteto fits your development process.

Both solutions address this need, but one is built for individual developer speed while the other is designed for organizational velocity.

Understanding the Shared Goal​

Modern application development has moved far beyond simple monoliths. Your applications are now code plus configuration, runtime, network policies, and countless dependencies across microservices. Developers can't gain real confidence that their changes work by running unit tests alone. They need access to realistic environments that reflect production complexity.

This is where solutions like Okteto and mirrord come in. Both recognize that the traditional "code locally, pray it works in CI" workflow creates bottlenecks, bugs, and frustration. Both offer ways to speed up the inner development loop while connecting to shared services.

How mirrord Works​

mirrord is designed to give individual developers a fast feedback loop by allowing them to run their code locally while connecting to services running in a remote Kubernetes cluster. When you use mirrord, your application process runs on your local machine, but mirrord creates an abstraction layer that intercepts network calls, environment variables, and file system access, routing them to or from the remote cluster as needed.

This approach lets developers iterate quickly on their code without needing to build containers, push images, or wait for deployments. You write code, save the file, and see results almost immediately, all while your service behaves as if it's connected to your staging or development environment.

The focus is squarely on developer velocity for that inner development loop: the cycle of writing code and iterating.

How Okteto Works​

Okteto takes a different architectural approach. Instead of running your code locally with an abstraction layer, Okteto runs your development process directly in Kubernetes, in actual pods within your cluster. When you develop with Okteto, you're working in the same runtime environment where your code will eventually run in production.

Okteto's flexibility comes from recognizing that different teams and different scenarios need different approaches. Your payments team testing a critical transaction flow doesn't need the same environment as your front-end team building a new dashboard. A developer fixing a bug in one service doesn't need the same setup as a platform engineer validating infrastructure changes across 50 microservices. Okteto adapts to match what each team actually needs, whether that's a single service connected to shared dependencies, a full environment replica, or something in between.

Beyond the development experience, Okteto provides the infrastructure for your entire development lifecycle: on-demand image builds, namespace management, preview environments for pull requests, testing capabilities, observability, and the governance features platform teams need to support hundreds of developers.

Quick Comparison: What Are the Key Differences?​

The table shows what each solution offers. The rest of this guide explains why those differences matter for your decision.

Understanding the Strategic Differences​

Architecture: Where Your Code Actually Runs​

Here's a technical distinction that matters: when you use mirrord, your process isn't actually running on Kubernetes. There's an abstraction layer that replicates network calls, secrets, and other cluster behaviors. This works for many scenarios, but it means you're not testing against the actual runtime environment, access controls, and network patterns your code will face in production.

With Okteto, your development process runs in actual Kubernetes pods within your cluster. Same access management, same network policies, same runtime constraints. This matters more as your applications grow in complexity and your organization's compliance and security requirements mature.

Scope: Individual Speed vs. Organizational Velocity​

Now that you understand how each solution works, the strategic question becomes: what do you actually need?

mirrord is a focused tool built to solve one part of the development lifecycle exceptionally well: enabling individual developers to get fast feedback by running code locally while connecting to a remote Kubernetes environment.

Okteto is a complete platform built with the understanding that fast feedback loops are essential, but they're just the starting point. Building great developer experience for your organization means thinking beyond individual speed to organizational velocity. A platform handles your full development lifecycle: building images, running tests, generating preview environments, managing access and costs, and providing the visibility platform teams need to support hundreds of developers efficiently.

The Day One and Day Two Story​

Both Okteto and mirrord excel at day one. You can start with a single service, connect it to a shared environment, and immediately give developers that fast feedback loop everyone wants.

The difference emerges after that initial win, when your team's needs expand:

Months 1-3: A few developers are using the new workflow. Fast feedback is delivering value. Success stories are spreading.

Months 6-12: More teams want in. You've gone from 10 to 40 to 100 developers. New questions surface: How do we manage access to shared environments? What's this costing us? Can we build images on-demand instead of depending on CI? How do developers run tests before opening a PR? What about preview environments for code review?

Year 2+: You have multiple teams with completely different needs. The front-end team just needs API access. The payments team needs three specific microservices. The platform team needs to test changes across 50+ services. Your AI team needs environments to run and test hundreds of agents in parallel.

This is where the platform approach proves its value.

What an Environment Platform Actually Provides​

When we talk about Okteto as a platform, here's what that means in practice:

Multiple Development Models, One Solution​

Not every team in your organization will work the same way. Some teams need full environment deployments. Others work better with a single service connected to shared dependencies. Some need hybrid approaches depending on what they're building that day.

Okteto supports all three models:

• Divert mode: Run a single service with your changes while routing traffic from a shared environment (similar to mirrord's approach)
• Full deployments: Spin up complete environment replicas when you need true end-to-end validation
• Hybrid: Mix local and remote services based on what makes sense for your workflow

You don't have to choose one model and force every team to adapt. Different teams can use different approaches, and individual developers can switch between them based on their current task.

Supporting The Full Development Lifecycle​

Fast feedback on code changes is table stakes. But your developers also need:

Build infrastructure: Build container images on-demand without depending on CI pipelines or running Docker Desktop locally. This becomes crucial as your team scales and build times impact everyone's velocity.

Testing capabilities: Run integration tests, end-to-end tests, and validation against realistic data before your code reaches CI. Catch issues earlier in the cycle.

Preview environments: Automatically generate shareable environments for every pull request. Your reviewers can see changes in action, not just read code diffs.

Namespace management: Control who can access what, how long environments live, and how resources are allocated across teams. This isn't glamorous, but it's essential at scale.

Observability and insights: Understand how your team actually works. Which microservices are build bottlenecks? How are teams using environments? Where are the friction points? This visibility helps you continuously improve your developer experience.

Cost and resource management: Know what you're spending and where. Set policies for automatic cleanup and scale resources based on actual usage patterns.

Enterprise readiness: SSO, audit logs, compliance controls, and the security features that enterprise organizations require.

Choosing a Development Environment Solution For Your Team​

As you evaluate development environment solutions, look beyond the feature comparison chart. Consider where your team will be in 12 months, 24 months. Do you need just faster feedback loops, or complete development infrastructure? Will this solution grow with you, or will you need to migrate again as you scale?

Here's how to think about this decision:

Choose a focused tool like mirrord if:

• You have a small team with simple environment needs
• Your development model is straightforward and unlikely to change
• You have other solutions in place for builds, testing, and preview environments
• Your primary concern is individual developer speed, not organizational velocity

Choose a platform like Okteto if:

• Your team is growing or you expect significant growth
• You need to support multiple development workflows across different teams
• You're building or scaling a platform engineering function
• You care about realistic Kubernetes environments, not abstraction layers
• You want a solution that handles the entire development lifecycle
• You need enterprise features like governance, observability, and cost management
• You're thinking about developer experience as a long-term investment

Ready to See the Difference?​

If you're building for growth, if you're investing in platform engineering, if you need flexibility to support diverse teams and workflows, Okteto is built for you.

Start with our free tier to see how easy it is to get up and running.

Want to discuss your specific environment strategy? Our team has helped organizations from 20 to 2,000 developers build platforms that actually scale. Talk to our team →

For platform teams, this trust gap represents both a challenge and a massive opportunity. Developers need a few key things to trust AI agents enough to rely on them for important work, and platform engineers are uniquely positioned to be the catalyst that makes it happen. This post shows you how to build that trust and accelerate AI adoption across your organization.

The Trust Paradox in AI-assisted Software Development​

The data tells an interesting story. 62% of developers are now using AI tools (up from 44% last year), but favorability actually dropped from 77% to 72%.

This is the trust paradox of AI adoption. Usage is climbing while confidence is declining. Developers are adopting AI tools faster than ever, but they're also becoming more skeptical about the results.

Why? Because the current AI tools create a "trust but verify" problem that doesn't scale. They're great at generating code that looks smart, but they leave you doing all the validation work. You get code snippets without knowing if they actually work, if they handle edge cases properly, or will break when they hit real production constraints.

This creates a confidence erosion cycle where AI generates promising code, you find issues during manual testing, and you trust the agent less next time. Instead of building confidence through proven results, current tools are making developers second-guess what they produce.

Meanwhile, conversations are leaning into which LLM to use and how to craft the perfect prompt, but nobody's talking about giving AI agents the production-like environments they need to generate real results. To understand why this matters so much, let's first look at common friction points developers are experiencing.

Why Current AI Tools Aren't Meeting Developer’s Needs​

Developers are excited about AI, but they're also getting burned by it. Here's a few hurdles they are encountering.

The "Code Suggestion Trap"​

Most AI tools today are basically fancy autocomplete. They spit out code snippets, maybe even entire functions, then basically say "good luck!" and leave you to figure out the rest.

Now you're stuck doing all the verification work. Does this code actually work? Has it been tested? Will it break in production? Does it handle edge cases? Is it secure? You end up spending just as much time checking the agents homework as you saved by using it in the first place.

The promise was increased productivity, but the reality is increased validation overhead.

The Local Development Wall​

The next hurdle: AI agents running on your laptop are basically flying blind. They don't know about your internal APIs, your database schemas, your microservices, or any of the custom network policies that make your app actually work.

So the agent generates code that looks great locally but fails the moment it touches your real infrastructure. It's being put in a situation to make assumptions about your application that just aren't true.

The Security and Governance Gap​

Enterprise teams have additional concerns beyond just functionality. How do you audit what an AI agent did? How do you ensure it's not exposing sensitive data or violating compliance requirements? Most AI experiments are operating as black boxes without the enterprise-grade controls that organizations need.

When developers install AI tools on their laptops or use cloud-based services, there's often no visibility into what data the agent accessed, what actions it took, or whether it followed your security policies. For regulated industries or security-conscious organizations, this lack of governance makes AI adoption a non-starter for both adoption and trust.

The Platform Engineering Opportunity​

Developers are in experimentation mode with AI tools. Some are going out of bounds because they don’t know they have better options. They haven’t been trained or given the best practices for your organization. Sound familiar? It's the same pattern we've seen with cloud adoption where developers find tools that make them more productive, and if platform teams don't provide a path, they'll make their own.

The difference is, with AI agents, the stakes are higher. We're talking about internal code and secrets that have a high potential to be shared with external LLM providers. That’s.. not ideal.

But here's your chance. This isn't your first rodeo. The teams that get ahead of developer adoption by building better alternatives, or golden paths if you will, they win.

Right now, every developer is basically running their own AI solution with zero governance, zero observability, and zero standardization. That's a problem you can solve.

Three Essential Pillars for Trustworthy AI in Software Development​

Let's talk about what developers actually need to trust AI agents. It comes down to three things, and they're pretty simple when you think about it.

Empowerment ("I can describe what I want, and it actually happens")​

This is about going way beyond code suggestions. Developers need AI agents that can take a prompt like "add authentication to this API" and actually deliver a working, deployed, testable feature.

Not just code that might work. Not just suggestions you have to implement yourself. The goal should be a real endpoint you can reference, with proper database connections, that handles edge cases, and that you can immediately test and validate.

When an agent has access to your actual infrastructure (your databases, your APIs, your deployment tools), it stops making wild assumptions and starts making informed decisions. It knows your database schema, understands your API contracts, and can work within your actual constraints to produce trustworthy work like a real member of your team.

The empowerment comes from seeing results, not just savvy code. Click a link, test an endpoint, see it working. That's trust.

Safety ("I can experiment without breaking anything")​

Safety isn't just about preventing disasters (though that's important). It's about psychological safety - knowing you can let an AI agent loose on a complex task without worrying it'll take down production, expose sensitive data or mess up your local environment.

This is where we have strong opinions and where ephemeral environments become your best friend. Every AI agent needs its own completely isolated environment + your infrastructure. There should be no configuration drift, no weird state from previous runs, no chance of stepping on other people's (or agents) work.

Safety can't be an afterthought. Your governance, security policies, and access controls need to be baked right into these environments. The agent operates within the same boundaries you'd set for a new team member with appropriate access, proper monitoring, full audit trails.

Unblocked ("I don't have to configure anything")​

This is where platform comes in. Remember the difference between tools and workflows that get utilized and those that get abandoned often comes down to friction. The same is true for AI adoption.

Developers shouldn't have to become infrastructure experts to try AI workflows. The cognitive overhead of setup, configuration, and troubleshooting kills experimentation before it starts.

The most successful AI implementations remove barriers rather than adding them. When developers can focus on the problem they're trying to solve instead of wrestling with tooling, that's when you see real adoption and genuine productivity gains.

This isn't just about convenience. It's about enabling the kind of rapid experimentation that builds confidence in AI tools. When trying something new is easy, developers will actually try it. When it's complicated, they'll stick with what they know.

When you nail this, developers stop thinking about the infrastructure and start thinking about the problems they want to solve. That's when AI adoption can really take off.

The Infrastructure Gap Everyone's Missing​

Building trust with agentic development requires a few things working together in tandem. You need solid models, great prompting, and the right infrastructure. Most teams are getting really good at the first two. They've figured out which LLMs work best for their use cases and how to write effective prompts.

But they're missing the third piece that makes realistic output possible.

When you give a capable AI model good prompts AND production-like context to work within, that's when you see the real breakthrough in trust and reliability.

Why Application Context Changes Everything​

Think about how modern applications actually work. It's not just code anymore. It's code, configuration, secrets, infrastructure, network policies, deployment workflows, monitoring, logging, and the fifteen other things that make your app actually run in production.

When an AI agent understands this full context, it generates fundamentally different output. Instead of creating a REST API that works in isolation, it builds one that properly integrates with your auth service, follows your database conventions, handles your error patterns, and deploys using your actual CI/CD pipeline.

The validation happens automatically because the agent is working in an environment that mirrors production. When it says "this works," you can actually trust that because it's been tested against real constraints.

And ultimately, trust builds when developers see working systems, not just clever code. An agent that can show a functioning output demonstrates competence in a way that code suggestions never could.

Your Strategic Role as a Platform Team​

This is where platform teams become the heroes of AI adoption.

Your role is expanding from infrastructure automation to AI experience enablement. You're creating the foundation that lets developers confidently delegate complex work to AI agents. You're building on the platform you already have and adding a new dimension that makes AI agents actually useful and safe for your teams.

The magic happens when you can abstract away all the complexity of AI infrastructure while maintaining the control and governance your organization needs. Developers get the simplicity of "just works" environments, while you ensure security policies, compliance requirements, and operational standards are automatically enforced.

This is about enabling developer velocity without sacrificing governance. When you get this balance right, AI adoption accelerates naturally because developers trust the guardrails you've built.

The Network Effect of Adoption​

The beautiful thing about getting this right is how success breeds more success. When some developers start having positive experiences with AI agents in proper environments, word spreads quickly. Other developers see working demos, successful deployments, and real productivity gains.

This creates a virtuous cycle. More developers want to try AI agents, which leads to more success stories, which drives even broader adoption. Instead of fighting skepticism and resistance, you're building momentum across the organization.

Plus, you get the visibility and control that's been missing from the current chaos of individual AI tool adoption. Instead of wondering what developers are doing with AI, you have observability, governance, and standardization built in.

Building this infrastructure foundation isn't just a technical challenge. It's a strategic opportunity that will define how your organization adopts AI.

Why This Matters More Than You Think​

The teams that solve AI infrastructure first are going to have a massive advantage. Not just in productivity, but in talent attraction, developer satisfaction, and business outcomes.

You're Building the Future of Work​

When developers trust (and enjoy) working with AI agents because they operate in properly governed, production-like environments, adoption stops being cautious and starts being aggressive. Teams begin tackling bigger problems, automating more complex workflows, and shipping faster than they ever thought possible.

Think bigger. You're not just enabling current AI capabilities. You're building the foundation for what's coming next.

Single agents are just the beginning. The real transformation happens when teams can orchestrate multiple specialized agents working together on complex, multi-step workflows. The infrastructure patterns you establish now (ephemeral environments, policy enforcement, observability) become the foundation for enterprise-scale AI orchestration.

Platform Teams as AI Enablers​

This positions platform teams at the center of organizational AI transformation. You become the team that makes ambitious AI projects possible by providing the infrastructure foundation that developers can build on confidently.

Developers start leveraging platform capabilities as competitive advantages rather than working around infrastructure limitations. Leadership sees platform investment as directly driving AI transformation rather than just keeping the lights on.

The Bottom Line​

Trust in using AI agents in development lifecycle comes from having all the pieces working together. Great models and prompts get you started, but the infrastructure foundation is what makes developers confident enough to actually rely on AI for important work.

Get the infrastructure right, and AI adoption accelerates across your organization. Teams become more ambitious, developers become more confident, and platform teams become the heroes of AI-powered transformation.

The transformation is already happening. The only question is whether you'll lead it or spend the next few years trying to catch up.

AI agents are moving fast. What started as single-agent experiments in terminal windows is quickly turning into something more ambitious like multi-agent systems that collaborate, take initiative, and run complex workflows in parallel. The future isn't one agent. It's fleets of them.

But here’s the challenge: we need real infrastructure to support this, especially at enterprise scale.

Many teams are beginning to scale agent usage to broader adoption across engineering workflows. But the tools and infrastructure are lagging behind that ambition. Isolation becomes harder to maintain, policies are difficult to enforce, and managing agent deployment at scale introduces new overhead for platform teams.

What teams need is a way to give every agent its own remote environment that runs on their company infrastructure. These environments must be ephemeral, secure, and aligned with how your applications run in production. That unlocks real use cases for parallelism and scale. It enables teams to verify code rather than have agents simply suggest it. Most importantly, it supports agentic development in a way that meets enterprise standards.

Why Agentic Development Requires Infrastructure​

Scaling AI agents from a single instance to a functioning fleet is a shift that requires more than just the right logic or workflows. It requires an infrastructure orchestration layer.

We’re seeing a wave of multi-agent frameworks and building solid proof-of-concepts for local dev. You’ve probably even seen the workflow where developers are running five terminals with five different agents. It works, to a point. But when those agents need to run concurrently, access internal systems, or follow organizational policies, that approach begins to fall apart. We know that local setups and shared clusters are simply not built to support repeatability, security, and scale.

You start hitting familiar friction: configuration drift, lack of auditability, resource contention, and security concerns. These aren't signs of bad practice. They're symptoms of missing infrastructure.

So, the moment has arrived. We’re pushing the boundaries at a faster pace than we’ve seen in a very long time and we need to quickly solve for these limitations in order to unlock real agent adoption.

Jack Clark, cofounder of Anthropic, described the opportunity clearly:

"I think it's actually going to be the era of the manager nerds now, where being able to manage fleets of AI agents and orchestrate them is going to make people incredibly powerful."

But to unlock that potential, you need ephemeral, isolated and reproducible environments for every agent. You need observability into what’s running and where. And you need automation that lowers the barrier for developers while keeping platform teams in control.

That’s the foundation we built Okteto AI on.

What is Okteto AI​

We built Okteto AI to help platform and engineering teams orchestrate, run and test agents at scale.

With Okteto AI, every AI agent gets its own fully provisioned environment, ready with the services, configs, and dependencies it needs. These environments are designed to be ephemeral: they spin up in seconds, run the task, and shut down when done.

Beyond just generating suggestions, agents can now build, deploy, and test code end-to-end inside these environments. That gives developers confidence in the output, and they no longer need to manually verify every change or review every line. When the agent completes its workflow, you know the code works because it’s already been validated in a production-like setting.

Why Okteto Environments Fit Agent Workflows​

As agents become an extension of our teams, they’ll need the same access and resources that developers need today such as code, infra, tests, network policies, etc. And they’ll need isolated spaces to experiment, fail, try again, and improve without the risk. Okteto environments provide exactly that with strong security baked in:

• Ephemeral by design: every agent gets a clean slate. No stale state or config bleed across runs. It also ensures every agent operates in a repeatable context, making tests more reliable and environments easier to debug and audit.
• The power of your infra: maintain full control by running environments inside your own cloud or Kubernetes infrastructure. Ensures agents can interact safely with internal APIs and services, and allows platform teams to enforce organizational security policies while maintaining production parity.
• Realistic and consistent: environments that give agents a place to actually run and verify their code, not just suggest it. Each action happens in real-time, in a space that reflects how your application behaves in production. You get tested, working code, not just output that looks right.
• Instant provisioning: automate the provisioning of environments so platform teams can support hundreds of concurrent agent runs without bottlenecks.
• Fully governed and observable: control access, set resource limits, monitor infrastructure usage, and track how many agents are running at any time. Platform teams get full visibility into activity and costs, making it easy to manage scale while maintaining oversight.

These are the same capabilities already used by teams at Monday.com, LaunchDarkly, and Ruggable to power developer environments. Now, they’re available for AI agents too.

Real Use Cases from Early Testing​

Early users are already putting Okteto AI to work on real engineering projects. These aren’t demos or toy apps. They’re production-grade workflows powering real development.

Parallel feature development: A backend engineer launched two agents in isolated dev environments to work on separate features. One agent refactored the billing service to support regional tax logic. The other scaffolded a new FastAPI service for fraud detection. Both agents ran independently, passed all tests, and opened pull requests with production-ready code. This enabled faster delivery across multiple initiatives without added complexity.

Automated onboarding of a legacy Go service: A platform engineer used an agent to onboard a live billing API into Okteto. The agent generated an Okteto Manifest and Docker Compose file, spun up the full environment, connected a seeded Postgres database, ran tests, and opened a pull request with a preview environment. What normally took days was completed in minutes.

Greenfield scaffolding for internal tools: A developer used an agent to scaffold a new FastAPI application for an employee directory. The agent generated the full project structure, wrote tests and configuration files, ran validation with Okteto Test, and launched a preview environment for internal review. This gave the team a production-like foundation to build on quickly.

These stories show the real potential of pairing agents with cloud-native infrastructure. Okteto makes it possible for agents to build, test, and ship working code inside environments that reflect your real application, not just generate suggestions.

As Sourcegraph’s “Revenge of the Junior Developer” puts it, the rise of agents levels the playing field. The right tools make anyone more productive, but only if the environment supports that progress.

That’s the opportunity in front of us. Okteto gives these agents the environment they need to go from limited experiments to productive contributors. Without infrastructure that supports experimentation and scale, agents won’t deliver results.

100x Productivity for the Agent Era​

Oketo AI represents a fundamental leap forward in how agents are used in modern software delivery, and in how developers interact and manage them.

If AI agents are already delivering a 10x improvement over traditional development for repetitive and routine tasks, teams have the opportunity to multiply that impact by another 10x with parallel agents and Okteto can help get them their faster. With one-click access to instant agent environments, developers can confidently delegate tasks to agents and immediately verify the output without switching contexts or troubleshooting broken setups.

This is not just a tooling upgrade. It is a reimagining of the developer experience. Okteto brings together infrastructure automation, agent orchestration, and production realism into a seamless, developer-first workflow

And while developers will love managing fleets of agents, others prefer deep focus solving a problem with a single agent. The future of development should make room for both. It should amplify strengths, and remove friction.

At Okteto, we’re building with that in mind. The Okteto Platform gives you infrastructure to scale dev, test, preview and agent environments without adding overhead so developers can do what they do best - build great products.

This is what 100x productivity can look like.

Try Okteto AI​

We’re looking for teams experimenting with multi-agent orchestration who want a safe place to run workflows and are ready to push AI in real infrastructure.

Okteto AI is included in your Okteto subscription. Once enabled, it takes seconds to spin up your first agent fleet.

Final Thoughts: The Era of the Manager Nerds​

Agentic AI is not a trend. It’s a paradigm shift in how software gets built.

Some developers will become managers of fleets, designing workflows, tuning behavior, and scaling outcomes. Others will stay heads-down, solving big problems. Both need agent environments that run on their infrastructure and don’t get in the way.

At Okteto, we’re building for both. And we’re ready to help you start today.

You’re either stuck spinning up a full application stack locally every time you want to test something, or dealing with shared environments that break the moment someone else merges their half-working code. Neither approach scales well. Neither option is built for how fast you want your team to move.

Meanwhile, AI is speeding up the development loop. Teams are growing. Infra budgets are shrinking. Expectations are higher than ever. But somehow… your dev environment is still the bottleneck?

It’s time for a better way.

Yesterday’s Approach: Where Most Teams Have Started​

Traditional development environments usually follow one of these two models:

Local Development​

Spinning up services on your laptop used to work, until your app needed 20 microservices, a message queue, two databases, and a bunch of cloud-specific configs. Now you’re juggling Docker Compose files and spending hours replicating production just to fix a bug.

Shared Environments​

Everyone works in the same long-lived environment. These are easy to spin up, but delicate in use. One wrong push, and the whole team is debugging someone else’s mess. Testing is hit-or-miss. You never know what state you're in, and to top it off, they are likely costing your team more in productivity and dollars than you realize.

These environments can get teams started, but they don't scale well.

Today’s Standard: Full Ephemeral Environments​

Most modern teams moving to Kubernetes or Cloud Native workflows adopt a fully isolated dev environment per engineer. These environments are powerful. They’re realistic. And they let each developer move independently.

But as your team grows, keep an eye on how your environment strategy scales:

• Are boot times getting longer as your app complexity grows?
• Are you seeing infra costs rise with every new engineer?
• Are clusters starting to feel overloaded during peak dev cycles?

These are common signals that it's time to evaluate and design how you're managing environments at scale.

Full environments are essential for modern teams. And Okteto makes it easy to create and manage these environments, making them a great default starting point for most teams.

The Next Step For Scale: Ephemeral + Divert​

As teams grow and mature, they start looking for smarter ways to optimize their setup without sacrificing speed, flexibility or quality.

That’s where Divert comes in.

Divert is an Okteto feature that lets you spin up just the services you're working on, while connecting them to shared, long-running services like databases, queues, or backend APIs.

With Divert:

• Teams operate with a standardized, shared environment model with all production-like configs and policies
• As a dev, you only run the microservices you’re actively working on
• Traffic to shared services is seamlessly routed between both environments
• End-to-end testing still works with no mocks or patchwork
• The experience is transparent to developers, just like working in a full environment

This approach unlocks a flexible model:

• You keep the realism and independence of full ephemeral environments
• You reduce costs and boot times by sharing what doesn’t change as frequently
• You enable faster collaboration without duplicating infrastructure

When to Use Divert vs. Full Environments​

Choosing between full environments and Divert isn’t just about features, it’s about understanding where your team sits on the environment maturity curve. The needs of your team today, require a different environment from two years ago and will be something else two years down the road. That’s why having a flexible strategy is critical for modern teams.

• Full environments are simpler to adopt and work great for small teams, smaller applications and specific use cases
• Divert is more efficient at scale, but requires deeper knowledge of how services and data interact.

Final Thoughts​

There’s no one-size-fits-all in dev environments.

You need full environments for some workflows, and shared resources for others. Okteto gives you both with the flexibility to evolve as your team and architecture scale.

Start with full environments. Layer in Divert for optimized resource sharing and infra usage. This is the recipe to scale with confidence.

Modern software development has evolved quickly. We’ve embraced microservices, cloud-native infrastructure, and CI/CD pipelines. But there’s one area where many teams are still stuck in the past: development environments. In particular, giving developers realistic, production-like environments to test their changes end-to-end remains a huge bottleneck.

Let’s talk about why this happens and how giving developers self-service access to ephemeral environments is key to increasing the productivity of your engineering organization.

The Hidden Cost of Shared Environments​

In many organizations, realistic testing environments are scarce. Developers rely on a handful of staging environments to validate their changes end-to-end. These environments are expensive to maintain and quickly become bottlenecks.

The result is a familiar but frustrating pattern:

• Developers queue up to use staging
• Environments are hard to reset and often break due to leftover state
• Feedback loops are slow, and confidence in test results is low
• Teams lose hours (or days) debugging issues that stem from shared infra, not their code

This doesn't just affect developer happiness, it directly impacts throughput and business outcomes.

Quantifying the Problem: Exponential Cost Impact​

To put some numbers behind this, let’s start simply. For baseline purposes, you have developers earning roughly $100,000 annually - that's about $50 per hour. With just 10 developers each losing about 8 productive hours a week, you're already looking at $4,000 per week in lost productivity. But here's the catch: as your team gets larger, the environment becomes more crowded. More developers mean more traffic, more waiting, more downtime, and far more troubleshooting. Think of it like a traffic jam, the bigger it gets, the slower everyone moves. That's why the costs don't just increase linearly; they grow exponentially.

The Right Way: Ephemeral Environments on Demand​

Imagine a world where every developer can spin up their own development environment: on-demand, fully configured, and production-like. One command, and it’s live. One click and it’s gone.

These ephemeral environments are:

• Created automatically when needed
• Destroyed when no longer in use
• Consistent with production, eliminating environment drift and configuration mismatches.
• Integrated with your existing Development and CI workflows

They give developers a fresh, clean slate for every change. And the benefits are clear:

🔁 Faster Development Cycles​

No more waiting in line for a staging slot. Developers test immediately after they code. That translates into faster feedback loops, fewer context switches, and more momentum.

✅ Higher Quality Code​

Testing in a clean, isolated environment increases confidence in test results and reduces the risk of environment-specific bugs slipping into production.

🚫 Reduced Rework​

When bugs are caught earlier and in the right context, teams spend less time fixing regressions, patching hotfixes, or unraveling integration issues late in the pipeline.

💸 Lower Infrastructure Costs​

Instead of keeping large, expensive staging environments up 24/7, ephemeral environments spin up only when needed—and spin down automatically. You only pay for what you use.

📈 Accelerated Time-to-Market​

By eliminating bottlenecks and accelerating time-to-feedback, your team can ship value to customers faster with higher quality and less overhead.

The Platform Engineering Advantage​

Shifting to ephemeral environments benefits not only developers but also the broader platform engineering team:

• Reduces the operational burden of maintaining fragile shared infra
• Shifts environment ownership closer to developers (without giving up control)
• Scales seamlessly with team growth
• Demonstrates measurable impact on velocity and cost optimization

It’s a clear win for developer productivity and platform efficiency.

Conclusion​

The best teams remove friction from the development process. Shared staging environments were a necessary evil in the past, but they don’t scale with the complexity of today’s systems.

By giving developers access to self-service ephemeral environments, organizations can significantly reduce costs, improve productivity, and accelerate their delivery cycles.

Investing in ephemeral environments is not merely about developer experience. It's a strategic move toward increased profitability and innovation velocity.

Code lives in GitLab. Pipelines run in GitLab. But developers? They’re often stuck debugging broken local setups or juggling inconsistent environments.

This is where Okteto + GitLab changes the game.

GitLab: The Engine of Modern DevOps​

As a single platform for Source Code Management, CI/CD, and DevSecOps, GitLab helps platform teams consolidate tooling and enforce best practices across the org. It’s the backbone of efficient software delivery.

But even the best DevOps pipeline can’t fix a broken developer experience. If engineers are stuck troubleshooting local dependencies or waiting for staging deploys, velocity stalls.

Okteto: Production-Like Dev Environments in the Cloud​

Okteto gives developers instant, isolated, cloud-based development environments that mirror production —no manual setup, no drift. Environments spin up automatically from GitLab branches and sync changes in real time, so devs stay in flow, shipping faster and with higher quality than ever before.

For platform leaders, Okteto brings four key advantages:

• Fast inner dev loop: Okteto keeps developers in flow by giving them immediate feedback on code changes—without waiting on CI or staging deploys. Developers test in real environments, iterate rapidly, and ship faster.
• Standardization at scale: Okteto environments are declarative and version-controlled. You define your golden paths once and apply it org-wide.
• Reduced cognitive overhead: Developers no longer waste cycles on setup or troubleshooting local issues. They get an environment that just works, every time.
• Shift-left everything: Realistic environments mean more accurate testing, earlier feedback, and fewer surprises downstream. Less firefighting, more innovation.

Why GitLab + Okteto Works​

Together, GitLab and Okteto offer a streamlined, consistent experience from commit to deploy:

📦 Self-Service Developer Platforms​

Let developers create and destroy environments on demand, but with guardrails. Okteto abstracts the complexity while GitLab remains the control plane.

🧪Fast Inner Development Loops​

Developers write code, test it instantly in the cloud, and see live results without leaving their editor or waiting for CI to run. Ship value at the speed of the cloud.

🔁 Preview Environments for Every GitLab MR​

Integrate Okteto with Gitlab's Review Apps to get production-like live previews for every merge request without manual steps. Code reviews will become more thorough, collaboration will be more fluid, and confidence will be higher.

⚡ Streamlined CI/CD Workflows​

Pre-configured environments aligned with GitLab pipelines reduce flakiness and accelerate test cycles. You can even run the same tests from Gitlab CI and from Okteto using the same configuration, reducing CI cycles.

📉 Lower TCO of Internal Tooling​

Your platform team can focus on higher-leverage work by removing the need to maintain bespoke scripts or homegrown environment managers.

Developer Productivity Starts with the Environment​

If your developers are blocked by slow setup, broken local stacks, or inconsistent environments, your throughput suffers. GitLab gets your code to production and Okteto gets your team there faster.

The best platform teams don’t just optimize pipelines; they remove friction end-to-end.

Try It Yourself​

Modern platform teams are adopting GitLab and Okteto together to:

• Reduce cycle time across the SDLC
• Empower developers with cloud-native workflows
• Accelerate onboarding for new engineering hires
• Enforce standards without slowing anyone down

Ready to see what’s possible when your environments are as automated as your pipelines? Book a demo with our team.

From developer experience to estimated ROI, these badges reflect what real users are saying—platform engineers, developers, and QA teams who trust Okteto to simplify development at scale.

🏅 G2 Spring 2025 Badges Earned by Okteto​

Here’s where Okteto stood out:

• Users Most Likely To Recommend
• Best Estimated ROI
• Best Support (in 2 categories)
• Easiest To Do Business With
• High Performer (in 2 categories)

These awards are based on verified reviews evaluating everything from product ease of use to business value and customer support. We’re proud to be recognized but also for the feedback from users finding so much value and delivering results across the full developer lifecycle.

What Our Customers Are Saying About Developer Experience With Okteto​

“We use Okteto daily and it drastically shortened our cycles—everyone from QA to business stakeholders are now in the loop and can provide feedback before it hits our staging environment.”
— Leonid M., CTO

“The whole process is automated—we hit merge and never have to worry about it. It just works.”
— John C., Cofounder & CTO

“It provides a modern, smooth, easy-to-use interface... Beyond the tool is the fantastic, personalized support and engagement from the Okteto team.”
— Heath H., Lead Automation Engineer

“Today, engineers can spin up specific environments tailored to the areas of the product they need to work on, significantly improving development efficiency and reducing resource overhead. Our partnership with Okteto has been key in this transformation.”
— Ants K., VP of Product Engineering

Whether it’s setting up preview environments, eliminating local development setup pains, or enabling real-time feedback loops, our customers say it best: Okteto saves time, reduces overhead and cognitive load, and helps teams build with confidence.

Why G2 Recognition Matters For Ephemeral Development Environments​

We’re not just building a tool—we’re redefining how teams build software on Kubernetes. With Okteto, developers and platform teams can:

• Instantly spin up ephemeral, production-like dev environments on Kubernetes
• Eliminate manual setup and infrastructure bottlenecks
• Improve collaboration across QA, product, and security teams before code hits staging
• Boost developer productivity and accelerate iteration cycles

These G2 badges validate what we’re hearing every day: Okteto delivers a modern, automated approach to the development experience that drives results.

Thank You to Our Customers 💙​

To every customer who shared their feedback—we’re grateful. Your support powers our growth and pushes us to keep improving new areas of developer experience.

Want to see how Okteto can help your team ship software faster?
Explore our automated development environments or book a demo for a deeper dive.

Enter ephemeral environments – temporary, on-demand development spaces that enables teams to work smarter, not harder, by leveraging the flexibility of Kubernetes and cloud-native technologies.

Why Traditional Development Environments Fall Short​

For years, development environments have revolved around the developer’s laptop. While this approach has worked, increasing complexity has introduced limitations that slow down the entire software development lifecycle, resulting in:

1. Slow Onboarding: Onboarding a new developer can take weeks. They need to set up dependencies, configure their environment, and ensure compatibility – all before they can even begin writing code.
2. Testing Bottlenecks: Engineers often wait hours or even days for access to a staging or test environment, slowing down feedback loops.
3. Bugs in Production: Local environments can’t perfectly replicate production, leading to bugs that go unnoticed until they’re live.
4. Developer Burnout: An inefficient setup creates frustration, increases cognitive load, and stifles innovation, ultimately impacting team morale and retention.

These issues aren’t just a burden on large enterprises; they impact companies of all sizes. And the longer it takes to move from code to production, the higher the cost of rework, wasted resources, and missed opportunities.

What Are Ephemeral Environments and How Do They Work?​

Ephemeral environments are isolated, temporary deployments of an application in the cloud. Unlike traditional environments, they’re created on-demand and exist only for the duration of their intended use, such as testing a feature branch or running quality assurance checks. Think of them as disposable sandboxes—ready when you need them, gone when you don’t.

Ephemeral environments work by leveraging cloud infrastructure to create temporary, realistic development spaces that are provisioned automatically. Developers can create production-like instances of the application with a single command. This drastically reduces wait times, allowing every engineer to work independently in their own isolated environment.

Key Benefits of Ephemeral Environments for Development Teams​

By adopting ephemeral environments, teams can:

• Eliminate Bottlenecks: Developers no longer need to queue for shared environments. Instead, they have instant access to their own, personalized setup.
• Streamline Onboarding: New developers can hit the ground running in hours rather than weeks because environments are pre-configured and match production scenarios. No need for developer configurations.
• Enhance Collaboration and Feedback: Cloud-based environments allow the whole team to collaborate in real-time and catch issues earlier in the development process.
• Ensure Consistency Across Stages: Ephemeral environments can mirror the production environment across all stages – code, preview, test, staging – providing reliable testing grounds and minimizing discrepancies.
• Reduce Cognitive Load: Developers no longer need deep knowledge of Kubernetes or infrastructure setup, allowing them to focus on what they do best: writing code.

How Platform Teams Benefit from Ephemeral Environments​

While ephemeral environments improve developer workflows, they also provide significant advantages to platform teams by reducing operational overhead and enabling more efficient infrastructure management.

• Automated Environment Provisioning: Platform teams can eliminate the manual effort of setting up and managing development and staging environments by automating ephemeral environments.
• Scalability Without Infrastructure Bloat: Since ephemeral environments are created and destroyed on demand or through automation policies, they prevent unnecessary resource consumption and reduce cloud costs.
• Improved Security & Compliance: Temporary, isolated environments reduce the risk of configuration drift and security vulnerabilities, ensuring better compliance with industry standards.
• Standardized Developer Environments: By offering predefined, production-like environments, platform teams ensure that all developers work with consistent configurations, reducing variability and troubleshooting efforts.
• Faster Incident Response & Debugging: Platform teams can instantly spin up ephemeral replicas of production environments to diagnose and resolve incidents without disrupting live systems.

Common Use Cases for Ephemeral Environments​

Ephemeral environments are transforming how modern development teams operate. Here are some key scenarios where they provide the most impact:

Feature Development & Testing​

Developers can quickly create isolated environments for each feature branch, allowing them to work in parallel without interfering with the main codebase. This also ensures that QA teams can thoroughly test new features in production-like conditions before they are merged, reducing unexpected issues in later stages.

Preview Environments for PRs​

Engineers and product managers can access a live version of a pull request, making it easier to review and validate changes before merging into production.

Onboarding New Developers Faster​

Instead of spending days setting up local environments, new team members can start coding immediately with pre-configured, cloud-based dev environments.

Load Testing & Performance Validation​

Teams can spin up large-scale, disposable environments to test system performance under different conditions without affecting production resources. The New Stack adds that this method allows teams to scale testing more efficiently without being constrained by shared resources, ensuring faster iteration cycles and improved software quality

Customer Replication & Debugging​

Support and engineering teams can replicate customer-reported issues in an ephemeral environment that mirrors the customer’s setup, leading to faster debugging and resolution.

In a recent episode of the Cloud Native Testing Podcast, Okteto CEO Ramiro Berrelleza shared how companies use ephemeral environments not only for streamlined testing but also for better customer support and collaboration. Ephemeral environments are evolving beyond testing, becoming a foundational component of modern DevOps workflows.

Real-World Success Stories​

Companies like Yotpo and LaunchDarkly have already seen substantial improvements after adopting ephemeral environments:

• Yotpo: By transitioning to ephemeral environments, Yotpo’s developers reduced cognitive load and increased focus on product development rather than environment management.
• LaunchDarkly: Engineers went from weeks to nearly instant onboarding, fewer setup headaches, and increased productivity, all thanks to the flexibility of ephemeral setups.

For technical leaders, the message is clear: ephemeral environments can yield a significant return on investment (ROI). Block estimates they’ll save 500,000 developer hours through their DevEx efforts this year, which identified “instant developer environments” as one of the top strategic initiatives for the company. Simply put, ephemeral Environments free up developer time, reduce errors, and enable a more agile and responsive development process for companies of any size.

The Future is Ephemeral​

Embracing ephemeral environments represents both a technological and cultural shift. While the technical setup is crucial, the real change comes from aligning teams around a faster, leaner approach to development. By adopting this model, companies are positioning themselves to innovate faster and maintain a competitive edge, even with limited resources.

In a world where “doing more with less” is the new normal, ephemeral environments offer a path forward – a way to cut through the noise, reduce overhead, and empower your teams to do their best work. As cloud-native technologies continue to evolve, ephemeral environments may soon become the standard, providing developers the tools they need to innovate at the speed of modern business.

Today, having the right platform engineering tools in place isn’t just a “nice-to-have”—it’s a necessity. But navigating the platform tooling landscape is just the first step—making these tools work together in harmony is where the magic happens.

A unified tooling strategy helps your team move faster, collaborate better, and stay ahead of challenges, whether you’re working on platform engineering solutions, DevOps tools, or other critical systems. Tools that empower your team to manage infrastructure effortlessly, accelerate development cycles, and innovate without friction are game-changers.

But here’s the catch: even the most promising emerging ecosystems often come with gaps.

Integration issues, scalability roadblocks, and clunky user experiences can slow your team down when you need them moving fast.

The Platform Engineering Tooling Landscape: Considerations​

It’s an exciting time for platform engineering featuring tools and solutions that promise automation, developer productivity, and operational stability. But here’s the reality—assembling a cohesive tech stack is harder than it looks.

Why? Because:

• Integration Gaps: Tools often operate in silos, creating friction when trying to integrate them into a unified workflow.
• Scalability Issues: Some tools perform well in SMB environments but struggle at the enterprise level.
• User Experience: Developers want intuitive and easy-to-use tools that fit into their daily workflows, yet many solutions prioritize functionality over usability.

To build and drive adoption for a new platform, teams need tools that do more than function—they need solutions that unify workflows, promote collaboration, and scale with organizational growth.

21 Best Platform Engineering Tools​

The right tools can make or break a platform engineering strategy. Whether you’re scaling a startup or managing the complexities of an enterprise, these tools stand out for their ability to help platform teams design and implement scalable developer experiences.

Infrastructure Management Tools​

Terraform: As the cornerstone of Infrastructure as Code (IaC), Terraform has been defining how teams manage infrastructure for over a decade. By defining your infrastructure as code, Terraform ensures everything stays consistent across environments, reducing the risk of errors. Whether you’re managing a single app or scaling a multi-cloud environment, Terraform provides the governance and reliability teams need to stay efficient.

Pulumi: Unlike traditional IaC tools, Pulumi allows developers to use familiar programming languages like Python, TypeScript, or Go to manage infrastructure. This flexibility makes it a favorite among development teams looking for tighter integration between application code and infrastructure.

Crossplane.io: Crossplane.io enables teams to define and manage cloud-native resources using Kubernetes-native APIs. With Crossplane, platform teams can build custom resource definitions (CRDs) to standardize infrastructure provisioning while empowering developers with self-service capabilities.

kro (Kubernetes Resource Orchestrator) by AWS: New kid on the block, kro, is bringing a fresh approach to managing Kubernetes resources by turning complex configurations into reusable building blocks. kro’s controller takes care of the heavy lifting, figuring out the right order of operations and dynamically managing everything behind the scenes.

Development Environment Tools​

Okteto: Okteto delivers self-service Kubernetes development, test, and preview environments that mirror production. With a simple manifest, platform teams can offer single-click access to full environments with cloud resources, enabling new developers to be productive on day one.

Gitpod: A cloud-based IDE that automates development environments, Gitpod supports developers with prebuilt containers tailored to their projects. This is especially beneficial for developers and open-source contributors who want fast, disposable environments for quick tasks or contributions.

CI/CD Tools​

Harness.io: Harness has gained in popularity with its focus on simplicity and intelligence. It combines powerful automation with AI/ML-driven insights to make building, testing, and deploying code faster and more reliable. With features like continuous delivery, feature flags, and cloud cost management, this is a great platform for teams looking to simplify DevOps workflows.

Jenkins: Jenkins has been around forever (in tech years), and there’s a reason for that: it’s powerful, flexible, and endlessly customizable. If you’re managing complex pipelines, Jenkins is a solid choice. The downside is that it does often require extensive customization.

Dagger.io: Dagger reimagines CI/CD by offering a portable and declarative approach to building pipelines. With Dagger, teams can define their workflows as code using a single, repeatable configuration, making it easy to run pipelines consistently across environments—from local machines to CI/CD systems.

GitHub Actions: Already living in GitHub? Actions allow teams to automate workflows directly within their repositories. It’s an excellent choice for smaller teams looking to accelerate releases.

GitLab: It wouldn’t be right to highlight CI/CD tools without mentioning this powerhouse. GitLab offers an all-in-one platform that integrates version control, CI/CD pipelines, and DevSecOps workflows. With its robust automation capabilities, GitLab empowers DevOps teams to manage the entire software development lifecycle in a single interface.

Monitoring and Observability Tools​

Prometheus: In today’s world of Cloud Native development, everything moves fast. So, keeping an eye on your systems is critical. Prometheus, with its powerful query language and integration with tools like Grafana, ensures you’re never in the dark about your infrastructure’s health.

Honeycomb.io: Debugging distributed systems can feel like chasing a needle in a haystack. Honeycomb.io turns that haystack into a clear map of events, helping you visualize and troubleshoot issues in real time. Its event-driven approach allows teams to visualize and explore data in real time, pinpointing issues across complex architecture.

Datadog: Why settle for just metrics or logs when you can have it all? Datadog combines monitoring, logging, and tracing into one platform, offering complete visibility into your applications and infrastructure.

Security and Compliance Tools​

Snyk: Security shouldn’t slow you down. Snyk integrates directly into your workflows, helping you find and fix vulnerabilities in code dependencies, containers, and infrastructure configurations without disrupting your momentum.

Wiz: Great, you’ve made it to the promised land of Cloud - now how do you ensure cloud environments are secure? Wiz provides an agentless approach to identifying vulnerabilities, misconfigurations, and risks across workloads, containers, and Kubernetes clusters. By prioritizing critical issues, Wiz helps teams stay ahead of security threats and maintain compliance with minimal disruption.

HashiCorp Vault: Secrets management can be tricky but will become a necessity for many platform engineering teams. This tool securely manages API keys, credentials, and other sensitive information, giving you peace of mind that your data is locked down tight.

ARMO: Keeping Kubernetes clusters secure doesn’t have to be a burden for DevOps teams. ARMO makes it easy by seamlessly integrating into your CI/CD workflows to detect vulnerabilities, enforce security policies, and maintain compliance—all without adding friction to your team’s processes.

Cost Management Tools​

Kubecost: Managing Kubernetes costs can be a challenge, but Kubecost makes it simple by providing real-time insights into resource usage and spend across clusters. With Kubecost, teams can optimize workloads, identify inefficiencies, and take control of their cloud costs.

Okteto Resource Insights: Platform engineering teams use Okteto Insights to track environment usage trends, optimize infrastructure, and reduce unnecessary cloud costs by fine-tuning the resources allocated to your Kubernetes workloads. Ensuring resources are used efficiently can lead to uncovering opportunities to improve overall developer productivity and importantly find cost gains for organizations.

StormForge: StormForge simplifies the process of managing cloud resources with machine learning-powered optimization. By analyzing workload patterns, it identifies opportunities to reduce waste and improve performance, helping teams strike the perfect balance between cost and efficiency.

Closing the Gaps: Building a Unified Tooling Strategy​

The tools we’ve explored each represent a few key parts of the platform tooling landscape, but the real challenge lies in creating a cohesive ecosystem. A unified platform tooling strategy isn’t just about selecting the best individual tools—it’s about ensuring they work seamlessly together to support your team’s goals. Here are a few considerations for platform teams:

1. Meet developers where they are: Choose solutions, including DevOps tooling, that fit naturally into your workflows so your team spends less time troubleshooting and more time building.
2. Automation Is Your Best Friend: Automate repetitive tasks wherever possible to free up your team’s time for high-impact work. The less manual intervention needed, the smoother your processes will run.
3. Think Long-Term: The platform tooling landscape will continue to grow and evolve, so choose solutions that can scale effortlessly with your team’s growth and future needs.
4. Focus on Developer Experience: The best tools are ones your team will actually use. Tools should make developers’ lives easier, so prioritize options that simplify workflows and free up time for innovation.

A well planned approach doesn’t just smooth out the bumps in your process—it gives your team the confidence to tackle big challenges and deliver great results.

Ready to take the first step? We’ve put together a guide to start mapping your current platform landscape and DevOps tools, and pinpoint areas for improvement and investment.

At Okteto, our core focus this past year was on building features that directly solve critical challenges faced by platform engineering teams. We split our efforts into four main categories; enhance developer productivity, simplify cloud native development and Kubernetes workflows, improve security practices, and help organizations optimize their cloud resources. Below, we highlight some of the key innovations we’ve delivered and the actual impact they have for our customers.

Smarter Resource Management and Data​

We introduced Okteto Insights and the Resource Manager to give platform teams visibility into their resource usage. These tools enable infrastructure optimization and help reduce unnecessary cloud costs by fine-tuning the resources allocated to your Kubernetes workloads.

Okteto Insights includes dashboards to visualize product usage and behavior data such as developer usage, as well as infrastructure utilization and performance data like infrastructure and platform activities. Okteto's Resource Manager is designed to optimize CPU and memory resource requests for your Kubernetes workloads on Okteto. By analyzing the actual utilization of resources in real-time, the Resource Manager adjusts the resource requests for your pods automatically, ensuring they are appropriately configured without the need for manual intervention.

With better insights into usage and metrics, cloud-native teams can make informed decisions that lower infrastructure costs and optimize performance, ensuring that resources are allocated efficiently and effectively.

Accelerating Quality with Okteto Test​

Okteto Test was designed to seamlessly integrate testing into your development workflow on the Okteto platform. Whether you're running unit tests or end-to-end (E2E) tests, Okteto Test ensures an efficient testing experience before and after making a pull request. This ensures that code is tested in real-world conditions, reducing the likelihood of bugs and improving the overall quality of applications before they go live.

Okteto Test helps teams ship high-quality code faster. This reduces time spent on debugging and minimizes the risk of production issues, which translates into a better developer experience and faster time to market.

Expanding Access Through Google Marketplace​

By launching Okteto on the Google Marketplace, we’ve made it even easier for organizations to discover and adopt Okteto. This provides additional flexibility for large organizations by simplifying procurement processes. Teams can now purchase Okteto through the Google Cloud Marketplace, take advantage of flexible billing terms, and apply existing spend commitments or credits.

We are working on adding Okteto to AWS Marketplace in early 2025. If this is something you are interested in, please reach out!

Enhanced Security and Control​

Security is a priority for our customers. With Admin Access tokens, we’ve enabled teams to manage access to their Okteto clusters more securely and efficiently. This feature allows granular control over who can interact with resources, making it easier for platform teams to enforce security best practices.

We introduced updates to our Registry Credentials, Cloud Credentials, and we will be making environments rootless by default in upcoming months. We also introduced air-gapped installation for organizations that require a fully isolated network environment. This feature ensures that Okteto can be installed and operated without requiring direct internet access, providing an extra layer of security for customers with strict compliance or regulatory needs.

By improving credentials management and enhancing security protocols, Okteto gives security-conscious teams peace of mind that their environments are secure, helping them focus on development without worrying about breaches or unauthorized access.

Simplifying Cloud Native Development: Amazon EKS and OpenShift Integration​

We built Amazon (EKS) installation guides, made product improvements around installation, error messaging, support bundling and added OpenShift support to simplify the setup of cloud native development environments. Customers can now get up and running faster on platforms they already use, reducing setup time and operational overhead. This means teams can spend less time configuring environments and more time building the applications that drive business value.

Pushing forward with Platform Engineering teams in 2025​

As we look to the future, Okteto remains dedicated to helping platform engineering teams overcome their biggest challenges. From simplifying complexity of managing CI to enhancing teams ability to debug in real-time across distributed, cloud-native environments, we’re here to help platform and development teams remove friction in their workflows.

Ready to tackle some of your platform challenges? We’d love to chat!

Okteto CLI 3.0 will be shipped in early October and integrated into the Okteto Chart 1.25 release. There are some potential breaking changes, so please keep reading below to make sure your workflows aren’t affected by this update.

Our progress over the last 12 months leading to Okteto CLI 3.0!​

The main features we have released during this period are:

• Deploy on Remote: Do you need custom tooling to run the deploy commands of your Okteto Manifest? You can now define a container image to serve as the runtime of your deploy commands, eliminating all the dependencies on your local machine configuration to deploy your Dev Environments.
• Smart Builds: Are you tired of repeatedly building your container images? Smart builds detect repeated builds from other developers in your cluster and reuse them automatically, allowing you to deploy your Dev Environments in seconds.
• Okteto Test: Have you ever felt frustrated while troubleshooting a CI workflow? Say bye-bye to committing and waiting for minutes until CI fails. Okteto Test provides fast feedback and repeatability when running CI workflows on your local machine and on CI 😊
• Hybrid Development Mode: There are situations when running a service locally is faster than synchronizing code with a remote Development Container. Hybrid development mode enables you to run the service in development locally while keeping the rest of your application components on Okteto to take advantage of your local machine hardware.
• Okteto Logs: Have you ever tried troubleshooting your application and felt frustrated running several kubectl commands to find an error condition? okteto logs gives you a single command to obtain all this information without imposing Kubernetes cognitive load.

How can I try Okteto CLI 3.0?​

Okteto CLI 3.0 has been shipped in early October and is integrated into the Okteto Chart 1.25 release. Before upgrading to Okteto Chart 1.25, make sure your workflows aren’t affected by Okteto CLI 3.0. To do that, we recommend installing Okteto CLI 3.0 by using the following command:

curl https://get.okteto.com -sSfL

💡 Go back to the previous Okteto CLI version with: curl https://get.okteto.com -sSfL | OKTETO_VERSON=2.31.0 sh

Then, run okteto deploy and okteto up with your Okteto Manifests to ensure things keep working as expected.

On Windows

1. Download the Okteto CLI 3.0 Executable:
   • Visit the Okteto GitHub Releases page.
   • Download the Windows executable directly using this link: Download okteto.exe.
2. Move the Executable to a Preferred Location and add to your system PATH
   • To verify you’ve installed the CLI 3.0, you can run okteto version

To go back to the previous version, download the Windows executable for 2.31.0 and use it to replace the current executable.

Verify your rollback by running okteto version

Full list of breaking changes​

A major release is a great opportunity to remove deprecated functionality, help us increase the quality of our code base, and more suitable for future feature development. This is the full list of breaking changes in Okteto CLI 3.0:

• Commands no longer available: okteto init, okteto push, okteto stack, okteto login (replaced by okteto context) and okteto update (replaced by okteto version update).
• Okteto Stacks syntax has been removed in favor of Docker Compose syntax. If you are using the Okteto Stack filenames okteto-stack.yaml or stack.yaml, check out our guide to migrate from Okteto Stacks to Docker Compose.
• Local container registry credentials have less precedence than Okteto Registry Credentials. You can keep more precedence for your local registry credentials by setting the variable OKTETO_LOCAL_REGISTRY_STORE_PRIORITY_ENABLED to true in your terminal or as an Okteto Variable.
• Changes in flags for okteto deploy:
  • --build is removed. By default, images will always be built unless you specify --no-build to skip the build process
  • --f no longer supports pointing to a folder, only regular files are allowed.
  • Removed positional argument to deploy individual services from a Docker Compose file. This functionality is supported at the Okteto Manifest level.
• Changes in flags for okteto up:
  • --deploy will also rebuild the container images
  • --command is removed in favor of the syntax -- <<your command>>
    • For example okteto up api -- bash
• Support for devrc file is removed. devrc allowed developers to overwrite the Okteto Manifest with custom configuration.
• The commands okteto pipeline deploy, okteto pipeline destroy, okteto preview deploy and okteto preview destroy now default to --wait=true
• Drop support for Okteto Manifest v1. Follow our guide to migrate from v1 to v2.
• Flags --namespace and --context always take precedence over environment variables OKTETO_NAMESPACE and OKTETO_CONTEXT. namespace and context are no longer supported at the Okteto Manifest level.

Updates to GitHub Actions​

Each GitHub Action supports the following tags:

• latest: this is the version running the last stable Okteto CLI release
• v3: this is the version running the last stable Okteto CLI 3.x release
• v2: this is the version running the last stable Okteto CLI 2.x release
• main: this is our development version. Don't use this tag for production usage!

Finally, you can ping a specific Okteto CLI version in your GitHub Actions, for example, okteto/context@2.31.0.

Keep in touch!​

We understand that changes like these may require some adjustments to your workflows, and we’re here to support you every step of the way. If you have any questions or need assistance transitioning to Okteto CLI 3.0, please don’t hesitate to contact our support team.

Thank you for your understanding and continued support as we strive to enhance the Okteto experience for all users.

The Current Challenge: Visualizing and Testing Changes Pre-Merge​

While Dagger simplifies CI pipelines, it doesn’t inherently solve the problem of previewing changes in a realistic environment before they are merged. Developers frequently face challenges like:

1. Lack of Interactive Previews: Developers need a way to see and interact with their changes before merging. Traditional CI setups typically run tests but don't provide a live preview environment.
2. Environment Consistency: Ensuring that tests run in environments identical to production is critical for accurate feedback and the fastest workflow. Running code in pipelines often differs from production, leading to potential issues post-deployment.
3. Inclusive Feedback: CI workflows usually focus on developer feedback, leaving out crucial input from design, marketing, and product teams until changes reach staging or production.

Ultimately, these challenges all make it harder for teams to iterate and ship fast and lead to poor development experience within organizations.

The Solution: Insert Okteto Preview Environments​

By including Okteto Preview Environments into the CI process, DevOps teams can address these challenges by automating a shareable URL for each pull request, allowing reviews before merge. Code is deployed in your branch on an actual Kubernetes cluster using all the same configuration as production, ensuring you get the most reliable feedback on how your code would look when pushed to production.

This approach allows developers and stakeholders to interact with the application before merging, ensuring that feedback is gathered early and accurately. The consistency between the preview and production eliminates discrepancies, while inclusive feedback from all departments accelerates the review process and improves the overall quality of the code.

Integrating Okteto Preview Environments with Dagger CI/CD​

If you're already using Dagger to manage the CI pipelines for your cloud native applications, you can instantly start leveraging the benefits of Preview Environments as well. The main benefits you get are:

• Better DevX: Your team members can now see a working copy of their code changes before it even gets merged. This makes it easy to get feedback from others and iterate faster.
• Automated Testing: You can run your testing suite against these preview environment endpoints in your Dagger pipeline to be sure that your changes work as expected without having to wait for staging, test, or any other pre-prod environment. Dagger makes it very easy to integrate tests with Preview Environments using other modules like Cypress, etc. You can even write your own module for any testing tool you might use if it’s not available on the Daggerverse already.
• Broad Compatibility: Another great benefit of Dagger is that it runs on any CI engine. You can leverage the benefits of Okteto’s Preview Environments on popular CI providers/tools like GitHub Actions, GitLab CI, Jenkins, Circle CI, and all other providers Dagger supports!

How To Get Started with Okteto and Dagger​

To help Dagger users quickly adopt Preview Environments, we developed the Okteto Dagger Module. Here’s how you can get started:

• Explore the Module: Visit the Okteto Dagger Module on Daggerverse for detailed information.
• Check Out Sample Pipelines: Review our sample GitHub Action pipeline to see Preview Environments in action.
• Join the Community: Engage with us in the Okteto community to share your experiences and suggestions.

Conclusion​

Incorporating Okteto Preview Environments into your Dagger CI/CD pipelines transforms your development workflow by enabling pre-merge previews, ensuring environment consistency, and fostering more cross-department feedback. This integration not only enhances the Developer Experience but also accelerates your team’s ability to iterate and ship high-quality software efficiently.

Try it out today and experience the benefits of combining Dagger and Okteto for a best-in-class CI/CD setup and DevX.

The Need For Metrics​

Metrics are critical fuel for any platform team. Usage data enables teams to measure how developers are using the platform, what parts are loved, and what needs attention and improvements. More importantly, this data helps determine the platform team’s overall success in improving the DevX and ensures that the platform continues to evolve in ways that truly benefit its users. With this goal in mind, we launched Okteto Insights to help provide visibility to platform teams adopting Okteto as their development platform.

What Is Okteto Insights?​

Okteto generates a lot of data from developers using the platform, covering product usage, behavior data like developer activity, and performance metrics such as infrastructure utilization and platform operations.

Admin users can access this data through Okteto Insights via Prometheus Endpoints, enabling Okteto administrators to programmatically retrieve and analyze it. Subsequently, this data can be leveraged to create insightful dashboards using Grafana or similar tools to visualize platform usage patterns.

What Do These Metrics Tell?​

Okteto Insights sheds light on various crucial aspects of the Okteto platform. The metrics provide a comprehensive view of:

• The load and demand on pods and nodes, helping the platform team decide whether to scale the development infrastructure up or down.
• Developer usage patterns, which are key indicators of the degree of platform adoption.
• Utilization of preview environments, showing how often features are tested before full deployment.
• Trends in build and deployment times, which can highlight changes in application over time and the need for optimizations to speed up development cycles.

These insights can collectively guide strategic decisions which help the platform team improve the overall development experience with Okteto.

Try it out​

If you want to understand the impact and utility your developers are getting out of Okteto, you should definitely try Okteto Insights out. You can read the complete feature documentation here.

Start measuring and maximizing the success of your platform today!

In this article, I will delve into the key reasons why engineering leaders must invest in a platform engineering team to foster organizational success. Let's first start by understanding what platform engineering is.

What Is Platform Engineering?​

Platform engineering is transforming the way organizations approach software development, especially in the ever-evolving landscape of today. At its core, platform engineering focuses on providing robust and standardized internal tools and platforms that enable developers to concentrate on their primary task—writing and deploying code. By providing a suite of reusable tools, environments, and services, platform engineering significantly reduces the cognitive load on developers, allowing them to deliver value more efficiently. Let's see the benefits of platform engineering vs traditional DevOps workflow.

Accelerating Time-to-Market with Platform Engineering​

Being able to ship quickly is a crucial factor for organizations. The faster you can roll out new features, bug fixes, and updates, the more value you can provide to your users and customers. However, being able to ship fast requires proper enablement of your developers. Let's delve into the nuances of this argument next.

There are many things that can kill developer productivity. At the top of that list is likely the cognitive load that comes from constant context switching. In high-focus tasks like writing code, it is essential for developers to remain in their focus zone and work on what they do best without having to worry about other things. This includes tasks such as setting up development infrastructure and environments, spinning up test and staging environments, among other tasks.

When application developers have to switch from writing code one moment to working with cloud services and containers the next, it creates an unnecessary cognitive load and hampers productivity. They end up spending time learning and debugging tools like Kubernetes, Terraform, and cloud provider platforms like AWS, GCP, etc. This time could be much better utilized for writing code for the application and delivering value. This, in my opinion, is the biggest benefit of platform engineering.

Platform Engineering Teams: The Key to Developer Productivity​

This is where a platform engineering team comes into play. By packaging all the tools and resources that developers need under a unified platform which automates these productivity killing tasks, they make it easier for developers to focus on what they do best.

For example, Okteto is a development platform that allows developers to quickly create production-like development environments based on predefined configurations set by the platform engineering team. Similarly, there are service catalogs like Backstage that serve as a platform for developers to easily discover all the different microservices and applications within an organization. Ultimately, a platform aims to empower developers by providing them with the necessary resources and information, eliminating the need for constant context switching.

To summarize, if you want to deliver value to your customers quickly, you need to ensure that your developers can focus on what they do best without having to juggle a thousand other things. And this is where platforms truly excel!

Easier Security Compliance Thanks to Standardization​

When a platform becomes the streamlined way for developers to get things done, it means there are no more ad hoc decisions being made by developers for different tasks. With everything now maintained by the platform engineering team, it becomes much easier to ensure security and compliance across the organization. The platform team can define standardized processes and tools and abstract away the implementation details under the platform. This is something I feel platform engineering does better as compared to the DevOps way of doing things.

This means all dev workflows by default work just like how the platform team defined them, and everything is standardized. This makes it so much easier for organizations to comply with security policies and minimize the chances of a breach of security due to human error. Instead of trusting each developer to follow the security best practices (which many times they might not even know about!), the platform engineering team can bake them into the platform itself and ensure a uniform and secure system across the board.

Bonus Platform Engineering Benefit: Cost Optimization​

One of the often overlooked benefits of platform engineering is cost optimization. By automating tasks behind the scenes of the platform, it becomes easy to implement features like a garbage collector and auto scaling of resources and environments. These optimizations result in significant cost savings in the long run.

Let's consider Okteto's Garbage Collector, which allows platform engineers to define a time period for inactive development environments. After this period, the system automatically deletes these environments. This eliminates concerns about idle cloud resources that incur unnecessary costs each month. Additionally, the platform handles auto scaling of resources based on usage, ensuring that you only pay for what you actually use, rather than overprovisioned resources. You can find more information about this feature here.

Conclusion​

The narrative around Platform Engineering is, at its core, a story of faster development velocity, easier governance, and an effective use of resources. It's about abstracting and automating away the things that hamper developer experience and, in the process, achieving standardized and streamlined workflows.

For businesses seeking to invest in longevity, there's no better time than right now to give due recognition to this cultural shift and ensure that your development teams continue to function smoothly in the long run. Don’t just take my word for it, read about the success story at monday.com where they saw a 50% increase in developer velocity after investing in platform engineering!

Roadmap To Follow For Platform Engineering​

As a platform engineer, one of your main goals is to provide robust platforms that help the developers in your organization be more productive. To achieve this, you need a platform engineering roadmap that will guide your team towards success. Here are some recommended guidelines to follow when thinking about your dev platform:

1. Self-Service Environments: Just as businesses offer user-friendly portals to their customers, platform engineers should provide developers with the ability to independently access what they need. This reduces the cognitive load and reliance on learning and installing additional tools (such as Terraform, Docker, etc.) or depending on other teams. Developers greatly appreciate the ability to easily develop and test their applications. Empowering them to launch environments which allow them to do this, without the need for assistance from other teams or long wait times, can significantly enhance efficiency!
2. Golden Paths: In platform engineering, the notion of "golden paths" offers developers pre-defined workflows and solutions, akin to a customer service representative guiding customers through a seamless experience. By automating repetitive tasks like creating dev infrastructure and image builds and uploads, valuable time is saved and the risk of human error is reduced. This empowers developers to concentrate on their primary task of writing code, rather than being burdened by manual repetitive tasks. These pathways also assist the platform team in maintaining standardization and having governance over all the services provided. This becomes crucial in making sure you meet your organization's compliance standards!
3. Better Collaboration: Microservices-based applications are hard to develop as a team by default because of their distributed nature. Platform teams need to be able to provide developers with the tools and processes that enable better collaboration between different teams. This can include features like preview environments, shared environments for development, and efficient workflows to facilitate seamless collaboration among not only developers but also developers and other teams like marketing, design, sales, etc.

These are three things which we feel should be on your roadmap when approaching platform engineering. Starting a platform team can feel like a daunting task but if you break it down into these three areas it can start to feel approachable. It doesn't matter if you're building your own solution or adopting an existing one, you need to make sure that it fullfills these three needs: consumable in a self service manner, automate repetitive talks by providing golden paths, allow developers to collaborate with each other.

If you're able to provide these three things to your developers then consider yourself to be on the right way towards your end goal!

Benefits of Following Platform Engineering Principles​

Following the above platform engineering roadmap can bring a multitude of benefits to your organization as a whole. Just implementing the three things we discussed above can give the developers in your organization the following benefits:

• Enhanced Development Experience: Developers can concentrate exclusively on coding, free from the burden of operational and infrastructural complexities. This fosters greater job satisfaction, productivity, and overall workplace happiness. And everyone knows, happy developers write better code :)
• Lower Cognitive Load: By abstracting away the complexities of environment setup and streamlining workflows, platform engineers are able to relieve developers of the mental burden associated with these peripheral tasks. This allows them to focus their mental energy more effectively on creative problem-solving and coding, leading to higher quality work and innovation. The less they have to juggle between tasks the more energy they'll be able to give to existing ones.
• Faster Time-to-Market: With self-service environments, automated processes, and golden paths, developers can swiftly develop and test their applications. This results in increased development velocity, giving organizations a competitive edge. This often has a direct impact on customer satisfaction for companies.
• Cost Savings: By streamlining processes and automating tasks, platform teams can reduce the time and resources required for application development. This leads to significant cost savings for organizations in the long run. Having features like a Garbage Collector be a part of your platform can further help with minimizing savings.
• Better Collaboration and Teamwork: With better tools and processes, developers can collaborate more efficiently with each other. Additionally, platform features such as Preview Environments offer visibility into the development process for non-software development teams like product, marketing, sales, etc. This fosters stronger teamwork, effective communication, and ultimately results in better products for customers.

Conclusion​

In conclusion, following best practices in platform engineering can have a positive impact on your organization's overall success. By implementing this roadmap of self-service environments, golden paths and promoting collaboration, you can create a development experience that is efficient, streamlined and makes developers more productive.

You can get started reaping all the benefits we discussed from today itself! Okteto was built with these platform engineering principles in mind and allows platform engineers to easily create self-service environments and provide golden paths to their developers. Try it out today by signing up for our free 30-day trial.

Understanding the Evolution: DevOps versus Platform Engineering​

Historically, developers have been responsible for writing code and focusing solely on their applications. Once the code was written, it was handed over to operations teams for deployment. This separation of concerns made sense in a world where software was more monolithic and less complex.

However, with the advent of microservices, containers, and DevOps practices, developers started taking on additional responsibilities. They were expected to manage application builds, infrastructure, and more. This shift led to a blurred line between development and operations, often resulting in cognitive overload for developers. They were no longer solely focused on writing code, but also had to worry about infrastructure and deployment processes.

As developers embraced the new paradigm, they found themselves navigating a complex landscape of tools and technologies. They had to master containerization tools like Docker, orchestration tools like Kubernetes, and infrastructure as code tools like Terraform. This added an extra layer of complexity to their daily tasks, requiring developers to acquire new skills and stay updated with the latest trends in the rapidly evolving DevOps ecosystem.

I hope this historical context helped you understand the whole platform engineering vs DevOps debate. It should also make you appreciate the challenges faced by developers and the need for a more streamlined approach.

Platform Engineering Benefits: Facilitating a Focus on Core Competencies​

The rise of platform engineering addresses these challenges. One of the benefits of platform engineering is that there is now a dedicated team to act as an architect of shared infrastructure, tooling, and platforms for developers. By standardizing processes and providing consumable services, this team empower developers to focus on what they do best: writing code and delivering value.

In essence, a platform engineer needs to act as an enabler within the organization. By creating and managing a suite of consumable services that encompass everything developers require, platform teams dramatically reduce the cognitive load on developers. Developers can now access a standardized set of services for tasks like setting up dev and test environments, artifact building, etc., allowing them to concentrate primarily on coding. This is another way to compare platform engineering versus DevOps, since in the DevOps model developers were themselves expected to take care of a lot of these things.

Platform engineering tools not only streamline the development process but also benefits platform engineers by establishing standardization and governance across these services. The result is a more focused and efficient work environment for both developers and platform engineers which fosters innovation and fast shipping.

Adopting a Customer-Centric Approach: The Key to Excellence​

You can only start to reap the benefits of platform engineering when you have a deep understanding of the challenges faced by developers. Just as businesses conduct market research to identify customer needs and pain points, platform engineers must invest time and effort in understanding the daily obstacles developers encounter. Take the time to survey developers within your organization, familiarize yourself with their workflows, and see if they're able to focus on their core job of application development or not. Try to minimize or automate away any non-value-adding activities that distract them from their work and reduce their overall productivity.

The cornerstone of excelling in platform engineering versus DevOps lies in adopting this customer-centric approach towards developers. That in my opinion is the biggest difference between the two. Treating developers as your customers is all about active listening and understanding. By prioritizing their needs and experiences, you not only enhance your effectiveness as a platform engineer but also build a strong partnership with your developer colleagues. This alignment of interests can yield significant positive outcomes in terms of productivity, satisfaction, and the overall success of software teams within your organization.

Conclusion​

I hope this blog helped you understand the whole platform engineering vs DevOps paradigm better. With the right mindset towards Platform Engineering you can get significant improvements in developer experience. Read about one of our customers, monday.com, who saw a 50% boost in developer productivity by focusing on the right problems to solve!

I also hope this blog helped you provide a good starting point in your journey towards building a platform team. If you're still not sold on the benefits I would recommend reading our other blog on the benefits of platform engineering.

It's crucial to understand that this philosophy is not an isolated concept. Rather, it forms the foundation upon which the core tenets of platform engineering are built. The principles that guide exceptional platform engineering are, in essence, an extension and deepening of this customer-focused mindset.

In our next blog, I will talk about best practices when it comes to platform engineering. These practices include creating golden paths, self-serviced environments, and some other things which we will dive into next time :)

While the core developer features and experience continue to shape our platform, it's clear from our customers and community that Okteto's strength lies in serving cloud native teams and that Okteto is not a viable fit for individual developer use cases.

Over the past year, Okteto has transformed into a comprehensive platform tailored for platform teams automating modern development on Kubernetes. We've learned that our commercial road to success is switching targets and serving these platform and development experience engineering teams who then design and deliver high value to their internal customers, the developers.

Along with the product evolution, our product and engineering teams have invested an exceptional amount of effort in maintaining a free, multi-tenant tool. Challenges such as managing fraud and abuse by unauthorized users and crypto mining, security concerns in multi-tenant environments, and the misalignment in Okteto usage as a free hosting provider, have led to diverting our attention and time away from delivering critical value to our customers and users.

What's next?​

Because of these factors, we have decided to deprecate the free SaaS tier for individual accounts. On December 5, 2023 we stopped allowing new signups for the individual tier. Starting January 15, 2024 we will begin shutting down Okteto Cloud, the free tier of the SaaS product. We will be sending out a series of emails to affected users.

We remain focused and excited about delivering a great development experience to teams building cloud native applications and continue to work closely with platform engineering teams on increasing productivity and velocity and bringing joy to modern development. If you are interested in using Okteto’s platform, please reach out and we’ll help your team get started with Okteto Self-Hosted or Bring Your Own Cloud. You can also check out a free 30-day trial of our Self-Hosted offering of Okteto.

If you are ready to migrate your team to Okteto Self-Hosted or Bring Your Own Cloud, we will provide a license with 5 free users for the first year if you reach out before Jan 15.

A big thanks​

Once again, we extend our sincere gratitude for your ongoing support and commitment to Okteto. Your early adoption and enthusiasm have been instrumental in shaping the evolution of our platform. Together, we've pushed forward what modern development experience should be. Thank you for being an integral part of our community. We're grateful for your understanding, and we hope you'll continue building with Okteto in the future.

The Problem When Developing Modern Apps​

When approaching the problem we discussed above, organizations traditionally take one of these few approaches.

First is simply being unable to provide access to these resources. This case is farthest away from ideal because it means developers on your team just won't be able to develop properly. They would have to wait until staging to be sure that the changes they made are working or not.

The second approach is to teach developers how to create these resources manually. This isn't very ideal for two reasons:

• One, it involves developers learning different cloud providers and about their resources, thus adding to the cognitive load. Developers in many cases also don’t know how to configure things and how the infra is configured. This limits their ability to create production-like dev environments.
• And second, it is very time-consuming and cumbersome to have to repeat this process manually each time.

This is a problem people faced with their production infrastructure as well. And that is what led to the rise of Infrastructure as Code tools like Terraform. So what I want you to ask yourselves is, if you're already using Terraform scripts to create this infrastructure for production, why not use it for development as well? Now you might be tempted to just ask developers to run these Terraform scripts themselves. But that again suffers from more problems:

• It involves developers having some extent of Terraform knowledge and even installing and managing Terraform and the cloud credentials it needs on their own, which again adds to the cognitive load.
• It again, at the end of the day, is a manual process because developers need to run the scripts and take care of deleting things when they're done.

The first problem might be a big one from just a compliance and security perspective. Because you would need to ensure that you provide access to your cloud provider to developers in a secure way instead of them using any ad hoc credentials or IAM users/roles to create resources, thereby making managing things extremely tough in the long run. So what's the solution?

The solution is automating this problem away with Okteto. You can leverage your same Terraform scripts and automate this entire process with the help of Okteto. This means whenever a developer creates their development environment, the cloud resources will automatically be created for them using the right credentials that you, as platform engineers, have configured. Developers don't need to do anything themselves. In fact, they wouldn't even need Terraform installed locally.

On top of that, whenever they delete these ephemeral environments (or they remain unused for a fixed period), the resources will automatically get deleted for them. Pretty cool, right? This saves costs since you don't have to worry about resources running when nobody is using them.

If you would like to see this in action and learn about the value it provides, check out this webinar we recently did with our friend Richard, who is a HashiCorp Ambassador as well.

How To Set It Up​

The best part is that integrating Terraform with Okteto is pretty simple, thanks to Okteto External Resources feature. Check out this video, which walks through how you can do this in a few easy steps and automate the pains of developers away!

Conclusion​

As platform and devX engineers, you want to be able to provide the best workflows that make developers' lives easier. This involves giving them access to the resources and running environments they need without adding any additional cognitive load. With Terraform and Okteto, you can now automate the creation of development environments and access to cloud resources, making it a seamless experience for developers. This is a win for platform teams as well, as the access is now provided in a secure and compliant way, giving them complete governance over resources.

So go ahead and try out this feature with Okteto. You can access our sample app, which demonstrates using Terraform and Okteto, here.

To get started, you can sign up for a free 30-day trial of Okteto here! And if you have any questions or need help setting this up, don't hesitate to reach out to us. Happy automating!

Before automating environments for the ultimate modern development experience, platform providers (builders) need a vision and game plan. This guide aims to streamline the process of improving the velocity of development in your organization by building a better DevEx.

What is development velocity?​

Development velocity is the time it takes to complete building, testing, and releasing modern software products ready for customer usage. A product can be an entire cloud-native application, a new microservice feature, or a fix to a defect. The ability to maintain a continuous creative process and stream of high quality apps is the desired state of velocity for most software engineering teams.

Development velocity is a desired state and result of experiencing a continuous, high quality stream of creative value for the benefit of customers. It is measured across the development lifecycle including developers, test execution, QA, and running live in production.

It is also often confused with developer velocity. Developer velocity refers to an individual developer's time to build, test, and release their specific work, whereas development velocity encompasses the broader efforts and output of the entire team. Increased developer velocity is often a byproduct of an organization's enhanced development velocity.

Developer Experience (DevX or DevEx) has a key role to play in development velocity. If you're able to provide a great experience for your developers by giving them the right tools to be productive, an increase in development velocity is sure to follow.

What are the current roadblocks to development velocity?​

There is an automation gap between cloud-native development and production environments that significantly slows down creativity and development of microservices apps, and consequently, is getting in the way of delivering innovation into the hands of real customers. There is no tooling made available that removes the friction and toil associated with creating cloud-native applications.

The most exciting project in platform engineering today is the automation of a modern development experience. The experience designs a new abstraction interface and modern development stages for developers to automate the execution of cloud-native environments that are production-like. This self-service development experience is a critical foundation for speeding up the creativity and delivery of microservice applications, from development-to-production.

Development experience automation is the process of "productizing" a modern abstraction interface as the design centerpiece for unifying, executing, and governing cloud-native environments.

How to automate developer experience (DevX) and increase creativity?​

Cloud architects and production teams are deploying cloud-native infrastructure platforms like Kubernetes to improve on-demand service delivery, scalability, and the quality of service.  Now, platform teams are designing environments to mirror production environments and shift left the ability to preview, test and qualify features and microservices to development.

However, development teams must now reduce friction, shorten execution time, lower the complexity of modern app development and testing, and close the gaps between development and production environments. Using local platforms, DevOps pipelines, and scripted provisioning have lead to increased friction, development toil, and reduced velocity and confidence.

"The ultimate goal is to create joyful development teams that can increase innovation for their customers."

Designing a self-service DevEx​

The opportunity to automate environments in a self-service manner from dev-to-prod is now a reality. This is due to the new levels of abstraction and runtime architecture alignment resulting from the growing usage of containers, microservices, Kubernetes, and cloud-native infrastructure tools and automation.

Platform engineers can design a new interface that provides a self-service, end-to-end developer experience and an environment execution architecture that is more unified, automated, and governed than previous versions of local, siloed environments.

Using a self-service modern interface frees both platform engineers and developers from the need to build and maintain custom automation software, which makes more time available for automating developer experiences.

How taking a DevX first Approach enables Development Velocity​

Automating the end-to-end provisioning and de-provisioning lifecycle is just one aspect of achieving a modern DevX. You need to adopt an approach that focuses on bridging the gaps between developer creativity, application delivery, and full-stack application configuration administration. This design approach aims to standardize the user experience by using unified, intuitive, and automated concepts, functions, and lifecycle-specific workflows.  The goal is to make the need for  development environment administration totally automated and transparent.

With an automation platform, development-to-production environments can be managed without burdening developers, testers, and delivery engineering teams. By standardizing and modernizing the development experience, the interface and platform adoption increase the visibility, trust, and control of configured development-to-production environments for the entire development team. This allows "The Developers (i.e., the Consumers)" and "The Platform Engineers (i.e., the Providers)" to focus on increasing creativity, confidence, and collaboration. The result is increased development velocity and shipping modern apps.

How to plan for the DevX Consumer and DevX Provider​

DevEx Consumers (Users)

DevEx consumers (users) include application and container developers, test and QA engineers, extended product team members, staging and SRE engineers, and production engineers. They all require environments for development, delivery, and production. Consumers also include automation software / tools that require runtime environment deployments via APIs. For example, provisioning environments enabled with every pull request (PR) for test automation.

DevEx Providers

DevEx providers are the platform/devX engineering teams that design and implement platform automation to deliver execution environments that provide the next modern development experience across every stage of the modern lifecycle. These providers are responsible for both provisioning environments to their entire development and deployment team and engineering the next modern experience platform.

Summary​

This playbook is a valuable tool for platform and DevX engineers and architects who are aiming to close gaps that slow down progress towards achieving a higher velocity in the development-to-production modern lifecycle. If you're looking to dive even deeper into the topic, check out this panel discussion:

This exciting platform engineering practice has the potential to reach a new level of development usability, ease-of-work environment, and environment automation for an entire modern, cloud-native experience. The guide highlights the need for:

• Creating a New Level of Abstraction (The Missing DevX Interface). This presents an opportunity to automate environments with a modern development experience from development-to-production.
• Taking a DevX-First Approach. Automating environments with the next modern development experience involves more than automating the end-to-end execution environment lifecycle.
• Planning for both Development Experience Consumers (Users) and Providers.  The “provider" of environments are the platform engineers.  DevX consumers are the internal customers.

The ultimate platform engineering vision is a joyful development team continuously innovating for their team and customers.

To learn more, get these playbooks:​

In this article, we will explore those (and some additional) tips in greater detail which will help you enhance build times and, consequently, expedite the launch of your team’s development environments!

Understanding How Image Builds From Dockerfiles Work​

Before we delve into enhancing build times, it would be beneficial to understand how Dockerfiles instructions are utilized by a build service (whether it's Okteto's build service or Docker running locally) to construct images. Each instruction in your Dockerfile gives rise to an image layer. Layers help optimize work and conserve bandwidth. These layers are cached and do not require recomputation if things don't change. This means that if you change one line in your Dockerfile, only the layers after that point are regenerated. The rest of the previously built image remains as is. Now that we have this foundational knowledge about how layer caching for Dockerfiles works, let's see how we can leverage it to achieve faster build times.

Best Practices for Writing Efficient Dockerfiles​

Don't Copy Large Irrelevant Folders​

To optimize the image build process, it's recommended to use a .dockerignore file. This file allows you to exclude irrelevant files and folders, reducing the time required to transfer your local files to the build service.

For instance, if you're working with a node app and copying the application code to the container, you can exclude copying the local node_modules folder to the container. This is because the node_modules will anyways be regenerated when you run npm install in the container. By doing so, you can improve the efficiency of the build process.

For more detailed guidance on using the .dockerignore file, you can refer to the official documentation here.

Try Minimizing the Number of Instructions in Your Dockerfile​

As mentioned earlier, in a Dockerfile, each instruction plays a role in forming a new layer within the image. To optimize the efficiency of building the image, it is recommended to minimize the number of layers by combining multiple commands into a single RUN instruction. This can be achieved by utilizing the && operator and ensuring that unnecessary files and dependencies are cleaned up within the same RUN instruction. By embracing this approach, you can significantly expedite the process of building images, resulting in faster and more efficient builds.

Arrange Your Instructions Properly​

As we learned above, Dockerfile instructions are cached as layers. When making changes to an instruction, only the subsequent layers will be regenerated. This presents an opportunity to strategically order our instructions, ensuring that we avoid rebuilding unchanged layers. To achieve this, it is recommended to arrange Dockerfile instructions based on their frequency of change. Place the most stable and least frequently changing instructions at the top of your Dockerfile, while volatile or frequently changing instructions should be placed at the bottom. Here is an example of the recommended order of instructions:

1. Install the necessary tools for building your application.
2. Install or update library dependencies.
3. Generate your application.

By optimizing the order of instructions, we can improve the efficiency and speed of the Dockerfile build process.

Leverage Cache Mounts​

Rebuilding the same layer for each image build can be a time-consuming process. However, with cache mounts, you can store intermediate layers from your Dockerfile and reuse them across multiple builds. Cache mounts work by mapping a specific directory within the container image's build context to a directory on the host system. This mapped directory becomes a storage space for intermediate files and dependencies. By utilizing cache mounts, you can avoid recreating these layers during each build, resulting in significantly reduced build times. If you're interested in learning more about using cache mounts with webpack/nodejs, check out our tutorial here. Additionally, you can find a list of cache folders used by various programming languages and frameworks by following this link.

The following two recommendations for enhancing image builds are specific to Okteto's Build service.

Increase CPU/Memory Resources​

During the installation of Okteto Self Hosted, you have the option to configure the CPU and memory resources allocated for the Okteto Build service. This can be done by modifying the buildkit section in your Okteto helm values file. For example, the following configuration reserves 1 CPU and 4 GB of memory for the Okteto Build service, with a limit of 2 CPUs and 8 GB of memory:

buildkit:
  resources:
    requests:
      cpu: 1
      memory: 4GB
    limits:
      cpu: 2
      memory: 8GB

Please note that the performance of the Okteto Build service can be influenced by the type of processor it runs on. Different virtual machines (VMs) may have processors with varying capabilities. To enhance performance, you can configure the Okteto Build service to run on a dedicated node pool with a high-speed processor. This can be achieved by using the tolerations.buildPool section in the Okteto helm values.

Furthermore, for further optimization of performance, you can scale the Okteto Build service instances based on CPU utilization. This can be done either by configuring more instances with buildkit.replicaCount or by utilizing buildkit.hpa to implement a Horizontal Pod Autoscaler based on CPU utilization.

Configure Better Storage​

Choosing the right storage for the Okteto Build service is a crucial configuration setting that can greatly enhance image build speed. Since image builds require intensive I/O operations, opting for SSDs instead of standard disks can have a significant impact on build performance. You can configure the storage class of the Okteto Build service by setting the buildkit.persistence.storageClass field. Additionally, the buildkit.persistence.size and buildkit.persistence.cache fields allow you to adjust the size of the storage and cache folders for Okteto's Build service.

Conclusion​

In conclusion, the ability to expedite the image build process plays a significant role in enhancing the overall development experience. By minimizing the number of instructions, arranging them properly, leveraging cache mounts, and optimizing resources and storage, you can realize notable improvements in your build times and efficiency. Okteto's Build service, with its flexible configuration options and dedicated resources, is designed to further streamline this process. We encourage you to explore and leverage these strategies in your development workflow and experience the difference. So why wait? Give Okteto a try today and elevate your development experience!

What Is the Catalog​

The Catalog feature empowers platform engineers to pre-configure a list of applications directly from the intuitive Okteto web interface. As a result, developers gain effortless access to their applications with all the correct configuration settings already applied when they launch a development environment from the Catalog. This convenient functionality streamlines the process of accessing different versions with different configurations of applications, eliminating the need for developers to manually configure anything themselves. It helps platform engineers have better governance over the environments, making sure all applications are configured in a consistent and secure way that is compliant with all your organization's policies.

The Value It Provides​

By pre-configuring Catalog entries, platform engineers can toil from the lives of developers so they can focus on what they do best: writing code and creating value! This saves time that would have traditionally been wasted by developers in trying to get the correct configuration and apply it to their environments.

Consider the following example: your application relies on a RDS database that needs to be provisioned on your cloud provider or you maybe you need to get a secret from Vault. While Okteto will automate the actual processes (checkout our External Resources feature!), it still requires the appropriate credentials. Depending on individual credentials or multiple ad hoc user roles created by developers isn't ideal, as they might lack the correct permissions or be forgotten, posing security risks. As a platform engineer, you've established a single role with the necessary permissions to be used for all development needs of this particular application. The Catalog feature allows you to add these credentials as environment variables, ensuring they are included in each developer's environment in a secure way while keeping the scope specific to the app launched from the Catalog.

Just like this example, there are multiple use cases where you need standardization and governance over the configuration that developers use as part of their environments. And the Catalog shines in these scenarios: it seamlessly facilitates governance and standardization for development environments. It allows you, as the platform admins, to predefine the options available to the developers on your team, so that they don't need to spend time configuring their environment settings manually, and can instead focus on creating value.

By empowering platform engineers with granular control over the developer experience, Okteto enables teams to accelerate their development process and deliver high-quality software with utmost efficiency. Benefits for Platform Engineers:

• Pre-configure catalog entries to reduce developers' time to get to the coding phase.
• Eliminate concerns about misconfigurations by developers when launching development environments.
• Provides greater control over the developement experience by ensuring that the deployment environment is pre-configured as intended.
• Ensures standardization across all developer environments by making sure every environment is running with the same configuration as intended.
• Facilitates easy governance of applications and versions by allowing to specify the exact branch for each catalog entry with the correct environment variables already set.

How It Works​

Configuring the Catalog to display different applications with different configurations based on your requirements is a straightforward process. By accessing the admin interface in the settings, you only need to complete a few fields to add a Catalog entry.

• Name (required) - Provide a unique and recognizable name for your catalog entry. If you're adding multiple versions of the same application, specify the configuration differences.
• Repository URL (required) - Include the URL to your Git repository.
• Default Branch - Specify the default branch to be used if no specific branch is mentioned when launching a development environment. Developers will still have the option to change this when launching a development environment from the Catalog.
• Manifest Path - Specify the relative path to your Okteto manifest file if it's not located in the root of your repository. This is particularly useful if you have multiple Okteto manifests for your application based on your use case.
• Environment Variables - Configure the necessary environment variables for your application using key-value pairs. Each environment variable will be injected into the containers running the application and any development containers launched by developers.

That's it! This is all the configuration required to add an entry to the Okteto Catalog. Once you're finished, save the changes and the developers on your team will see the newly added entry when launching a development environment from the Catalog.

Summary​

In conclusion, the Okteto Catalog is a feature that empowers both platform engineers and developers, facilitating pre-configurations of applications and significantly reducing the time to dive into coding. It ensures standardization across all developer environments, eradicates worries about misconfigurations, and removes friction from the development process. With a seamless workflow, Okteto enables teams to accelerate their development process and deliver quality software efficiently.

We highly encourage you to explore this feature out youself. Why not take advantage of our free trial and see firsthand how the Catalog can simplify your development processes? Sign up for our free trial today and let Okteto take care of the rest. Happy coding!

It is common in today's landscape to build microservices-based applications that leverage resources like RDS databases, storage buckets, etc from different cloud platforms. Consequently, it becomes imperative to grant developers access to these resources during the development phase. Failing to do so would mean expecting developers to code in an unrealistic environment, which often leads to difficulties and introduces bugs.

However, teams frequently encounter challenges in efficiently and effectively implementing this practice. Developers are often burdened with manually configuring resources themselves, relying on makeshift bash scripts or constantly seeking assistance from the platform team. This not only wastes valuable time, but also creates a subpar development experience, as any dependency on the platform team by developers inevitably leads to delays.

To tackle this challenge, platform engineers should prioritize automating the process. This will empower developers to effortlessly provision self-service environments that also include any cloud resources required by the application. In this article, we will delve into how this can be facilitated effortlessly with the aid of Pulumi and Okteto.

What is Pulumi?​

Pulumi is an open source infrastructure as code tool that allows you to define, deploy and manage cloud resources on any cloud provider using popular programming languages like Python, TypeScript, Go, etc. This means that instead of replying on hacky bash scripts or typical configuration manifests, platform engineers can use the languages they are already familiar with to define the infrastructure for developers. Another benefit is that since developers are already familiar with these languages it is easier for them as well to understand and make changes as needed. Pulumi also provides a consistent workflow across different clouds including AWS, Azure, and Google Cloud Platform, making it a versatile tool for any team.

What is Okteto?​

Okteto is a cloud-native automation platform that empowers platform engineers to automate the modern development experience. It enables them to effortlessly create self-serviced, production-like development environments for developers. With Okteto, developers can easily replicate their production environment, including all necessary cloud resources. This eliminates the need for manual resource configuration or reliance on the platform team, as developers can have their own self-service development environments. Our recent launch of "External Resources" introduces a new feature that allows platform engineers to define the provisioning and deprovisioning of any cloud resource as well during development.

How Pulumi and Okteto Work Together​

Pulumi and Okteto seamlessly gel together to automate the creation of development infrastructure for microservices-based applications. Okteto's "External Resources" feature allows you to utilize any existing Pulumi configuration you have for production for creating the development infrastructure as well. Let's explore this further by examining the sample app I have prepared.

If you check out the app, you'll see that it's a todo list app with a backup feature. When you hit the "Save" button, all your current todos get saved in an S3 bucket.

Before diving into the code, to make this app work, you have to define the following Okteto Secrets on your dashboard:

The first three are for Pulumi to communicate with your AWS account and create resources. The last one is the Pulumi access token needed to create the stack and communicate with Pulumi cloud.

If you take a look at the code, you'll see that the Pulumi configuration for creating the S3 bucket is in the pulumi-aws-s3 folder, specifically in the index.ts file. I personally used TypeScript to write the code, but the cool thing about Pulumi is that it supports multiple languages, so feel free to use whichever language you're comfortable with!

// index.ts

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// Define Pulumi config variables
const config = new pulumi.Config();
const bucketName = config.require("bucketName"); // You can set this in your Pulumi config

// Create an AWS S3 bucket
const todosBucket = new aws.s3.Bucket("todos_bucket", {
    bucket: bucketName,
    forceDestroy: true,
});

// Export the bucket name for reference
export const bucketNameOutput = todosBucket.id;

Here, we have a crucial requirement: the "bucketName" needs to be passed in via config values. Remember this, as it will become relevant later on. Now, let's dive into our Okteto Manifest and explore further!

When using Okteto, all the configuration for your development environment is stored in a single file called okteto.yaml. A typical okteto.yaml has three sections:

• build: This part tells how to build images for different services in your application.
• deploy: Here, you specify how Okteto deploys your application to set up your development environment.
• dev: This section has the configuration for development containers for each of your microservices.

We won't dive into all the details of the entire Okteto manifest for this application in this blog. Instead, let's focus only on the Pulumi relevant sections. If you want to learn more about how the Okteto manifest for this application was written, you can check out this other blog.

If you check out the first command in the deploy section, you'll see that's where all the magic happens for automating the creation of the bucket with Pulumi:

# okteto.yaml

...
- name: Create the AWS S3 Bucket
    command: |
      set -e
      cd pulumi-aws-s3
      resourceName="${OKTETO_NAMESPACE}-todolist-pulumi"
      
      pulumi stack init "${OKTETO_NAMESPACE}"
      yarn install
      pulumi config set bucketName $resourceName
      pulumi up --yes

      # create the URL for the Pulumi Dashboard
      pulumi_about_json=$(pulumi about --json)
      fully_qualified_name=$(echo "$pulumi_about_json" | grep -o '"fullyQualifiedName": "[^"]*' | awk -F'": "' '{print $2}')
      stack_url="https://app.pulumi.com/$fully_qualified_name"
      
      s3Dashboard="https://s3.console.aws.amazon.com/s3/buckets/${resourceName}"

      # make the values available to the following steps and the dashboard
      {
        echo "OKTETO_EXTERNAL_S3_ENDPOINTS_BUCKET_URL=$s3Dashboard"
        echo "OKTETO_EXTERNAL_PULUMI_ENDPOINTS_STACK_URL=$stack_url"
        echo "S3_BUCKET_NAME=$resourceName"
      } >> "$OKTETO_ENV"
...

The script is pretty straightforward to understand. All we need to do is navigate to the folder containing our Pulumi configuration and execute the commands as usual to create the resources. One useful trick here is leveraging the ${OKTETO_NAMESPACE} variable. It allows us to generate a unique name for the stack we create part of each each development environment. This variable is automatically populated by Okteto with the name of the current namespace where the developer deploys the application.

After that, we generate the URL for the stack on the Pulumi cloud dashboard using some clever bash techniques. Another important point to note is that once all the commands are executed, we export the bucket name, S3 dashboard, and Pulumi dashboard URL to the ${OKTETO_ENV} variable. This special variable allows us to reference the exported values in subsequent commands and set up external resources. If you're interested in learning more about configuring External Resources with Okteto, please refer to our documentation.

If you look at the commands after this step, you’ll see that we proceed by creating a secret using AWS credentials. This will allow our application code to establish communication with the newly created bucket and deploy the microservices component of our application. Make sure to also review the destroy section in the code, which functions similarly to deploy, but is specifically responsible for deleting the bucket and associated stack when a developer is terminating their development environment. This step is crucial in ensuring that no unused buckets are left behind.

Seeing It In Action​

Once you have prepared your Okteto manifest and added the AWS credentials and Pulumi access token as Secrets in your Okteto dashboard, you are ready to deploy the application. It is worth noting that as Platform Engineers, Okteto also offers the option of setting these Secrets at a cluster level, eliminating the need for each developer to log into any cloud provider console. When it comes to deploying the application, you can make it available by preconfiguring it as part of the Catalog of applications. For the purpose of this tutorial, we can simply use the Git URL option:

Notice how Okteto seamlessly handles the execution of Pulumi configuration and the creation of the S3 bucket. But that's not all, the developer dashboard also provides direct access to the S3 console and Pulumi stack dashboard. Furthermore, I've incorporated READMEs to provide information about the bucket and Pulumi dashboard. You can add any product-specific configuration here. This approach greatly simplifies onboarding for new developers by consolidating all the necessary information in one convenient location.

Conclusion​

And that's it! This is how simple it is to use Pulumi with Okteto to automate the creation of any infrastructure your application requires and provide developers with the necessary access during development. It is crucial to provide developers with a realistic environment that automates the creation and deletion of application resources, and both Pulumi and Okteto excel at this task. With Pulumi, you can write the infrastructure configuration in languages familiar to both platform engineers and developers. Meanwhile, Okteto takes care of automating the creation and deletion of this infrastructure. If you found this article interesting, why not try deploying the sample app and witness it in action for yourself? Get started by signing up for a free trial of Okteto!

Problems Teams Run Into When Building Apps​

Effective collaboration is absolutely essential for shipping fast. However, when it comes to applications with a microservices-based architecture, there are certain obstacles that can hinder this process.

In a distributed architecture, each microservice operates independently and communicates with other services through APIs. This poses a challenge as it becomes difficult for team members to understand the entire system at once. Additionally, as each service can be built using a different technology stack, it becomes challenging for team members to communicate effectively and understand the code written in different languages.

Therefore, when developer David is working on microservice A and needs assistance or a change in microservice B, they typically have two options:

1. They can ask developer Tom, who is knowledgeable about microservice B, to make the necessary modifications. This process involves Tom first pulling David's changes, making their own changes, and then pushing them for David to pull again. As you can probably imagine, this is quite inconvenient and time-consuming, resulting in a poor overall development experience.
2. Alternatively, they can request Tom to engage in pair programming and guide them through the code changes via synchronous communication. It is indeed a commendable approach, although it can be challenging to consistently execute due to factors such as time zones and availability.

As you can see, collaborating on a team for a microservices-based application can be incredibly challenging. The good news is that Okteto helps address and overcome these types of problems!

How Okteto Makes Collaborative Development Easier​

Okteto is a cloud-native development platform that speeds up the development of applications with a microservices architecture. Okteto allows developers to provision self-service development environments where a copy of the entire application they want to work on is deployed for them automatically on a K8s cluster. Each developer works in their namespace, and the code changes they make get reflected live on the endpoints shown to them on their Dashboard as soon as they hit save.

How does Okteto facilitate collaborative development? There are two features that make this possible. The first one is Live Endpoints, which you can learn more about in our other blog post. In this blog, we will focus on the second feature: "Sharing Namespaces!”

When a developer shares their namespace with another developer, they instantly gain access to the deployed application, complete with all the necessary settings and security configurations. This also encompasses any infrastructure, metadata, logs, and deployment information that have been created. This is incredibly beneficial as it eliminates the need for the second developer to set up their development environment whenever they want to assist someone. What's even more fascinating is that once two developers share a namespace, they can each launch a development session for different microservices simply by executing okteto up.

If you're not familiar, okteto up launches a remote development container that synchronizes code between developers' local machine and the cluster. This means any changes developers make locally are instantly reflected at the live endpoints. By sharing a namespace, developers can collaborate in real time, tackling the same bugs or adding new features. Each developer has the freedom to make changes to any individual microservice, with those changes immediately available to other team members to see at the endpoints. Just imagine the boost in productivity when developers can iterate quickly without the need to commit or pull code, or go through the entire build process to see each other's changes. Once developers are satisfied with their overall changes, they can commit their work to the same branch or pull request. This streamlined workflow makes a significant difference in productivity and collaboration and allows teams to ship value faster.

Conclusion​

Collaborative development plays a vital role in the success of any organization when developing microservices-based applications. With Okteto, platform engineers can empower developers to collaborate in real-time, eliminating delays. By removing time-consuming processes like committing and pulling code to see each other's changes, Okteto enables teams to focus on efficiently building high-quality applications. It provides the means to iterate and ship rapidly. So why not try and experience the transformative power of enhanced collaboration in your team? Sign up for our free trial today!

What Is the Garbage Collector?​

Firstly, let's demystify this cool sounding term - Garbage Collector. If you're picturing a physical bin truck rummaging through your Kubernetes cluster, you're not far off the mark. Except, this truck is virtual, and its job is to smartly scale down applications during periods of inactivity. This ensures your cluster isn't bloated with unused resources, keeping your costs manageable.

The beauty of Okteto's Garbage Collector is that it's fully automated, so you don't have to lift a finger. Gone are the days of meticulously tracking which developer's environment is utilizing unnecessary resources while they're on vacation, and constantly reminding them to discard it. The Garbage Collector effortlessly handles these tasks, granting you peace of mind and valuable time to focus on other crucial responsibilities. This powerful feature benefits both Platform Engineers and Developers in multiple ways:

• Platform Engineers are relieved of the burden of continuously monitoring developers' environments and manually shutting down unused ones.
• Developers are freed from the cognitive load of remembering to destroy their environments once they've completed their work.

With Okteto's Garbage Collector, efficiency and productivity are maximized, allowing everyone to thrive.

How It Works​

The Garbage Collector in Okteto operates through two configurable policies:

1. The first policy determines the duration of inactivity required to scale all Kubernetes resources in a development or preview environment to zero, effectively putting the namespace to sleep.
2. The second policy specifies when the environment should be completely destroyed, including all Kubernetes and external resources associated with it.

Configuring the sleep duration before destruction offers the benefit of allowing developers to effortlessly resume their work without the need for redeployment. Okteto simply wakes up their environment by scaling up all their Kubernetes resources to their specified values.

You might be wondering what qualifies as inactivity. According to the Garbage Collector, an application or its resources are considered inactive if a developer hasn't performed any of the following actions during the specified inactivity period:

• Upgrading or redeploying via the UI or command line.
• Launching a development container with okteto up.
• Deploying the latest version of their code using okteto deploy.

There are a couple of ways to wake up an environment that has been put to sleep. Developers can do this either through the user interface (UI) or via the command line interface (CLI). Another great feature is that if any of the endpoints associated with the development or preview environment receive traffic, Okteto will automatically wake up the environment. This comes in handy when developers share the URL with someone on their team for testing or feedback, and that person or team accesses it after a few days. The garbage collector will ensure that the environment goes to sleep when there is no activity, but as soon as someone accesses that endpoint, it wakes up again.

How Can You Configure It​

If you're aiming to optimize your cloud usage and reduce costs, consider configuring the garbage collector for your Okteto installation. You can find detailed steps on how to do this in the accompanying video.

For more information about this feature, please refer to our documentation.

Conclusion​

In conclusion, managing infrastructure costs associated with Kubernetes can be quite a challenge. However, with Okteto's Garbage Collector, you can smartly automate resource management, scaling down applications during periods of inactivity, and ensuring your cluster isn't running with unused workloads. This not only saves costs but also improves efficiency, allowing Platform Engineers and Developers to focus on more important tasks. So why wait? Start optimizing your cloud usage and cut back on unnecessary expenses by configuring the Garbage Collector for your Okteto installation today! For detailed steps on how to do this, refer to our accompanying video and documentation.

In this article, we will explore how you can leverage existing Helm Charts for your applications to spin up cloud native development environments for the developers on your team with the help of Okteto.

What Okteto Can Do for You​

Okteto empowers platform engineers to automate and streamline the modern development experience, by enabling provisioning of self-service dev environments for developers that closely resemble production. These environments cater to all stages of the development lifecycle, from coding until deployment.

By deploying applications for development on Kubernetes and automating the provisioning of any necessary additional resources, Okteto bridges the gap between dev and prod. If your applications are already packaged as Helm Charts, you can effortlessly leverage them to create dev environments for every developer and stage across the lifecycle. This ensures two things that make a significant impact on the speed of the development experience:

• Developers have the ability to work in a realistic production-like environment and not waste time configuration environments. By utilizing the same helm charts for both spinning up development environments and deploying applications to production, you ensure that the development team operates in an environment that closely mirrors the production setup. This eliminates the occurrence of bugs and security vulnerabilities that often arise due to configuration discrepancies between development and production. Say goodbye to late-stage surprises in the software development lifecycle.
• Developers are freed from the cognitive load of setting up these environments and worrying about managing Kubernetes. With Okteto's manifest-driven development environments, once platform engineers write all the configuration for creating a developer environment, developers simply need to log into their Okteto instance and click the launch button. This eliminates the need for them to do anything else to get things up and running. It also ensures they don't have to deal with Kubernetes themselves and spend time learning it.

Okteto comes with a ready-to-use Manifest for effortless platform automation, allowing you to easily define, automate, and govern all your environments. Let's explore how we can create an Okteto Manifest to set up modern development environments for a todo list application that has already been packaged as a helm chart.

Prerequisites​

Before diving into writing the Okteto manifest, let me provide some details about the application we'll be working with. This will help you draw parallels with your own application and make it easier for you to write your own Okteto manifest.

Our sample todo list application consists of three microservices placed in one repository:

1. A React Frontend (client) responsible for the UI.
2. A Node.js Express (server) backend that communicates with the UI and the database.
3. A Postgres Database (db) used to store the todos

Within the directory for each service, you will find a folder named chart that contains the helm chart for deploying the respective service. It is important to note that in the deployment.yaml, the container image for the client and server service is kept configurable instead of being hardcoded. Pay close attention to this detail as we will come back to this later.

# oktetodo/client/chart/templates/client-deployment.yaml
...
spec:
      containers:
        - name: client
          image: {{ .Values.image }}
          ports:
            - containerPort: 3000

This is crucial because it provides you with the flexibility to pass different versions of the container (such as prod or a branch) while maintaining the same manifest, rather than being stuck with a fixed hardcoded image that was pushed to your image registry weeks ago. The best part is that Okteto automates the image building and pushing steps, freeing developers from these tasks. We will delve into more details on this topic later when we explore how we pass the built image to these deployments.

Writing the Okteto Manifest for Helm Packaged Applications​

Now that you're familiar with the application's appearance, let's move on to creating our Okteto Manifest. This manifest encompasses three key sections that configure your development environments and the experience:

1. Build: This section outlines the instructions for building images for various services within your application.
2. Deploy: Here, you define how Okteto deploys your application, setting up your development environment.
3. Dev: This section contains the configuration for remote development containers for each of your microservices.

The Okteto manifest offers numerous options to customize the behavior of your development containers. However, for simplicity's sake, let's explore a simple Okteto Manifest for this application to start with.

build:
  server:
    context: server
  client:
    context: client
deploy:
  - name: Deploy the DB
    command: helm upgrade --install db db/chart
  - name: Deploy the Node.js Backend
    command: helm upgrade --install server server/chart --set image=${OKTETO_BUILD_SERVER_IMAGE}
  - name: Deploy the React Frontend
    command: helm upgrade --install client client/chart --set image=${OKTETO_BUILD_CLIENT_IMAGE}
dev:
  server:
    command: bash
    sync:
      - server:/app
  client:
    command: bash
    sync:
      - client:/app

In the build section, we define the location of the Dockerfile for each of our microservices. This allows Okteto to build container images using the latest code from the repository when developers launch their development environments. We use the context parameter to specify the folders where the Dockerfile for each microservice resides. Additionally, you can utilize the dockerfile key to precisely indicate the exact location of the Dockerfile.

The deploy section is where we execute the Helm commands to deploy our application's Helm charts to the Kubernetes cluster used for development. Remember our earlier discussion about not hardcoding the container image name in the deployment YAMLs for our application's microservices?

Here, we define values for those container images. With Okteto, you can reference the images it builds in the build step within the deploy section using the $OKTETO_BUILD_SERVICENAME_IMAGE variable. To reiterate, the benefit of this approach is that the development environments are always set up with the latest code, rather than relying on older images that were built and pushed a long time ago. And like we discussed earlier, all the image building and pushing is handled by Okteto so developers don't have to worry about anything.

In the dev section, we define the configuration of the dev containers for each of the microservices. The command key tells Okteto what command to run by default when developers replace the running container for the service with a dev container by running okteto up. And the sync key tells Okteto what folders on your local machine to sync with the folders inside the container. You would usually sync where your service's code lives locally to the working directory you specified in the Dockerfile for your service.

That's it! You've completed all the necessary configuration to make your Helm packaged application ready for development on Okteto. You can try running okteto deploy from the root of your cloned repo to see if everything is working as expected. Once you've done this, you can make your application available for cloud native development to your developers by adding it to your Okteto Catalog.

Please note that if you wish Okteto to automatically generate endpoints for your application services, you will need to include the following annotation in your application's ingress YAML file:

annotations:
    dev.okteto.com/generate-host: "true"

You can read more about this here in the docs.

Conclusion​

In this article, we explored how easily you can prepare your Helm packaged applications for cloud native development using Okteto. This approach offers numerous platform benefits, such as unified, automated, and governed environments throughout your modern software delivery lifecycle. If you're interested in learning more about the advantages Okteto brings to your organization's development experience, be sure to check out our Platform Features.

If you're convinced that enabling a modern, cloud-native development experience for your team is the way to go, sign up for our free self-hosted trial and get started today.

Running Things Locally Isn't Practical for Modern Development​

When dealing with just a couple of containers running simple microservices, developers might not encounter any issues. However, as they scale up the number of microservices or run more demanding workloads, even the most powerful development machine will start experiencing bottlenecks. This is especially true for modern cloud-native applications we develop today. They typically consist of 10 to 50 different microservices, which is impractical to run locally. Not only does it slow down development, but restarting or spinning up everything again severely hampers productivity.

This is Not How You Run Containers in Production​

One significant issue is that running containers with Docker Compose on local machines differs from how it's done in production. Instead of directly running containers, production environments leverage Kubernetes resources like Deployments or StatefulSets. Consequently, developing locally with Docker Compose means working in an environment that deviates from production. This discrepancy increases the likelihood of bugs that are difficult to identify, such as misspelt environment variables or other similar issues. To ensure stability and avoid unexpected surprises upon deployment, it is crucial to develop in a realistic environment.

Environments Aren't Reproducible​

When developers launch their application using `docker-compose up`, they cannot launch another instance of the application to experiment or try out a different version or commit. Technically, they could rename things and then run them again, but not only is that inconvenient, it also significantly impacts the performance of the local machine. Consequently, the developer's creativity and freedom become restricted.

Sharing Work is Tough​

After implementing a feature or bug fix for the application, sharing it with someone on the team instantly and effortlessly becomes a challenge. Engineers need to commit and push their changes, and then someone else on the team has to pull them and run `docker compose up` to see the updates. If any further changes are requested, they have to repeat the entire process. This inefficient iteration process significantly slows down the velocity at which developers can deliver code. Additionally, this approach excludes team members from other departments such as product, sales, and marketing, who may not have the expertise to run Docker on their local machines. As a result, feedback from these teams is delayed in the software delivery cycle. However, with Okteto (as we'll soon explore), this feedback can be provided much sooner, streamlining the entire development process.

End to End Tests​

While Docker Compose is useful for bringing up all the services of your application locally, it doesn't replicate the realistic environment of production. As a result, running end-to-end tests on your application using Docker Compose may not yield the expected results. Furthermore, only the developer running the application locally can test it, making it difficult to share endpoints for testing with other teams.

How Okteto Fixes These Problems and Improves the Docker Compose Workflow​

Okteto takes your Docker Compose application and translates your application services into Kubernetes resources, deploying them on a cluster. This ensures that developers can begin development in an environment that closely resembles production. Additionally, by not running any containers locally, the local machine's resources are not constrained, regardless of the demands of the application. What's even better is that developers can deploy their application, or different versions of it, to different Okteto Namespaces, allowing for multiple copies. This approach treats each environment as ephemeral, enabling them to quickly spin up new instances as needed.

Okteto solves another pain point by creating endpoints instead of providing access to your application on localhost. These endpoints reflect live changes you make to your code, enabling you to easily share your work and receive feedback from your team. No need for developers to commit their changes or for other team members to run Docker on their machines. Moreover, these endpoints allow you to run realistic E2E tests on your application. If you'd like to learn more, check out this article.

Trying Out Okteto!​

Running your Docker Compose applications on the cloud with Okteto is a breeze. Sign up for our self-hosted free trial here. Once you have Okteto installed on your cluster, check out this video to learn how to get your Docker Compose applications up and running with Okteto!

How Organizations Have Tried to Keep Up​

The most common approach involves setting up a shared cluster, allowing developers to deploy and test their applications before moving them to production. Although organizations may use different terms like "staging environments," "preview clusters," or "testing clusters," they essentially serve the same purpose. It may appear promising on paper, but in reality, it falls short. Let me explain why.

• Limited clusters can lead to waiting times as teams have to take turns using them. This can cause delays in fast shipping, as one team's use of a cluster prevents another team from accessing it.
• Shared environments also carry the risk of one team's changes affecting another team's project, potentially causing unexpected bugs or system instabilities. Additionally, resetting the application and environment after each team's usage to start anew can be a time-consuming task.
• Moreover, assuming that developers possess the necessary expertise in Kubernetes for application deployment and troubleshooting is unfair. This expectation also adds to the cognitive burden on developers, diverting their focus from working on the application itself.
• It is crucial to alleviate this cognitive burden on developers. Yet, the alternative should not be a constant reliance on Platform or DevOps engineers for support. Always having to depend on another team member inevitably leads to delays and slows the delivery cycle.

When these issues are combined, they result in a bad development experience. This not only causes dissatisfaction among developers and platform engineers but also hampers productivity.

While it may seem like granting each developer access to their own dedicated cluster is a viable solution, it is not a practical approach. It can incur significant costs for an organization and still encounter the same issues mentioned earlier. So, what does the ideal solution look like?

How Okteto Helps Boost Productivity and Provides a Great Development Experience​

Okteto addresses this challenge by enabling platform engineers to unify and automate the provisioning of self-serviced ephemeral environments for developers. These environments deploy the application on Kubernetes and allow developers to develop and test it there directly. There's quite a lot to unpack in that first statement. Let's explore the details:

• Unified: Okteto unifies development and production environments, bridging the gap between the two. With Okteto you can spin up development and preview environments using the same manifests you use to deploy to producion, ensuring developers on your team are always wotking in realisitic environments. This minimizes bugs and enhances security.
• Automated: Using Okteto, platform engineers can describe everything about how a development environment should be provisioned in the Okteto manifest. This means once this manifest has been created, they no longer have to do anything manually to deploy the application for developers on Kubernetes and spin up dev environments.
• Self-Serviced: With Okteto, each developer gets access to as many namespaces as they need in a Kubernetes cluster, allowing them to effortlessly deploy, develop, and test any application they want at the click of a button - whenever they want, without having to rely on DevOps engineers to do any provisioning. Additionally, it automatically puts these namespaces to sleep when they are not actively being developed, ensuring optimal resource utilization.
• Ephemeral: The environments provisioned by Okteto are designed to be ephemeral. After completing their work and merging the code, developers can delete the environment and launch a new one with the latest commits. This eliminates the need for developers to manually keep their environment up to date with the latest code, as is often required when developing locally. This also makes it easier for developers to do experiments and try different things out fast. With the ability to maintain multiple environments in different states (including long term testing and different branches in development), developers now have the flexibility to iterate and innovate with ease. With Okteto, developers can effortlessly spin up a new environment based on the exact commit and version of the application they want.

It is these features that make it a better option than having a cluster that gets shared among different teams. Platform engineers can simply install Okteto on a cluster and then give access to their developers and get rid of all the problems we discussed earlier.

The cherry on top is that you also get a bunch of other useful features. With Okteto, development teams can experience the ultimate "shift left" approach. Okteto eliminates the need for developers to wait until they have pushed all their commits and cut a release to test their code on a production-like Kubernetes environment. Okteto exposes endpoints after deploying your application, which allows you to see the changes of the code you write as soon as you hit save. This is great for testing things as you develop instead of having to wait till you've committed and pushed your code. Additionally, it provides the reassurance that your changes won't cause any issues when you do push them, as you're developing in an environment identical to production. If you're interested in delving deeper into this topic, I recommend checking out this other article.

Conclusion​

Developing and testing cloud native applications has always been complex. Traditional methods bring pitfalls - shipping delays, system instabilities, and reliance on DevOps and cloud expertise. Okteto changes the game! It automates the provisioning of self-served ephemeral Kubernetes environments, eliminating the need for sharing clusters and waiting for other teams. Developers can spin up Kubernetes-based dev environments with a click! But that's not all. Okteto offers the ultimate "shift left" experience. Develop and test your code in real-time, in a production-like environment, without waiting to commit and push. Exciting, right?

If you're interested in seeing firsthand the impact of Okteto in boosting organizations’ developer productivity, take a look at our case study on monday.com. Discover how Okteto played a pivotal role in accelerating their developer velocity by an impressive 50%!

So what are you waiting for? Try Okteto today and experience the difference firsthand!

We completed an independent audit, with the support of Strike Graph, confirming Okteto's controls related to our information security practices, policies, procedures and operations met the rigorous SOC 2 standards for security, availability, processing, integrity, confidentiality, and privacy as developed by the American Institute of Certified Public Accountants (AICPA).

What Does SOC 2 Compliance Mean for You?​

SOC 2 is a technical audit designed to ensure that service providers securely manage your data to protect the interests of your organization and the privacy of your customers. By achieving this compliance, we have demonstrated that we have reliable and effective controls in place to safeguard your sensitive data.

In addition, SOC 2 compliance gives you confidence that Okteto is dependable and secure. It means that our solutions are built with security measures to protect your data from unauthorized access and use. Moreover, it demonstrates that Okteto takes data security seriously and is dedicated to keeping customers' trust and loyalty.

Your Trust, Our Priority​

At Okteto, we understand the trust you place in us when you entrust us with your critical data. We value your security and prioritize your privacy above all else. We thank you for choosing Okteto and assure you that we will continue to serve you with the highest standards of security and trust.

"At Okteto, we are deeply committed to providing a secure and reliable platform for our customers," said Ramiro Berrelleza, CEO of Okteto. We're proud to have successfully achieved this compliance and will continue our commitment to providing a secure platform and processes for our customers. With SOC 2 compliance, you can trust that Okteto is the right choice for your cloud native development needs."

While we take a moment to celebrate this achievement, we understand that maintaining and enhancing our security posture is a continuous journey in guiding our customers to building world-class development experiences for their organizations. We will continue to invest in robust security measures and prioritize transparency in our processes.

Thank you for being a part of our journey. Here's to many more milestones together!

What Does ArgoCD Actually Do?​

GitOps principles advocate for the use of Git repositories as the sole source of truth for application infrastructure and configuration. The concept revolves around storing all application-related files and manifests in a Git repository and using it as the central management hub for deployments. ArgoCD aligns with these principles by treating the configuration stored in a Git repository as the desired state for the application deployment, effortlessly deploying it to the specified target environment. What sets it apart is the inclusion of a Controller that continuously monitors the deployed application, ensuring synchronization with the manifests in the repository. In case of inconsistencies, ArgoCD empowers you to reconcile the differences through a single command or the click of a button.

Using ArgoCD for application deployment offers several benefits:

1. It maintains an up-to-date documentation of your application's deployment configuration in a version control system.
2. Rollbacks are as simple as reverting a commit, making it easy to undo changes.
3. It enables effortless modifications to deployments simply by merging pull requests.
4. It monitors the cluster to ensure that the deployed application aligns with the manifests in the git repositories, maintaining the desired state accurately.

As you delve into the rising popularity of ArgoCD, it becomes evident that its appeal is no surprise. However, it prompts an important question: if you're already leveraging ArgoCD for production deployments, why not extend its usage to manage your development deployments as well?

Why Integrate ArgoCD with Okteto​

In the industry, it has been widely believed that exactly replicating production environments during development is impractical, mainly due to cost, resource, and technological constraints. This notion became even more daunting with the shift towards distributed architectures and cloud services, as complexity continued to rise. Microservices and containerization have heightened the significance of bridging the gap between development and production. The complexity of microservice-based applications amplifies the likelihood of issues arising in production if not caught early on. But fear not, there is a solution: Okteto.

Okteto empowers platform engineers to automate the modern development experience by provisioning self-serviced production-like dev environments. These environments are for all stages of the dev lifecycle: from coding, until deployment. Okteto comes with ready-to-use Manifest and platform automation to make environments easy to define, control, and govern.

These environments deploy applications on Kubernetes and provision any additional necessary resources. If you're already using ArgoCD to manage your production deployments, it can seamlessly integrate with Okteto. This means you don't have to put in extra effort to recreate your production configuration. This approach ensures a single source of truth for both production and development configuration. And the benefits of ArgoCD, such as easy deployment changes through PR merges and seamless rollback options, extend to the development phase as well.

By leveraging Okteto's capabilities, you gain a faster inner loop in your development workflow. With Okteto, you can make changes to your code and test them quickly, without the need for committing to the repository right away. This allows you to iterate and validate your changes faster, ensuring a smoother development experience. Once you're satisfied with your changes, you can commit them, triggering the ArgoCD deployment logic, and exercise your deployment workflow as intended. This combination of Okteto and ArgoCD provides the best of both worlds: the speed and flexibility of Okteto's fast inner loop development, and the reliability and consistency of ArgoCD's GitOps model tied to commits and deployment logic.

By embracing the Okteto Experience and aligning your development and production environments, you can bridge the gap and create a unified, modern development experience for your team.

How to Use ArgoCD with Okteto​

Now that you recognize the value of using ArgoCD for your development environments as well, let's explore how you can achieve this with Okteto. When utilizing Okteto, all the configuration for your development environment resides in a single manifest known as okteto.yaml. A typical okteto.yaml consists of three sections:

• build: This section specifies how to build images for different services as part of your application.
• deploy: Here, you define how Okteto deploys your application to set up your development environment.
• dev: This section contains the configuration for development containers for each of your microservices.

As the name implies, the deploy section is where we leverage ArgoCD to deploy our application to the development environment, mirroring the production setup. If you have prior experience using ArgoCD for production deployments, you are familiar with the typical flow:

1. Running argocd app create to create your application.
2. Running argocd app sync to fetch manifests from the specified repository and deploy them to your Kubernetes cluster.

We will follow this exact process in the deploy section of our Okteto manifest. To demonstrate, we have created a "Hello, World!" Go server. You can find the code and detailed instructions in the repository here. Upon examining the deploy section in the Okteto manifest, you will notice the following commands:

deploy:
 - argocd app create simple-go-server --repo https://github.com/rinkiyakedad/simple-go-server.git --path k8s --dest-server https://kubernetes.default.svc --dest-namespace $OKTETO_NAMESPACE
 - argocd app sync simple-go-server

For the argocd app create we specify the location of our manifests by providing the --repo and --path flags. You should replace these with the location of your application manifests.

As the name suggests, the --dest-namespace flag tells ArgoCD which namespace to deploy your application to. Since we want this namespace to be the one that the developers specify when running okteto up we use the $OKTETO_NAMESPACE environment variable here. The installation job automatically populates this variable with the namespace you specify when running okteto up (or your default dev namespace if you don’t specify anything).

This is the only configuration that platform engineers need to do in order to use their production manifests for development environments. ArgoCD will ensure that each developer's environment matches the state specified in the manifests from the designated repository.

While the example application is a single microservice and assumes that ArgoCD and Okteto are installed in the same cluster, the core concept of using ArgoCD with Okteto remains the same: adding your ArgoCD deploy commands to the deploy section of the Okteto manifest. Regardless of your specific configuration, this approach holds true!

Conclusion​

In this article, we explored how ArgoCD enhances the practices of continuous delivery by introducing GitOps into the workflow. We examined the benefits it offers through its approach of treating Git as the source of truth and continuously monitoring and reconciling the deployed application state with the one specified in Git repositories. Additionally, we discussed how ArgoCD, together with Okteto, simplifies the replication of production infrastructure during development. We delved into the advantages of this approach and examined a simple application that demonstrated how easily it can be accomplished.

In conclusion, integrating ArgoCD with Okteto can significantly streamline your modern development flow, ensuring that your development and production environment configurations are aligned seamlessly. By applying the same ArgoCD commands in the Okteto Manifest that you use for production deployments, you automate a standard, unified modern environment for the developers in your team. Remember, a well-structured and consistent development environment is a key foundation for successful modern app delivery.

Tools like ArgoCD are increasingly prevalent in the Kubernetes production ecosystem. That's why it's crucial for platform teams to utilize these very tools to seamlessly bridge the gap between development and production for their developers. Okteto not only provides platform teams with an easy, ready-to-use modern development experience but also enables them to unify development and production environments.

To explore the full potential of our platform, sign up for our free 30-day trial!

May highlights​

• Okteto 1.8 Chart Release
• Change to ingress architecture that affects customers using their own ingress-controller
• Okteto CLI 2.16 Release
• Support for Kubernetes 1.25
• Dropped support for Kubernetes 1.22

Before you upgrade​

Okteto 1.8 includes a change in the ingress architecture. If you're using your own ingress controller instead of the ingress-controller embedded with Okteto chart, please checkout the updated section about "How to use your own ingress controller".

New features & improvements​

Updated the Okteto CLI to version 2.16​

The latest version of the Okteto CLI includes several new features and some bug fixes. You can find a more thorough overview of what's new in versions 2.15 and 2.16 in our documentation link below.

Added support for Kubernetes 1.25​

As part of our goal to maintain N-2 version support for Kubernetes, we've now added support for v1.25 to remain aligned with cloud infrastructure providers and the regular channel releases from the CNCF and Kubernetes community.

Added an installation guide to the Okteto UI for Self-Hosted customers​

We've added an in-app experience to the Okteto Admin UI showing the main steps in the Okteto installation process. You now have a source of truth within the Admin UI to gather necessary access credentials or other information to get Okteto installed within your environment even faster than before.

Each step in the guide is optional and can be skipped if it does not apply to your situation and provides documentation to help complete the step to ensure success with the process.

Destroy External Resources from the Okteto UI​

You can now manually destroy External Resources from the Okteto UI that you provisioned as part of your deploy configuration, in the Okteto manifest, to ensure those resources don't remain active and idle when development of your application is complete.

Added additional icons for External Resources​

We've added additional icons to External Resources to improve the developer experience when interpreting the resources that are part of an application in Okteto. New icons include:

• AWS
• GCP
• LaunchDarkly
• MongoDB

Catalog items now sorted the same in admin and developer views​

Previously the two Catalog modals were sorted differently. Now both the admin and developer views should be defaulted sorted in the same way: alphabetically.

Support added for Bitbucket personal repositories​

We've improved the integration with Bitbucket to now support personal repositories. This gives customers an additional option to bring code repositories into Okteto for faster development.

Persistent namespaces can no longer be put to sleep by admins​

We've removed the option for admins to sleep a namespace that had been set to Keep Awake previously. This ensures that when a namespace is intended to persist garbage collection it cannot still be put in a sleep state and cause a confusing experience for developers of that namespace.

Breaking changes​

Changed default value for buildkit's service session affinity​

This value has changed to None by default and will break your Okteto experience if you do not make a change to your buildkit configuration.

To keep using ClientIP as sessionAffinity you must set service.sessionAffinity: Client IP in your buildkit configuration.

See a more detailed list​

For a more detailed list of improvements, bug fixes, breaking changes, and deprecation notices please see our documentation.

In this article, we will examine how development teams traditionally share their work across the organization, the problems they encounter, and how switching to Okteto can solve these issues and unlock greater productivity for developers.

Problems With Current Methods of Sharing​

Traditionally, if you're a developer who has just written code for your microservices-based application, getting feedback from someone can be a tedious process. Typically, it involves the following steps:

• Commit and push your code
• Wait for CI processes to ensure your code hasn't broken the application
• Your team member clones the code
• They build and run the application

Each of these steps takes time and slows down the inner development loop, making it difficult to receive fast feedback and iterate quickly. Additionally, these steps assume you're only seeking feedback from other developers. If you need to share changes with the design or product team, the process becomes even more complex, as they may not know how to build and run the application and even what environment to use for that.

So, how can we optimize for fast feedback loops and improve this process?

How Okteto Simplifies Sharing Changes and Getting Feedback​

Okteto is a development experience platform that automates both the experience and the environment. Its goal is to simplify development and make collaboration a breeze when working on modern applications. When developing applications using Okteto, developers are provided with endpoints where they can access a version of the application deployed just for them, specifically for development purposes. Any changes they make to the code will be reflected live at these endpoints as soon as they hit save, without having to wait for a build or deployment process to complete. See it in action for yourself!

With Okteto, the complicated process of showing your changes gets reduced to just two steps:

1. Saving your work
2. Sharing the endpoint shown on your dashboard with any team member

This makes collaboration extremely simple, as these endpoints can be shared with anyone in your organization to give them a preview of what you’ve been working on and get feedback. The platform takes care of provisioning full-stack environments for everyone so nobody has to do any configuration or create any additional environments to see the changes.

Enable Sharing By Default in the Experience​

Developers need to be provided with the right tools for development to make collaboration easier​

Whether you are working on a small project with just a few team members or a larger project with dozens of developers, Okteto enables platform engineers to automate modern environments that make it easy for developers to share and collaborate as part of the development experience. This allows developers to get feedback from their peers and collaborate seamlessly.

In addition, Okteto provides a secure environment for sharing and collaborating across the entire software development lifecycle. Platform engineers can control who has access to these live endpoints, ensuring that their intellectual property is protected at all times. This is particularly important for sensitive projects where confidentiality is key.

Okteto doesn’t just simplify modern application development for developers, but also across the entire organization. With Okteto, platform engineers are able to introduce a platform that allows product, design, marketing, and sales teams to see the changes to the application developers are making in real-time, giving them better visibility into the development process and allowing them to provide timely feedback.

Preview Environments vs Endpoints – When To Use What​

In addition to endpoints on the Okteto platform, Platform Engineers can also configure Preview Environments for their code repositories. While Endpoints enable developers to share each small change they make and receive feedback as soon as they hit save, Preview Environments, on the other hand, automatically create an environment for every Pull Request and provide a URL that anyone can use to view them. Each of them has its utility in different phases of development.

Endpoints are useful during the phase when developers are writing the code and want instant feedback from a person or team closely involved in the development of the feature they’re working on. Preview environments come into the picture when developers have completed working on a feature or bug fix and make a pull request. They are meant to provide a broader set of people visibility into what change is going to be merged in the application codebase. Another key difference between the two is that while Endpoints deploy only the code a developer has written when working, Preview environments deploy all the commits in a pull request regardless of who has made them. Preview environments have a broader scope and are meant to be used for feedback when a feature or bug fix is ready to be shipped, whereas endpoints are meant for instant feedback on small iterations developers might be making when they’re writing code.

Conclusion​

In conclusion, Okteto provides a modern and fast way to share development work and collaborate with your team. Its endpoints make it easy for developers to see changes in real-time. The ability to share these endpoints enables seamless collaboration across the organization, including teams like sales, marketing, and design that traditionally got involved much later in the review process.

If you're looking for a better way to work with your team, give Okteto a try and see how it can improve your productivity and the speed of your team’s workflow!

MongoDB Atlas is a cloud database service that allows teams to deploy and manage MongoDB databases with ease. Its streamlined experience simplifies application building by providing data distribution and mobility across AWS, Azure, and Google Cloud. The service has built-in automation for resource and workload optimization and features like automatic scaling, backup and recovery, and a robust security model, ensuring that data is always safe and available.

Many teams are already using MongoDB Atlas to build modern applications. But the question is if you're using MongoDB in cloud production platforms, why not leverage it during cloud-native app development as well?

What Does Okteto Do​

Okteto is a platform for modern development experience automation. Platform and Development Experience teams define, control, and govern modern development experience and environments. One of the features we offer is provisioning and de-provisioning full stack Kubernetes dev environments that are exactly like production. At Okteto, we've always believed in providing developers with a realistic development environment that's set up instantly and has everything they need for modern app development.

This means that if your microservices are dependent on a cloud database service like MongoDB Atlas, you should be able to work with it during development and testing as well. As part of this philosophy, we recently launched a new feature to our platform: Okteto External Resources. This feature makes working with any resources and cloud service outside of the running Kubernetes development cluster during development a breeze.

Using MongoDB Atlas With Okteto During Development​

If your microservices based application relies on a MongoDB Atlas, it's important to make this service available to developers with their Kubernetes development environment to execute a full production like stack. However, platform and DevX teams often struggle with implementing this in an efficient and effective way. They often end up writing hacky bash scripts for spinning up and down the cloud database service, which developers are then left to make work and debug. With Okteto, microservices deployed in Kubernetes can access MongoDB Atlas as the production cloud service and manage all your data workloads during dev and test. Then the developer experience is extended for offering easier management and better metrics for the data part of your application.

Using MongoDB Atlas with Okteto governed Kubernetes development environments provides even more benefits to the development experience:

• It allows developers to work with realistic production data during development by easily cloning databases. This is difficult to replicate when working locally with a non-cloud-based database.
• It simplifies the management and sharing of databases between developers. With MongoDB Atlas and Okteto, you can easily and securely share access to different databases during development according to your needs.
• It provides full control over the lifecycle of the database during microservice development. This means that if you want to, you can have your MongoDB Atlas database deleted whenever you delete your development or preview environment. This makes it easier to manage resources without having to worry about chasing people around.

How To Use MongoDB Atlas As an External Resource in Okteto​

To demonstrate how you can use MongoDB Atlas databases as external resources, we have prepared a sample cloud-native application for you: https://github.com/okteto/voting-app-with-external-resources

This app mimics modern applications in Kubernetes and highlights the power of Okteto External Resources. The application is a voting portal consisting of three microservices:

• The voting service for casting your vote
• The worker service to process the votes
• The result service to show the final results

The vote services interacts with an API Gateway in AWS to store the data in a MongoDB Atlas database.

Once you spin up a modern environment for the application using Okteto, the Atlas database will be deployed for you. You will also see endpoints that you can visit to see these resources.

The power of this feature is that developers can work in a running Kubernetes development environment that already has all the resources that the application uses, without needing to set anything up. They don't have to create the Atlas database or the Lambda function in AWS every time. Another benefit of Okteto External Resources is that they're ephemeral, just like your development environments. This means that when you destroy your dev environment, the resources created will also be destroyed with it.

Conclusion​

Enabling any cloud database like MongoDB Atlas with Okteto during modern development can help platform and DevX teams deliver the best development experience freeing developers from wasting time on services and resources set-up and control. By using MongoDB Atlas as an external resource in Okteto, developers can:

• Work with realistic data in a production-like Kubernetes environment.
• Be more confident in their code and ensure that their application is working correctly before pushing it to production.
• Save time and effort during development by easily connecting to resources that their application depends on without having to set them up manually each time.

For more information about Okteto External Resources:

• check out our press release announcing the feature
• read the documentation

It is very common for the cloud-native microservices we code these days to utilize resources deployed on different cloud platforms, be it AWS, GCP, Azure or any other. Some common resources which we see being used in modern applications are:

• Databases services like Amazon RDS, Google Cloud SQL or Azure SQL Database
• Object storage services like Amazon S3, Google Cloud Storage or Azure Blob Storage
• Message queue services like AWS SQS, Google Cloud Pub/Sub or Azure Service Bus

These resources have become such an integral part of the applications we work on that it is impossible to imagine how we can develop and deploy microservices without them. But using these resources complicate things during development because providing access to them for every developement and test environment isn’t an easy task.

What Does Okteto Do​

Okteto is a platform for modern development experience automation. Platform and Development Experience teams define, control, and govern modern development experience and environments. One of the features we offer is provisioning and de-provisioning full stack Kubernetes dev environments that are exactly like production. At Okteto, we've always believed in providing developers with a realistic development environment that’s set up instantly and has everything they need for modern app development.

This means that if your Kubernetes deployed microservices are dependent on resources by any cloud provider, you should be able to work with them during development and testing as well. As part of this philosophy, we recently launched a new feature to our platform: Okteto External Resources. This feature makes working with resources outside of your Kubernetes development cluster a breeze.

Why Use Cloud Resources With Okteto During Development​

If your microservices use resources from a cloud platform, it makes sense to make these resources available to developers during development as well. However, teams often struggle with implementing this in a way that's efficient and effective. Developers are often forced to manually configure these resources themselves, using makeshift bash scripts or seeking help from the platform team. This not only wastes time, but also creates a bad development experience. Additionally, debugging becomes more difficult when developers are working with multiple cloud providers they may not be experts in.

Okteto's External Resources can help alleviate these issues. Here's how:

• They allow platform engineers to automate a development experience that automatically provisions and de-provisions cloud resources for developers. Developers get Kubernetes development environments with one click, and all the necessary cloud resources are already configured for them.
• They give the platform and DevX team full control over the lifecycle of these resources. This means developers can have their cloud resources automatically deleted whenever they delete their development or preview environment. This makes it easier to manage resources without having to worry about chasing people around.
• They also ensure secure access to these cloud resources, only allowing access for those who need it. This is especially important when working with user data stored in cloud resources needed during development.

How To Use Cloud Resources As External Resources​

To demonstrate how you can use cloud resources as external resources, we have prepared a sample application running on Kubernetes development cluster for you. This app mimics modern applications and highlights the power of External Resources. The application is a restaurant portal consisting of three microservices:

• The menu service for ordering food
• The kitchen service to track order completion
• The cheque service to generate the bill for the order

We have prepared two different versions of this application to show the flexibility external resources offer. One uses resources from AWS: https://github.com/okteto/external-resources-aws

and the other uses GCP: https://github.com/okteto/external-resources-gcp

The application uses a message queue and object storage from both cloud providers. Once you launch an environment for the application using Okteto, these cloud services will be deployed for you. You will also see endpoints that you can visit to see these services.

The power of this feature is that developers can work in a running Kubernetes development environment that already has all the cloud resources that the application uses, without needing to set anything up. They don't have to create the message queue or object storage every time. Another benefit of External Resources is that they're ephemeral, just like your Okteto development environments. This means that when you destroy your dev environment, the cloud resources created will also be destroyed with it. This makes it easier for platform engineers and team leads to manage resources without having to worry about chasing people around.

Conclusion​

Being able to use any cloud resource during development with Okteto can help teams work in realistic environemnts Without wasting any time on setting up services and resources or controlling them. By using cloud resources as External Resources in Okteto:

• save a lot of time and effort during development by allowing developers to connect to resources that their application depends on without having to set them up manually each time
• work in an exactly production like modern environment
• be more confident in the code quality and ensure that their application is working correctly before pushing the code

For more information about Okteto External Resources, check out:

• our press release announcing the feature
• read the documentation

Feature flags allow developers to enable or disable features in an application without deploying a new version. This enables teams to release new features gradually and test them with a subset of users before rolling them out completely. In today's world, feature flagging has become a standard practice in modern software development. LaunchDarkly is a popular feature flagging service that allows developers to manage their features and rollouts with ease.

What Does Okteto Do​

Okteto is a platform for modern development experience automation on Kubernetes. One of the features we offer is provisioning and de-provisioning environments that are exactly like production. At Okteto, we've always believed in providing developers with a realistic development environment that's set up instantly and has everything they need for development. Our goal is to give developers the ultimate experience when developing modern applications.

This means that if you use feature flags in production, you should be able to work with them during development as well. As part of this philosophy, we recently launched a new feature to our platform: External Resources. This feature makes working with LaunchDarkly during development a breeze.

Why Develop Using LaunchDarkly With Okteto​

Developers are already using LaunchDarkly's SDK to write code with feature flags. However, a common problem they face is the difficulty of testing these feature flags during development. A major issue is having to manually set up a LaunchDarkly environment with pre-populated flags for every developer who wants to work on the application or test features. This process takes time away from coding and can lead to a poor developer experience. Additionally, there is no easy way to replicate the same feature flags present in the production environment for each developer.

Using LaunchDarkly dashboards as External Resources with Okteto solves both of these problems by:

• Automatically provisioning (and deprovisioning) feature flag dashboards
• Cloning existing environments, which ensures that the LaunchDarkly environment during development is pre-populated with all necessary flags

How To Use LaunchDarkly Dashboards As External Resources​

You can configure a feature flag dashboard in LaunchDarkly to be set up for each developer when they spin up their development environment. This dashboard is already configured to work with the application being developed and requires no configuration from the developer’s side. It has all the flags you want to include from your existing production environments.

This simple application demonstrates how easy External Resources make working with services that live outside your Kubernetes cluster, a LaunchDarkly dashboard in this case.

The application displays some text with an emoji. If you look at the code, you’ll see we use LaunchDarkly’s SDK to change the text and emoji when the feature flag is enabled. When you deploy the application using Okteto, Okteto not only deploys the app itself but also provisions a feature flag dashboard for you in LaunchDarkly. You can view this right from your Okteto dashboard.

If you visit the endpoint shown for the LaunchDarkly dashboard, you should be able to toggle the “Use new emojis” feature flag on and off. Refreshing your application should show you the replaced text and emoji.

The power of this feature is that developers can work in a running development environment that already has all the feature flags that the application uses without needing to set anything up. They don't have to create a dashboard in LaunchDarkly every time or manually clone all the flags they need from the production environment. Another benefit of External Resources is that, like your dev environments, they're ephemeral. This means that when you destroy your dev environment, the LaunchDarkly dashboard will also be destroyed with it. This makes it easier for platform engineers and team leads to manage resources without having to worry about chasing people around.

Conclusion​

Leveraging feature flags during development with LaunchDarkly and Okteto can help teams release new features gradually and test them with a subset of users before rolling them out completely. By using this combination:

• developers can easily manage feature flags in their development environments
• ensure that their code is working correctly before releasing it to production
• save a lot of time and effort during development by allowing developers to connect to resources that their application depends on without having to set them up locally.

Check out this video demonstrating the benefits you get from using LaunchDarkly dashboards as an External Resource in Okteto:

For more information about External Resources, check out our press release post announcing the feature or head to the docs!

Okteto's latest feature, External Resources, enables platform engineers to provide a streamlined development experience to their developers who work on modern applications. In this article, we'll explore how External Resources can help you take your developer workflow to the next level!

What Are External Resources and how does it help DevX?​

Modern development platforms must evolve rapidly to meet the needs of modern applications. One common thing we hear from our users is that the applications they are developing not only rely on Kubernetes resources, but also on resources deployed outside the cluster, such as cloud databases like MongoDB Atlas, S3 buckets on AWS, and PubSub queues on GCP, to name a few. They need a way to make these resources easily accessible to developers and testers during development without having to configure them for each developer every time. They also need a way to keep track of all these resources and access them from the same dashboard for easier management. To solve these problems, we have launched our latest feature: External Resources.

With Okteto, you can now seamlessly integrate External Resources into your development experience, eliminating the need for separate, manual tasks. The platform team can define any resource that microservices use and which are deployed outside the Kubernetes cluster by defining the external section in the Okteto Manifest. Once the resources have been defined and any required deploy and destroy configurations are set, they will be available to everyone in development when an environment is launched.

This provides platform engineers with a way to automate the provisioning (and deprovisioning) of an application's resources for the developers on their team, without requiring any effort from the developers and testers themselves. External Resources also provide a way to easily control the lifecycle for all microservices and application-specific dependencies from the Okteto Admin Interface once environments are deployed.

Benefits of Standardizing External Resources in the DevX​

The goal of External Resources is to enable platform engineers to automate the smoothest possible experience for the developers on their team. External Resources simplify the developer’s workflow by:

• Allowing for quick and easy configuration and control of connections to any resource which lives outside the K8s cluster
• Providing unified, standard control of the lifecycle of external resources and the environments
• Making it easy for the entire team to find and manage the application resources during development and testing
• Automatically garbage collecting resources when no longer used, ensuring efficient use of resources
• Saving time and removing risks and deployment errors from developers trying to set up application resources themselves
• Managing access to External Resources securely, ensuring only authorized users have access to the provisioned resources
• Giving flexibility for the application to grow and evolve by allowing you to bring any resource from any provider to your environments

Try It Out Now!​

In conclusion, External Resources are a valuable addition to Modern Development Experience Automation. By leveraging Okteto, platform engineers can enable developers to focus on building better, more secure, and more efficient applications, without having to worry about setting up application resources. The benefits of External Resources are truly boundless.

We have reference sample applications that showcase the power of External Resources. These samples demonstrate how External Resources can be used to build distributed, modern applications. Developers can try them to get a sense of how easy their workflow becomes once they don't have to deal with the admin and management headaches of provisioning and managing cloud resources that their application depends on. By trying out these samples, platform engineers can familiarize themselves with the capabilities of External Resources and learn how to control and govern the ultimate development experience that is fast and high-quality for their developers.

So what are you waiting for? Go give the samples a try!

San Francisco, CA - April 18, 2023 - Okteto, the leader in modern development experience automation, announced today at KubeCon Europe 2023 a new Okteto Release 1.7 with External Resources that integrate any resource with Kubernetes development environments. External Resources are used to access any resource including applications, databases, message brokers, serverless functions, security infrastructure, reporting dashboards, etc that are not available as containerized services and can be hosted anywhere. Once an External Resource is defined in Okteto, developers can instantly deploy, run, and test cloud native microservices without concern for configuring support for external dependencies with a single-click. Okteto Release 1.7 with External Resources is available in Okteto Self-Hosted and Bring Your Own Cloud.

Typically Platform and DevOps teams are required to install and configure applications, execute custom admin scripts just to keep up with provisioning and de-provisioning infrastructure for development. As a result, developers are often stuck waiting for environments, when they could be developing applications. Now Platform and Development Experience teams can build a single development experience to govern the environments for all microservices and development resources and continuously automate a modern experience for all developers.

Customers are evolving to Microservices and Kubernetes Platforms​

Modern application development teams can now speed the adoption of Kubernetes-ready architecture with support for existing non-container workloads. Not all required application resources are implemented in containers nor hosted on Kubernetes which can be a blocker to releasing new applications. Now that Okteto has released External Resources, many legacy applications, infrastructure, as well as, modern applications services can be automated with every development environment to speed productivity and delivery. Customers and technology partners will be using Okteto to provide a robust, incremental path to cloud native microservice applications.

External Resources Extend Modern Development Experience Automation​

Platform and Development Experience Engineers are able to provision environments in Kubernetes that can now access resources anywhere with a single-click experience. Okteto External Resources includes:

• Defining any external resource in your Okteto manifest from any cloud or or service provider
• Leverage a single approach to govern development environments for modern apps
• Manage resources deployed outside the Okteto Kubernetes cluster
• Adds robust, lifecycle control for microservice dependencies / when needed / if required
• “external” includes any resource like: Applications, databases, message brokers, serverless functions, reporting dashboards, any resource, everywhere..

Platform and Development Experience Engineering Benefits​

• For Platform / Development Experience engineering teams - A robust, graceful way of taking control of the lifecycle of external dependencies as part of the development experience
• For Modern Development teams - Less time and risk implementing microservice app dependencies, runtime configurations, and debugging
• For Modern Architects - Easier and faster way to evolve and execute distributed applications (legacy and microservices) and the automation for distributed resources/systems/apps/security, any resource, any where.

With Okteto, the entire team can enjoy benefits such as increased visibility, improved trust, and more governance and control. The team can quickly find and manage app dependencies and mitigate the risk of manual deployment errors.

With the addition of External Resources, the Okteto experience enables faster and higher quality transition to cloud native apps and platforms, providing more innovation and value to developers and startups.

Learn more about External Resources and how Platform teams can deliver a great development experience for modern developers.

Below is a detailed list of the features and improvements that shipped in March with links to the documentation to learn more.

New features​

Added support for Kubernetes 1.24​

Okteto is striving for N-2 version support for Kubernetes to ensure we remain aligned with cloud infrastructure providers and the regular channel releases from the CNCF and Kubernetes community.

This change, and our broader effort to stay current with new Kubernetes versions, will ensure a consistent and stable experience on Okteto.

Updated the Okteto CLI version to 2.14​

The latest version of the Okteto CLI includes several new features and some bug fixes. We continue to invest in the CLI to provide a great developer experience to our customers and end users because it is the entry point for most developers and is core to the Okteto product experience.

Customize endpoints shown in the Okteto UI​

You can now use the dev.okteto.com/endpoints annotation in your Ingress or VirtualServices resource to define a list of endpoints (separated by commas) that will replace the default endpoints used by Okteto.

This change also expands the OKTETO_NAMESPACE and OKTETO_DOMAIN environment variables to make endpoints portable between namespaces.

Support for configuring the buildkit service account​

Buildkit is the build service used in conjunction with okteto build to build containers directly in the cluster. The service account for buildkit is now configurable to provide you with more flexibility and control over your Okteto implementation.

Token-based authentication for simpler self-hosted installation​

When installing Okteto Self-Hosted, we now default to token-based authentication. This simplifies the installation process by removing the need to initially implement more complex authentication systems, seeking internal approvals to get access to those systems, and reducing the time to first exploration of Okteto.

Once you've explored Okteto with this initial implementation, you can switch to another authentication method that is more ideal for expanding to multiple users and production environments.

Added automatic Personal Access Token expiration​

Starting in Okteto 1.7, Personal Access Tokens (PAT) will have a default, automatic expiration of 180 days. We made this change to align ourselves with information security best practices and balancing the developer experience within Okteto. When a PAT expires, it can no longer be used to authenticate a user or for API requests. It is also not possible to restore an expired token; you must create a new token.

Note: Existing tokens are not affected by this change unless or until the Okteto instance is upgraded to 1.7 or newer. At that point, the expiration timer begins from the day the instance is upgraded.

Changed self-hosted registry storage default to container filesystem​

When installing Okteto self-hosted, you are no longer required to use external storage for the registry. Now the installer defaults to using the container filesystem storage. This change simplifies the self-hosted installation process further to help you get setup faster.

Support custom quotas for node port and load balancer service types​

Previously customers would specify desired quotas in the values.yaml file but Okteto would ignore values that were not defined as configurable. We've now added maxNodePorts and maxLoadBalancers to the list of configurable options at the namespace level for your Okteto instance.

Public override support for self-signed certificates and bring your own certificate​

We now support the definition of a publicOverride option in your chart configuration, which enables you to customize the domain your developers use to access your Okteto instance. This does not affect the (sub)domains used for development environment endpoints within Okteto.

For example, if publicOverride is set to okteto.schrutefarms.com, your developers would access your Okteto instance using okteto.schrutefarms.com but your developer endpoints would still remain movies-dwight.example.com.

Improved the wake operation​

The Okteto wake operation running behind the scenes now prioritizes waking dependency services first to ensure your environment is brought back up without any issues. This change aligns the wake operation with the development environment creation process by using the same order of operations.

Added support for dynamic endpoints for external resources​

You can now use dynamic endpoints for external resources you include in your Okteto manifest. This means you can create a complete list of services for your application that exists within Okteto and provides a convenient link to relevant service endpoints along with documentation to help other developers collaborating in the same namespace.

This feature supports:

• Static endpoints (a hardcoded URL in the external section)
• Hybrid endpoints (a mix of static + $ENV_VARS)
• Dynamic endpoints (completely dynamic using $ENV_VARS)

Breaking changes​

Changed the default ingress class for ingresses managed by okteto​

In the March release we've changed the default ingress class for ingresses managed by Okteto from nginx to okteto-nginx. We made this change to prevent collisions with other controllers that may already be installed on a cluster.

There is no action required from our users and all ingresses managed by Okteto will be automatically updated as part of this change.

See a more detailed list​

For a more detailed list of improvements, bug fixes, breaking changes, and deprecation notices please see our documentation.

Is building and maintaining an internal development platform negatively impacting developer happiness and retention? If your innovative developers are burdened with the administrative tasks of maintaining a development platform, your company may have unhappy developers. And unhappy developers can really negatively impact product productivity.

When unhappy cloud app developers leave the organization because of a negative developer experience, the cost can be significant — both in direct and indirect costs. Here's a double whammy: When developers go, it can demoralize the rest of the team. This exodus can lead to decreased engagement, lower productivity, and increased turnover as other team members seek new opportunities.

Now here's a triple whammy: if you build your development platform and that development team leaves, they'll take their knowledge of the development platform's systems tech with them. This departure of information can lead to knowledge gaps and potentially costly mistakes as new team members learn the ropes of this new system. So now you're down developers and a development platform.

Ugh!

Retaining talented developers

Developers in general dislike organizational red tape, emails, meetings, and resource allocation, which hinder their productivity. Hence, a great developer experience (DX) can boost performance and productivity. Companies that prioritize DX can gain improvements in areas, such as talent retention and attraction, productivity, consistency, quality, security, compliance, and speed.

By providing a user-friendly platform, reducing time wastage, standardizing tooling, embedding security and compliance, and automating production, organizations can increase developers' job satisfaction, decrease costs, enhance product quality, meet compliance standards, and achieve faster deployment times. Furthermore, such investments in DX can result in high returns on investment, making them worth the effort.

Pro Tip: ask how happy your developers are with your existing in-house development platform. Many companies discover that buying a development platform increases a positive developer experience and accelerates productivity. So, what are the benefits of prioritizing a positive developer experience? Here are five things to consider:

1. Attracting and retaining top talent. Keeping developers happy is a key benefit of prioritizing DX in organizations. The best engineers in the industry seek out companies with strong tech culture, high employee satisfaction, and a reputation for excellence. In such organizations, developers are able to focus on their core skills and build great software with the latest tools, while minimizing bureaucracy and unproductive work.
2. Increase productivity and reduce costs. By streamlining processes and reducing the time spent on mundane tasks like searching for resources and handling administrative work, developers can bring customer solutions from idea to code in a matter of minutes, rather than months. This targeted investment in a positive developer experience (DX) can produce a high return on investment.
3. Improved product quality. By standardizing and productizing the entire tool stack for developers can contribute to better developer experience (DX), as well as improve the overall quality of digital products. By building with high-quality components and tools, developers can more easily create products that meet customer needs and are free from errors or glitches. Additionally, having easy-to-find and integrated tooling allows developers to focus on what truly matters, rather than spending time figuring out how to use unfamiliar tools.
4. Better security makes developers more secure. By incorporating security testing as part of the enterprise-wide continuous integration/continuous delivery (CI/CD) pipeline or embedding default compliance policies in all cloud environments, compliance is established from the outset, reducing the team's efforts on routine work and meeting the organization's audit, security, and risk requirements.
5. Reduce scrap and rework. Early feedback on quality checks, such as testing, code quality, and controls, reducing handovers and coordination between teams, and full automation of the production process can eliminate rework and allow developers to cover more ground quickly. Consequently, organizations can achieve multiple deployments a day, rather than waiting weeks or months between deployments. Thus, prioritizing developer experience can lead to more efficient and effective development processes, ensuring the organization's success.

Why outsourcing software development fosters a great developer experience

Building a development platform can provide – in some isolated cases - benefits, but it's essential to consider the opportunity costs that come with it. You might miss out on other projects or initiatives with a higher ROI or limit your flexibility and scalability. Therefore, it's crucial to carefully weigh the potential benefits and costs and make an informed decision.

Buying a cloud development platform can offer several benefits compared to building one in-house. First, it can save the company significant time and resources, allowing them to get to market faster. With a pre-built platform, the company can immediately start using the platform rather than spending time and resources developing one from scratch. Developers want to innovate, they don’t want to delegate and administrate.

The building of a platform keeps them from doing what they love: building killer applications. Buying can give the company a competitive advantage by allowing developers to bring new products and services to market quickly and efficiently. That’s a recipe for a happy developer.

That’s pretty cool, right?

However, building an in-house platform also means that your team will be accountable for future development expenditures, ongoing research, maintenance, bug fixes, platform updates, and support. These tasks can be expensive and time-consuming, removing valuable resources from your core business activities.

That’s not so cool.

Remember that things in high-tech move fast. If you’ve got a prospect with unique or urgent needs — and your engineering team must first make modifications to your platform in order to meet this customer's exotic feature requirements — you might lose out on the deal. But a third-party vendor with a suite of out-of-the-box modern development platform features lets you turn disruptive change into business opportunities.

The Opportunity Cost of In-house Software Development Tools​

When considering building a development platform, it's essential to consider the opportunity costs that come with it. Opportunity cost refers to the potential benefits you might miss by choosing one option over another. Here are some of the opportunity costs that you might encounter when building a development platform:

1. Time and money​

Building a development platform takes time, resources, and effort. The opportunity cost spent building the platform could be spent on projects that have a higher ROI. As you think about building your platform, consider this: It took an entire dedicated team of engineers a year to build the first version of a leading development platform vendor. This effort represented around 1 MM in payroll expenses to get the platform up and running. Throw in a few other priorities and distractions, and you're easily looking at 2X that.

2. Preventing Developers from Delivering Value​

Building a development platform requires a team of experts with specific skills and knowledge. The developers you devote to building the platform could be better used to design killer cloud applications that will grow your business by driving revenue. That’s a huge opportunity cost because it’s an opportunity lost. Pro Tip: Ask yourself if building in-house software is at the expense of developing, qa, and implementing and rolling-out core features to grow your business. What is the opportunity cost of using your developers to maintain an in-house solution instead of delivering value?

3. Missing Out on Critical Features​

You might assume you’ve gained a competitive advantage by building your own platform but ask yourself the following questions:

• Is your feature roadmap comparable to what you get out of the box with a vendor?
• Can you manage multiple moving parts, such as IDEs, Docker, code repos, and endless tooling options?
• Can you connect to another developer's branch on its local frontend without spinning up that instance?
• Can you troubleshoot issues globally across namespaces and shared environments? If the answer to these questions is "no," you may be at a competitive disadvantage.

4. Inability to Pivot Quickly to Seize Big ROI Opportunities​

Building a development experience platform can limit your ability to scale quickly and the flexibility to adapt to changing business needs. The inability to pivot fast is itself an opportunity cost as the limitations of your in-house platform could compromise the desire to turn disruptive change into the next big thing. If you need to pivot your strategy or change direction, you might have to invest more time and money into the platform. The technical challenges of building an in-house platform are daunting and the total cost of ownership (TCO) of maintaining the solution often results in sticker shock. Pro Tip: when it comes to scalability and flexibility, ask yourself the following:

• What's the opportunity cost of using your cross-functional resources to provide ongoing bug fixes, maintenance, and platform updates at scale?
• Can you test the code before merging, and can your solution manage multiple microservices in parallel?
• Does your solution provide flexibility to allow developers to use their favorite tools and is it easy for both Kubernetes pros and newbies to collaborate?

The Benefits of Outsourcing Software Development for Dev Platforms​

When building, it's essential to consider the opportunity costs. For example, you might miss out on other projects or initiatives with a higher ROI, or your flexibility and scalability might be limited. Therefore, it's crucial to carefully weigh the potential benefits and costs.

Buying a cloud development experience platform can offer several benefits compared to building one in-house. First, it can save significant time and resources, allowing you to market faster. With a pre-built platform, you can immediately start using it rather than spending time and resources developing it from scratch.

Buying offers a tremendous competitive advantage by allowing platform and development engineering teams to bring software to market quickly and efficiently.

Building an in-house development platform can provide several benefits, such as customizability, better control over the development process, and increased efficiency (at least initially). But when looking at the bigger business picture —i.e., the total cost of ownership (TCO) of building software in-house — companies often experience sticker shock when they realize how much they've spent. Specifically, the costly ongoing maintenance of building an in-house development platform is always an unpleasant surprise.

TCO is the total cost of owning software over its entire lifecycle, including the initial building price and ongoing charges, such as maintenance, human capital investments, resource allocation, and opportunity costs.

Opportunity cost is what you give up when you chose to build a platform with features that very well could be obsolete in a few months.

If you build, you bear the entire cost burden of homegrown software. That includes paying for the initial buildout, ongoing support, bug fixes, upgrades, platform migrations, and keeping up with software industry trends. Mucking around with these complex technical challenges mean that your developers aren't developing - they're administering.

Opportunity costs of building are a time-monopolizing buzzkill for developers whose time is now stuck maintaining the platform instead of innovating and delivering value. Making matters worst is that unhappy engineers often leave a company.

Let's look at the five unforeseen maintenance costs that come with building an in-house development platform:

1. Infrastructure architecture maintenance​

To build an in-house development platform, you must set up and maintain the infrastructure required for development, such as servers, storage devices, and networking equipment. This infrastructure requires ongoing maintenance, upgrades, and replacements, which can be costly.

• Pro Tip: Ask if you or a vendor can keep up with maintenance and regular updates for new features and functionality to provide unparalleled speed, reliability, and scalability. A first-class architecture offers several layers of redundancy and ensures consistency and enterprise-ready security with every update.

2. Technical maintenance​

The in-house development platform must be compatible with various tools, frameworks, and programming languages. Maintaining and updating these technologies can be a significant cost driver.

• Pro Tip: Ask if your platform is built with pre-configured development images for the following languages: dotnetcore, golang, java, node, php, python, Ruby on Rails. Also, ask if your platform works with existing Helm charts, docker-compose, or Kubernetes manifests.

3. Security maintenance​

Developing an in-house development platform means you are responsible for ensuring its security. Maintenance includes upgrades to access controls, data encryption, and security testing.

• Pro Tip: Ask if your solution is secure enough to support SOCII or ISO27001 security, and can it effectively protect PII, or can it cross borders for GDPR compliance? If you say no to any of these questions, then consider the cost of a potential security breach. Don’t lose sleep.

4. Feature customization maintenance​

One of the benefits of building an in-house development platform is customizability. However, the total cost of ownership (TCO) of software customizations can require ongoing maintenance, especially when updating or upgrading the platform.

• Pro Tip: And will the customized features you build today be out-of-date tomorrow? And what features will you need in the future?

5. Integration maintenance​

Your in-house development platform must integrate with other systems, such as databases, applications, and APIs. The TCO of maintaining these software integrations can be complex and require ongoing effort and cost.

• Pro Tip: How much time and resources are needed to increase collaboration with the DevOps teams to ensure the end-to-end platform executes?

The Benefits of Outsourcing a Software Development Platform​

Planning and budgeting for ongoing maintenance, updates, and upgrades are essential to mitigate building costs. But increasingly, companies realize that the potential risks of building an in-house development platform aren't worth it.

Buying a cloud development platform that is already built and tested can make it easier to scale your operations as your business grows, and you'll gain access to the expertise of the platform's developers and support staff. This can help you troubleshoot issues, optimize your platform use, and get the most value from your investment. This expertise can also help you stay updated with the latest trends and best practices in cloud development.

What's the cost of not knowing what you don't know? For example, does your platform have the capability to support pair programming across multiple services? Can it provide easy access to Kubernetes? These are questions some of the most innovative development organizations forget to ask when going down the build path.

Ultimately, the TCO of building a software development platform is like the iceberg that sank the Titanic. From the horizon,  it looks harmless until you look under the water and realize that the TOC of building a development platform is costly enough to sink your boat.

Building an in-house development platform is no longer a technically trivial task.

Some of the most sophisticated engineering companies in the world, including Replicated, LaunchDarkly, monday.com and many more, have come to the conclusion that the technical difficulties of building just weren’t worth it.

"We tried to build it in-house, but that failed," said a Staff Site Reliability Engineer at a high-profile healthcare unicorn. "Companies don't understand the complexity of what's under the hood when building their cloud dev environments, such as the custom resource definitions and technical design needed to work with Kubernetes. Of course, you can create your development portal from scratch, but companies overlook that you need a dedicated team to manage this tool."

Likewise, Replicated, a company that provides delivery and management of Kubernetes applications, discovered building a technically-complicated development platform distracted the team from delivering more essential business value. The platform was also buggy, expensive and costly to maintain.

"Our homegrown solution took a massive investment of our engineering to keep Kubernetes, Docker, and all kinds of cutting edge technologies updated and supported," says Marc Campbell, Replicated co-founder and CTO. "It was difficult, taking our engineering team’s time to support because every day something was broken."

5 Technical Challenges of Building Software Internally​

If you’re still not convinced that building a cloud development platform is a Herculean task, here are five technical software development challenges that may change your mind:

1. Supporting different development tools and languages​

Building a cloud development platform that supports a wide range of development tools and languages can be technically challenging. Each tool and language has its own unique requirements and may require different versions of runtime environments, libraries, and dependencies. This requires careful planning and coordination to ensure that all tools and languages work seamlessly together.

• Pro Tip: Ask if your platform is technically built with pre-configured development images for the following languages: dotnetcore, golang, java, node, php, python, ruby and rust. Additionally, does your development platform work with existing Helm charts, docker-compose, or Kubernetes manifests.

2. Integrating with Kubernetes​

Kubernetes is a popular container orchestration platform used for deploying, managing, and scaling containerized applications. Integrating a cloud development platform with Kubernetes can be technically challenging, especially if you're dealing with complex applications and environments. This requires a deep understanding of Kubernetes architecture and best practices, which is a common technical challenge in software development.

• Pro Tip: What’s the cost to technically troubleshoot your in-house solution’s security vulnerabilities and Kubernetes-related updates?

3. Scaling​

Scaling as your needs grow requires careful planning and architecture. You need to ensure that your environment can handle increased traffic, data storage, and compute resources without impacting performance. This requires a deep understanding of cloud infrastructure and architecture, as well as expertise in scaling techniques and tools — another technical challenge in software development.

• Pro Tip: Ask if your platform can technically manage multiple moving parts, such as IDEs, Docker, code repos, and endless tooling options?

4. Security​

Security means you need to ensure that your platform is secure from unauthorized access, data breaches, and other security threats. This requires expertise in cloud security and best practices, as well as a deep understanding of security threats and mitigation strategies.

• Pro Tip: Ask these questions: Is your solution technically secure enough to support SOCII or ISO27001 security? Can you effectively protect PII? Can your solution cross borders for GDPR compliance?

5. Costs​

Building a cloud development environment can be costly, especially if you're starting from scratch. You need to factor in the cost of infrastructure, licensing, and ongoing maintenance and support. This requires careful budgeting and cost analysis, as well as a deep understanding of cloud economics and pricing models.

• Pro Tip: Ask if the technical challenges of building in-house software a constraint to develop, qa, implement and roll-out core features to grow your business?

4 Ways Buying Overcomes the Technical Challenges of Building​

Each of these technical challenges requires a different set of skills and expertise to overcome. And while building a cloud development platform can provide you with more control and customization, the technical challenges involved can make buying a better option for many organizations, especially those that want to focus on their core business and get to market faster. The benefits of buying include the following:

• Time to market: Development experiences need significant planning, design, and development time, which can delay the rollout of new applications and features. By purchasing an existing cloud development platform, development teams can save time and quickly begin building and deploying applications.
• Expertise: Building requires a deep understanding of software architecture, engineering, and security. By purchasing a platform, development teams can leverage the expertise of the platform provider, who has already invested significant time and resources in building a robust, secure, and scalable platform.
• Cost: Building requires costly investments in hardware, software, and personnel. By purchasing a platform, development teams can avoid these costs and instead pay a subscription fee to use the platform.
• Maintenance and support: It’s an endless challenge providing ongoing maintenance and support, including updates, bug fixes, and security patches. By purchasing a platform, development teams can leverage the expertise and resources of the platform provider to ensure that the platform remains up-to-date and secure.

At the end of the day ask yourself this: is attempting to overcome the technical challenges of building a cloud development platform your core business? Building requires significant technical expertise, time, and resources. Purchasing a platform can provide the platform engineering team with a more technically modern solution ready for delivering development experiences from dev to deployment.

Myth 1: Preview Environments Are Only for Frontend Applications​

One of the most common myths surrounding preview environments is that they are only useful when working on frontend applications. However, this is not true. Preview environments can be used to deploy any or all of the microservices that make up your application.

For instance, let's assume you're working on a backend API, and you've added code for a new endpoint in your latest pull request. Preview environments deploy this change to the API and provide you with a link that you can share with other teams in your organization that consume this API. This allows them to test and verify if the changes you've made are compatible with existing systems or not. This provides an excellent way to receive feedback from all the teams that could be affected by this API change! So, if you're working on cloud-native applications, you can rest assured that your team will benefit greatly from the use of preview environments.

Myth 2: Preview Environments Are Expensive​

Another common myth regarding preview environments is that they are costly to set up and maintain. This is not entirely true. While setting up preview environments may require some initial investment, they are not as expensive as most people believe. Since they follow the lifecycle of a pull request (PR), they are only active until the PR is up and are deleted as soon as the PR is merged or closed. This ensures that cloud resources are utilized in a cost-effective manner. In fact, preview environments can save money in the long run by helping identify potential issues early on, which can ultimately save both time and money.

Myth 3: Preview Environments Are Difficult To Set Up​

Some people believe that setting up preview environments is a complicated process that requires a lot of configuration. However, Okteto's Preview Environments are very simple to set up. If you're already using Okteto's Development Environments, you just need to create the YAML file for the Preview Environments GitHub Action (or create a GitLab CI/CD job), and you're good to go! If you're not already using Development Environments, you'll have to perform just one additional step of writing your Okteto Manifest. This is also a very simple process since it relies on the same manifests you already use in production (Helm charts, Kustomize, Docker Compose, etc.). You won't need to write any additional configuration files or create any infrastructure or cloud resources! Detailed instructions on how to set up Preview Environments can be found in our documentation.

Myth 4: Preview Environments Are Only for Developers​

Preview Environments are an invaluable tool for developers, but they are not limited to this group alone. Anyone in an organization can access the endpoints provided by Preview Environments, making them an excellent way to receive feedback from all teams, including sales, marketing, and design, that could be affected by a change.

For example, product managers can use Preview Environments to see how new features will look and function and provide feedback on their user experience. With Preview Environments, a product manager can test how a new feature will integrate with the current product and provide feedback on potential improvements or changes that could be made to improve the user experience.

Preview environments also provide a way for non-engineering stakeholders to understand the changes being made in a pull request. This doesn't have to be limited to people in your own organization. You can even choose to share the endpoints with some of your users or customers to give them a sneak peek of a coming feature or to get feedback from them as well!

Myth 5: Preview Environments Are Not Secure​

There is a common misconception that the endpoints provided by Preview Environments can be accessed by unauthorized parties, potentially leading to breaches. This couldn’t be farther away from the truth. Okteto's Preview Environments have the same level of security as production or staging environments. You can easily restrict access to published endpoints on pull requests by configuring Private Endpoints. This ensures that only people with access to your Okteto namespace can access the endpoints, and they will need to provide their credentials before being granted access.

Myth 6: Preview Environments Are Only for Large-Scale Projects​

Preview Environments can be very beneficial, regardless of the number of microservices that compose your applications. If your application has a large number of microservices, then it's a no-brainer that Preview Environments will be useful. It becomes very difficult to see the impact of changes in a pull request on the whole application without the endpoints provided by Preview Environments.

But even if you're working on a project with just two or three microservices, the core benefit they provide is still relevant: early feedback from everyone on your team. Even in small projects, non-software engineering teams are almost always left out of the review process. Preview environments help fix that by deploying the changes in pull requests and providing endpoints that anyone can access to review and provide feedback!

Conclusion​

Preview environments are an incredibly valuable tool in the modern application development lifecycle. Not only do they enable all team members across your development team and company to be a part of the feedback process, but they also allow developers to receive early feedback on their work. By providing a quick and easy way to see and test changes, preview environments can help reduce the number of bugs and errors that make it into the final release. In this article, we have discussed some common misconceptions associated with preview environments and have demonstrated just how valuable they can be in helping to ship applications faster. If you are a platform or development experience engineer, Okteto is a great place to get started to learn how to enhance your development experience with Preview Environments. To get set up, follow the quick and easy steps outlined in our guide or you can follow along with our video tutorial:

A pod is Kubernetes’ smallest and simplest unit representing a single instance of a running process in a Kubernetes cluster. Pods contain one or more containers. They share the same network namespace to allow containers within the same pod to communicate with each other. However, a pod is updated and deleted based on the desired state defined by higher-level objects such as Deployments, StatefulSets, DaemonSets, and ReplicationControllers.

When such actions are performed, the pod IP address changes or is removed based on the pod state. You cannot guarantee that this pod IP will exist in the future. Pod IP addresses in Kubernetes are assigned dynamically and can change under different certain circumstances.

Therefore, you need a reliable identifier. This is where the Kubernetes Load Balancer service comes to rescue. This Kubernetes service provide stable Kubernetes endpoints for accessing applications.

It creates everlasting IP addresses for exposing applications both internally and externally. A service acts as a single entry point to a set of pods. This allows clients to communicate with the application without knowing the individual pod IP addresses or their current state.

The major types of services in Kubernetes are:

• ClusterIP
• NodePort
• LoadBalancer

In this guide, you will learn how to use Kubernetes Load Balancer service to expose applications running in Kubernetes Pods internally and externally.

How a Load Balancer Works and Why It Is Useful​

Imagine your website has thousands of different clients per minute. It is not easy for a single server to keep up with the requests demand. This creates a bad user experience with unpredictable downtimes.

A load balancer helps you distribute the requests to the different servers in the resource pool. This ensures no single server becomes overloaded at any single time.

In Kubernetes, a Load Balancer Service is a crucial component for deploying and managing applications in Kubernetes. It exposes a service externally in the underlying infrastructure (for example, a cloud provider's load balancer).

The Kubernetes Load Balancer Service provides load-balancing abilities for incoming traffic to distribute evenly across multiple pods for better performance and high availability.

A Kubernetes LoadBalancer provides external network access to a set of pods to achieve high availability in a cluster. This creates a single and stable IP address for accessing the application without being affected by the pods' state.

Kubernetes uses the Load Balancer service to automatically create a load balancer in the underlying infrastructure. The infrastructure being used must have the capacity to provision a LoadBalancer. This is common when using cloud providers such as AWS to provision your applications and route incoming traffic to the pods in a Kubernetes cluster.

Cloud provider uses their own control manager to automatically detect spec.LoadBalancer. The Load Balancer is then provisioned within the cluster to load balance incoming traffic across multiple pods.

This can be used alongside large-scale applications, such as e-commerce apps requiring handling many concurrent requests from external users. A Kubernetes Load Balancer Service creates a unique IP address that is accessible by external networks. It then redirects incoming traffic, and its IP address is the only entry to the Kubernetes cluster.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 8080

If you have defined how to expose the service externally, it will display EXTERNAL-IP as pending:

> kubectl get service nginx-loadbalancer
NAME              TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nginx-clusterip   LoadBalancer   10.101.132.164   <pending>     80:30998/TCP     16m

Understanding Kubernetes Load Balancer Service With an Example​

Suppose you want to create a cluster to run the Nginx server with three instances. You need to create ReplicaSet that has three Pods, each of which runs the Nginx server. Below is a simple deployment you can leverage to get a cluster started:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-loadbalancer-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Now, this deployment requires a service object to expose the application. You can use the previously created Load Balancer service object.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer-service
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP

In this case, the Kubernetes service will use a selector to map the service to the corresponding three pods with matching labels. Nginx will have three pods, run the following Kubernetes command to see them:

> kubectl get pods --output=wide
NAME                                             READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
nginx-loadbalancer-deployment-544dc8b7c4-bhh5h   1/1     Running   2          58m   172.17.0.6   minikube   <none>           <none>
nginx-loadbalancer-deployment-544dc8b7c4-n25fn   1/1     Running   2          58m   172.17.0.8   minikube   <none>           <none>
nginx-loadbalancer-deployment-544dc8b7c4-wqkn2   1/1     Running   2          58m   172.17.0.7   minikube   <none>           <none>

It uses Kubernetes Endpoints as an object to update the IP addresses of each pod. Each service creates its own Endpoint object. Thus, the cluster can automatically track the matching pods' IP addresses accordingly.

You can describe your service and check how Kubernetes Endpoints lists the matching pods:

> kubectl describe service nginx-loadbalancer-service
Name:                     nginx-loadbalancer-service
Namespace:                default
Labels:                   <none>
Labels:                   <none>
Annotations:              <none>
Selector:                 app=nginx
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.101.132.164
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  30998/TCP
Endpoints:                172.17.0.6:80,172.17.0.7:80,172.17.0.8:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

The Kubernetes Endpoints keep the list of IP addresses up to date for the service to forward its traffic. Endpoints are updated automatically if pods are added, updated, or removed from the service selector. This allows the Service to route network traffic to the correct pods, as the Endpoints can save the address the application need to route to.

Every endpoint that represents the pod network IP and port is defined with the same name as that of the service as follows:

> kubectl describe endpoints nginx-loadbalancer-service
Name:         nginx-loadbalancer-service
Namespace:    default
Labels:       <none>
Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2023-02-02T09:29:12Z
Subsets:
  Addresses:          172.17.0.6,172.17.0.7,172.17.0.8
  NotReadyAddresses:  <none>
  Ports:
    Name  Port  Protocol
    ----  ----  --------
    http  80    TCP

Events:  <none>

Endpoints create a stable network identity for a Replicaset of pods. They change dynamically as the pods' state changes to load balance network traffic to a dynamic set of pods in a consistent pattern.

Kubernetes Load Balancers and Ingresses​

LoadBalancer service type is a good choice when you have a few services to expose. However, with many services, it can be hard to manage. It has limitations such as:

• Limited URL routing
• Cloud provider dependent
• Lacks SSL termination
• It doesn't support URL rewriting and rate limiting.

With an extensive pool of services to load balance, you need to explore other alternatives outside the LoadBalancer Kubernetes service. Ingress defines rules for incoming traffic, such as routing based on the URL path and hostname. This allows you to expose multiple services using a LoadBalancer and manage incoming network traffic to your cluster.

Unlike LoadBalancer Kubernetes service, it provides:

• Advanced URL routing,
• URL path-based routing,
• Hostname-based routing,
• SSL termination,
• URL rewriting, and
• Rate limiting.

In the Nginx example, a basic Ingress resource can be defined as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: nginx.you_url.com
    http:
      paths:
      - path: /nginx
        pathType: Prefix
        backend:
          service:
            name: nginx-loadbalancer-service
            port:
              number: 8080
              name: http

This will allow your cluster maps incoming traffic for nginx.you_url.com/nginx to the nginx-loadbalancer-service service you created using the service resource.

Conclusion​

To sum up, LoadBalancer is a powerful tool that can help you optimize your Kubernetes deployments. It provides several benefits, including load balancing, scalability, security, and ease of use. If you are looking to improve the performance and reliability of your Kubernetes deployments, LoadBalancer is definitely worth considering. If you want to learn more about Kubernetes concepts check out our Kubernetes Tutorial for Beginners!

Preview Environments provide an excellent way to not only validate that everything is working as expected but also allow everyone in the team to be a part of the feedback process. In this article, I’m going to give you four reasons which make them a must-have if you're looking to boost productivity across your team!

Reason 1: Bring Everyone on Board​

Feedback is one of the most crucial aspects of the software delivery process. Great feedback can come from anyone and not just engineers. But conventionally, the feedback process has always been limited to the software engineers on the team because it involved being able to read code. Even for technical team members, the feedback process hasn’t always been convenient. If you want to see how changes actually look and try things out, you would have to pull the code and build it, which is a time taking process.

Preview Environments solve both these problems by deploying the changes in a pull request and giving you a link that you can visit to view these deployed changes. This link is shareable, which means you can send it to anyone across your organization - product, marketing, sales, and even customers if need be! Not only does this allow a much wider set of people to be a part of the review process, but it also makes reviewing easier for everyone. Nobody needs to build the code or wait for a staging environment to try the new features or verify that that nasty bug blocking your users has indeed been fixed!

Reason 2: Feedback at the Right Time​

I think you will agree with me when I say that the early we're able to give feedback, the better. Often feedback from non-technical teams in software companies comes too late in the delivery cycle. It is often just before the release (or sometimes even after 💀) when you're testing things in a staging environment that you would show it to product, marketing, sales, and other teams. But the problem with this is that the feedback you get at this point is much harder to act on than if it were given right when chunks of code were being merged. Preview Environments solve this problem by allowing everyone to review things early on. They provide an excellent way to cut short iteration time by allowing early feedback.

Preview Environments follow the lifecycle of a pull request. They allow you to show the changes in a pull request or merge request before it gets merged. This way, you're able to get feedback for each pushed commit and make the required changes. This is so much easier than getting feedback in staging environments right before the release. Without Preview Environments, feedback early on is only possible from people who can read code, and others are left out of this very important process.

Reason 3: Validation That Things Work​

If multiple people have been pushing commits to the same branch, Preview Environments provide you a way to see the complete change together deployed live and be sure that things are as expected when you make a PR. But it’s not only this; even if you’re working on a branch alone, Preview Environments have become essential because of how complex our applications have grown.

Before a team has Preview Environments, it is very hard to know if the code works as expected or not. Sure, you can look at the code and review it syntactically, but when you start the application, maybe it doesn’t start. Maybe the helm chart you have for your application uses a variable different from the one you used in your code. Preview Environments do an excellent job of highlighting errors like these which are very hard to catch otherwise. When you have multiple services, and there is information flowing through a bunch of different things like databases, secrets, and whatnot, then validating that the changes in a PR still work with the rest of the application becomes a very tough job. Preview Environments help you provide this certainty that things work by deploying your changes and letting you see them!

Reason 4: Testing Your Code Better​

Preview Environments help you expand the kind of tests you run on your Pull Requests or Merge Requests. Before Preview Environments, you would have to rely only on CI/CD to run tests. While having a robust CI/CD is necessary, it still doesn’t solve all your problems. Typically CI/CD is mainly focused on unit and integration tests. What gets left out of the picture are end-to-end (E2E) tests.

End-to-end tests require your entire application to be brought up. This is something that the CI/CD systems are not good at achieving. Preview Environments, on the other hand, shine in this area! They bring up the application with your changes just like it would be deployed in production. This allows you to run all sorts of E2E tests. Preview Environments also allow you to run testing frameworks like Cypress and Selenium, which require the application to be brought up. If you’re working with APIs, the URL that Preview Environments provide can also be used to test them end-to-end using tools like Postman. The cloud-native applications we code today have multiple services and different scenarios that CI/CD doesn’t really have the capability of catching. Preview Environments, therefore, become a must-have for being able to ship bug-free applications!

Conclusion​

To sum up, Preview Environments are a great way to easily get validation and feedback from everyone across your organization in a timely manner! As our applications continue to grow more complex, it becomes essential to rely on them for faster iterations if you’re looking to ship code timely.So what are you waiting for? Sign up for Okteto for free and get started with launching Preview Environments for your repositories. You can find a detailed step-by-step guide to walk you through the process in our docs or check out our video tutorial to get started!

New Experience for Platform Builders​

The Catalog is a fast, easy way to pre-configure and publish launch ready Okteto app configurations (based on application and development lifecycle). Whatever makes sense for your project.

Features:​

• The Catalog enables experience engineers to pre-configure and publish a list of launch ready application configurations that deploy complete running environments
• The Catalog enables platform engineers to easily manage provisioning environments based on applications and development projects
• Automated configuration support for popular repositories such as Github, Gitlab, Bitbucket, Git.

Benefits:​

• Get back lost innovation time
• Creates an easy to use interface for everyone on the team
• Fast way to govern and support development environments
• Increases visibility, trust, and control in self-service provisioning / de-provisioning environments
• Significantly reduces risk of errors and minimizes costs

New Experience for Developers:​

The Catalog provides the ultimate developer experience for on-demand, self-service launching of application configured environments without manual tracking, configuring, and knowledge of multiple tools. The developer workflow is more independent without having to rely on devops engineers to configure their environments for them.

Features:​

• The Catalog is integrated in the Okteto Experience user interface for “one click” launching of app environments.

Benefits:​

• Get back lost innovation time
• Hyper-efficiency, on-demand automation increases the velocity of the development lifecycle and efficiency of the development team
• The optimal developer experience for launching environments without errors and time consuming debugging for complete applications at any stage of the lifecycle.
• Improved collaboration and less dependency with devops and platform engineering

For Experience Builders and their Development Team​

The Catalog feature gives more trust and control to platform, developer experience engineers and administrators and the ability to build a great developer experience. At the same time the Catalog provides a more seamless, frictionless workflow to help developers get started with their work.

The Catalog is available to all Okteto Self-Hosted and BYOC customers. Learn more and get started today →

The Problems Plaguing Modern Applications​

The applications we code these days consist of a large number of microservices. No doubt that this approach is much better and scalable than the monoliths we were coding earlier, but this microservices-based architecture has also led to some new problems for developers.

Traditionally developers would only have to run a command or two to bring up a monolithic application. But with microservices, a lot of configuration needs to be done to bring up all the services you require for development. Another problem is that even when you bring up these services locally, your dev environment is still nothing like the production Kubernetes clusters you’re running. Having developers spend time configuring a realistic production-like environment for development takes a huge hit on productivity and leads to a poor developer experience.

Another problem of modern application development is that it has become tough for developers to judge the impact of the code they write on the entire application. Identifying issues with your code earlier in the dev cycle is becoming crucial in order to ship changes faster. Giving developers tools that allow them to be self-sufficient and more productive is the secret ingredient to creating a wonderful developer experience in your organization. Let’s see how Sprkl and Okteto can help you achieve this!

Modern Dev Tools for Modern Applications​

Okteto allows developers to skip all the headaches of configuring a production-like development environment and get right to the code-writing phase. With Okteto, you can develop your applications directly in a Kubernetes cluster and see the changes you make in your code reflected live as soon as you hit save! This solves one-half of the problems we discussed above.

The second half is where Sprkl shines. Sprkl allows you to immediately judge the impact of the code you write on the entire app. It does so by leveraging OpenTelemetry to automatically instrument code changes and analyze them upon execution. This helps you write code with the confidence that things would not go wrong in production. You’re able to identify potential issues much earlier and fix them. Feedback provided by Sprkl includes traces on the code level, insights about hidden API calls, DB queries, and memory bottlenecks, among a lot of other things!

The inner dev loop refers to a single developer's workflow when working. It encompasses all the things developers do before committing and pushing their code. This makes up the core of developer experience and often is the bottleneck for dev productivity. Shortening the inner dev loop is the secret to unlocking dev productivity. If the inner dev loop your developers have to go through is frustrating and doesn’t provide genuine feedback, then the dev experience across your organization will no doubt be bad. Both Okteto and Sprkl improve this inner dev loop by giving developers access to all the things they need the most:

• instant and genuine feedback in a production-like environment
• analysis of the effect of their code on the overall application

See It in Action​

I’m sure by this point you must be wondering how you can use these two tools together. Marom Bracha recorded a demo showing you exactly that. Go check it out to give a boost to your developers’ workflow and simplify the development process for them!

Once you’re done watching the video, why don’t you go give it a try yourself to see the magic? The code in the video can be found on GitHub here.

To build or not to build? Ah, that is the Shakespearean question when it comes to software. When faced with a specific business challenge, many companies debate this dilemma; it's an especially tricky quandary when the software in question is meant to help software developers develop more efficiently.

Why building might at first seem smart​

Constructing an internal cloud development platform may appear like a smart business move at first glance. Having a custom-made solution enables teams to have control over the specifications and manage releases based on their specific needs. In-house software allows for customization of features to meet immediate requirements instead of opting for a third-party solution that may have unused features.

Another benefit of building an in-house dev platform can lead to a first-hand understanding of the technology and deeper sense of ownership and pride in the solution, which can translate to a more motivated and dedicated development team. This is a fair point because developers like to develop. And some organizations, especially those with sophisticated engineering teams, are tempted to build their own developer platform. It's easy to understand this philosophy: who knows the needs of developers better than a company's own developers?

However, this approach brings with it the responsibility for future development investments, constant research, compliance upkeep, bug fixing, platform updates, and support, all of which can be a costly and time-consuming distraction from the core business operations.

When considering the option to build or purchase software, companies usually start by evaluating their budget, assessing the impact of this investment on their core business, and weighing the near and long-term time constraints and potential future needs.

Although building software may be a viable option in some specialized cases, purchasing a cloud development platform from a vendor often proves to be a more favorable business decision for several reasons, including the following ten:

1. Buying a Cloud Dev Platform Offers Superior Features​

Investing in a cloud development platform developed by cloud experts is likely to bring significant business benefits. Vendors typically offer a wide range of advanced out-of-the-box features that allow developers to create microservices for cloud applications with ease. These cloud development platforms are battle tested and often designed with input from some of the most forward-thinking development organizations and have undergone thorough testing. As a result, these platforms offer features and capabilities that in-house development teams might not have considered on their own.

• Pro Tip: The key is to find a cloud development platform built with pre-configured development images for the following languages: dotnetcore, golang, java, node, php, python, ruby and rust. Additionally, the platform should work with existing Helm charts, docker-compose, or Kubernetes manifests. At the end of the day, you have to ask if your homegrown development is robust enough to simplify the adoption of Kubernetes, provide enterprise-ready security, support namespaces, mirror production, and scale as technology evolves. If not, then buying is the correct business decision.

2. Buying a Cloud Dev Platform Offers Reliability and Scalability​

If you have built your own in-house cloud development platform, it may seem that the in-house team's familiarity with the solution will make performance maintenance simple. However, if key team members leave the company with that crucial knowledge, it can create challenges. Additionally, as the environment needs to expand to meet the demands of emerging standards and new technology upgrades, such as Kubernetes, the in-house solution may not be equipped to handle these changes.

Inadequate updates to the platform and poor design of its resilience can lead to significant downtime during issues. Even seemingly minor updates can uncover security vulnerabilities and data bugs in business logic, which can hinder the performance of the development teams and put the delivery of value at risk. These issues can have a negative impact on the developer experience and slow down the entire process.

A cloud development platform provided by a third-party vendor can ensure speed, reliability, and scalability through ongoing maintenance and the introduction of new features and functionality.

• Pro Tip: When considering a third-party platform, it's important to look for one with a robust architecture that offers multiple layers of redundancy and provides consistent, secure updates. The platform should also be flexible and designed to perform at scale, whether you're developing simple internal apps or complex global apps with numerous microservices.

In-house solutions and the teams supporting them may struggle to keep up with the demands of your product development. There's no doubt that there are serious technical challenges involved in creating a scalable secure development platform. With a third-party platform, you can relax knowing that it is compatible with current standards and can adapt to evolving standards in the future, such as updates to Kubernetes. This allows your development team to focus on creating innovative cloud applications that will drive your business forward.

3. Don’t Waste Engineers on Non-Essential Tasks​

The reality is, if your engineers are dedicating a portion of their time each week to maintaining the development environment, they are not able to focus on driving innovation and creating revenue-generating application features. In other words, building an in-house platform can be both resource-intensive and time-consuming. The use of your valuable developer resources is part of the total cost of ownership (TCO) equation often ignored when development teams opt to build an in-house cloud development environment.

• Pro Tip: Look for a cloud development platform that comes with a support team that has extensive experience in cloud development and Kubernetes. The vendor should leverage their expertise to address complex problems, create comprehensive solutions, proactively tackle security concerns, and anticipate user needs and patterns to enhance your business and fulfill the requirements of all stakeholders. By doing so, your team that was previously responsible for maintaining the development environment can now concentrate on their core strength - developing outstanding applications.

4. Remember Building a Cloud Dev Platform Has an Opportunity Cost​

At the end of the day, the argument for building versus buying always comes down to ROI. If you build, you bear the entire cost burden of homegrown software. That includes paying for the initial buildout, ongoing support, bug fixes, upgrades, platform migrations, and keeping up with software industry trends. These costs can add up to hundreds of thousands of dollars, if not millions.

When evaluating the ROI of building versus buying a cloud development platform, it's crucial to consider the total cost of ownership (TCO) of building versus the cost savings and productivity benefits of outsourcing the maintenance and support responsibilities to a vendor. A vendor's expertise in hosting and maintaining cloud development solutions can provide a significantly positive impact on developer experience and overall organization productivity.

• Pro Tip: Ask the vendor to showcase their success in helping other companies improve their development processes, reduce the number of bugs and late-stage defects, and cut down on scrap and rework by 50%. A positive developer experience is a crucial factor in achieving a high ROI from a cloud development platform, and you should ask for customer testimonials that speak to this.

Remember, by outsourcing the maintenance of the platform to a vendor, your engineering team can concentrate on delivering value to your organization, instead of dealing with the overhead of maintaining a homegrown solution. The vendor bears the cost of building and maintaining the platform and can pass on the efficiency savings to you.

5. Improved Developer Experience Accelerates TTM for Software Releases​

Developing a cloud development platform from scratch can take a long time and exhaust your internal engineering resources. On average, building a cloud development platform with a dedicated in-house team can take a year or more. Buying a cloud platform from a vendor can save a significant amount of time as it is already built and ready to use.

This can free up resources for other critical business initiatives. For example, according to monday.com, switching from an in-house to a third-party cloud development platform accelerated developer velocity by 50% and reduced costly scrap and rework by an additional 50%.

And guess what? As a result of superior development processes, development companies using a cloud development platform can in return, reduce the time-to-market for new products and services compared to traditional in-house development platforms and processes. Surprise. Surprise.

• Pro Tip: Remember that the bottom line is the bottom line: Building an in-house cloud development platform is time-consuming and can take years with an entire team of engineers. During this time, the organization will have to divert resources away from other critical core-business efforts, which can hurt the bottom line.

6. Vendors Offer Technical Expertise for Kubernetes and Microservice Management​

Most cloud development platform vendors have a team of experts with extensive experience and knowledge with regards to microservices, Kubernetes and security, for example. These third-parties invest heavily in research and development to create the best possible product. This can ensure a higher level of quality and functionality compared to an in-house development team that may not have the same level of expertise.

According to Slai**,** a company building a developer-first platform for machine learning, the reason they switched to a third party cloud development platform was access to Kubenetes expertise and a pool of skilled resources that were not available internally to the company.

Slai was able to work with a Kubernetes namespace in a shared developer cluster that replicated their production environment. This made it easier for them to work on the project, as they did not have to be experts in Kubernetes: however, the company benefited from the additional expert support they received from the third-party vendor that had a deep understanding of their infrastructure, Kubernetes, and was able to help design their system to closely match the production environment.

• Pro Tip: Make sure the cloud development platform vendor has a high level of expertise in cloud computing, security, and infrastructure to support you. Ask if they have customer testimonials confirming the vendor provides excellent professional support. It can be challenging for most organizations to find and retain the necessary in-house expertise. Additionally, remember that maintaining a development platform isn’t your core competency in the first place.

7. Buying a Dev Platform Is Cost Effective​

Building an in-house cloud development platform can be very expensive, especially when considering the costs of hiring and training a team, buying hardware and software, and other overhead expenses. According to one build vs buy expert, building a cloud development platform represents around 1MM in payroll expenses to get the platform up and running. For Replicated, a company that enables the seamless delivery and management of Kubernetes applications in multi-prem, customer-controlled environments using a single architecture, the switch from building to buying resulted in immediate cost benefits. The company saved thousands each month on development costs and accelerated developer productivity by 200%.

"There's a cost-effectiveness to a third-party cloud development platform," says the Senior Software Engineer of a healthcare unicorn platform. "It offers a scalable, reliable, stable production-ready infrastructure that allows our team to shorten the gap from dev to prod and enables us to ship value to our customers faster. I can now deploy a helm chart, namespace, cloud integrations, and can go run through chaos scenarios. I can experiment, delete things and remove pods. I have immediate feedback as to how that might play out in production. And there's no way you can do that with local development or a homegrown solution."

• Pro Tip: Remind the business decision makers that buying reduces upfront costs. Building an in-house cloud development platform requires a significant upfront investment in hardware, software, and staffing. This investment can be substantial, especially for organizations unfamiliar with cloud computing. Those upfront costs can be in the form of opportunity costs.

8. Scaling with In-House Solutions Is Challenging​

Established third-party cloud development platforms tend to have a large user base and strong support networks, making it easier to scale and expand to meet customer demands. On the other hand, an in-house development platform may not be able to handle sudden spikes in demand, quick pivots necessary to adopt disruptive change, leading to prolonged downtime and decreased performance.

In the case of Replicated, the company's local dev environments could not meet the developer demands of the company's sophisticated platform. "Developers would spend a lot of time building their dev environment instead of coding, and that became unsupportable and difficult to maintain," says Marc Campbell, Replicated co-founder and CTO.

• Pro Tip: Pick a vendor with an architecture, roadmap and vision to support scalability now and into the future. A third-party cloud platform can provide better scalability compared to in-house development, as cloud platforms are designed to handle sudden spikes in demand. Couple that flexibility with a team of vendor experts on emerging technologies and you can be assured that your solution will be prepared for unforeseen technology and market changes.

As an organization grows, it may need to scale its cloud development platform to accommodate additional users and workloads. This can be challenging in-house, as the organization will need to acquire additional hardware and software and hire other staff to manage the platform.

9. Continuous Improvement Not Easy to Maintain Internally​

Most cloud development platform vendors constantly invest in R&D to improve their products and stay up-to-date with the latest technologies and trends. An in-house development platform may not have the same resources available for continuous improvement and may become outdated quickly. For example, the inability to keep up with updates to Kubernetes can crash an entire application. And not being current with security patches can leave your platform vulnerable to attacks.

• Pro Tip: Consider the value of a positive developer experience and weigh it against the potential risks and expenses of a failed migration, security breach, delays, and increased scrap and rework caused by a homegrown solution.

Cloud development platforms offered by vendors are continually updated and enhanced with new features and capabilities. Building an in-house platform means the organization will have to manage these updates and improvements, which can be time-consuming and resource-intensive.

10. Building a Cloud Dev Platform Is a Security Risk​

Cloud platform vendors typically have a team of security experts focused on ensuring their platform's security. They invest heavily in security infrastructure and continuously monitor and update their systems to prevent security breaches.

Historically, static application security testing (SAST) and dynamic application security testing (DAST) scans cannot accurately determine which environment is being tested against. This impediment can lead to security oversight and bugs skirting past the DevOps goalkeeper. But a cloud development environment with embedded security policies shores up your posture against vulnerabilities.

• Pro Tip: Work closely with system architects and CISOs to ensure the cloud dev platform vendor builds with security in mind. An in-house development platform may have a different level of resources or expertise to ensure the same level of security. A cloud development environment allows teams to test security protocols while in development. Forget about the days of developers creating risky ad-hoc staging environments that are impossible for CISOs and system architects to manage and protect. This new cloud security development paradigm has allowed DevOps and developers to work together to stop security risks dead in their tracks.

Using cloud platforms can provide better security compared to in-house development, as cloud platform vendors typically have a team of security experts and invest heavily in security infrastructure. Bottomline: Maintaining the security of an in-house cloud development platform is critical. However, doing so can be difficult and expensive, especially for organizations unfamiliar with cloud security best practices.

To Build or Buy a Dev Platform - Ah, That’s the Question​

Buying a cloud development platform from a vendor can provide benefits, such as time and cost savings, access to expertise, scalability, continuous improvement, and security, which are not necessarily guaranteed when building an in-house development platform.

These benefits can result in a better return on investment for a business, making it a better business decision. In addition, with a cloud development environment, you can say goodbye to the headache of worrying about security risks, learning Kubernetes, and escaping the never-ending cycle of updates. Instead, say hello to a simple, effective solution that allows more time for coffee breaks and debating the questions that really truly matter, such as:

Sure, building a cloud development platform can provide customization and control but at what cost - total cost of ownership, total cost of what happens when there is a security breach, and total cost of having unhappy developers leave. Buying removes these issues.

The best way to develop cloud native applications is in a development environment in the cloud which is where Okteto comes in.

With the Okteto development environment, you can now develop right inside the cloud and see how your application performs in the cloud.

In this tutorial, you will learn how to develop a full-stack application that comprises a VueJS front-end and a NodeJS back-end with Okteto.

Prerequisites

To follow along in this tutorial, it is required that you have:

• A basic understanding of JavaScript and the VueJS framework.
• A basic understanding of NodeJS.
• Access to an Okteto instance.
• Okteto CLI installed on your machine.

Setting Up Your Dev Environment​

To build and develop your applications in Okteto, you’ll need to first, connect your local machine to Okteto.
Run the command below to configure your Okteto context.

okteto context use https://okteto.example.com

Once your context is configured successfully, a new tab will open with the below output:

This output shows you are now connected to Okteto from your local machine. So, you can now develop your application with Okteto.

Initializing the Full-Stack Application With Okteto​

To see the power of Okteto, you’ll initialize the full-stack application from the ground up with Okteto.

Create a working directory called node-vue-app:

mkdir node-vue-app
cd node-vue-app

Add a docker-compose.yaml file and paste in the following configuration settings:

The Okteto CLI will use this file to deploy the full-stack application.

version: "3.8"
services:
  api:
    build: ./node-backend
    container_name: node_c
    ports:
      - '4000:4000'
    volumes:
      - ./node-backend:/app
  frontend:
    build: ./vue-frontend
    container_name: vue_c
    ports:
      - '8080:8080'
    volumes:
      - ./vue-frontend:/app

Inside the node-vue-app directory, create two other directories node-backend and vue-frontend to house the NodeJS backend and VueJS frontend application respectively:

mkdir node-backend
mkdir vue-frontend

In the node-backend directory, add a Dockerfile with the below code snippets:

You’ll need to do this so that Okteto would know what image to use and what to build.

FROM node:18-alpine

RUN npm install -g nodemon

WORKDIR /app

COPY package.json ./

RUN npm install

COPY .  .

EXPOSE 4000

CMD ["npm", "run", "dev"]

Go into the vue-frontend folder, create a Dockerfile and add the below code snippets:

FROM node:17-alpine

WORKDIR /app

COPY package*.json .

RUN npm install

COPY . .

EXPOSE 8080

CMD [ "npm", "run", "dev" ]

Initializing the Node.js Application with Okteto​

Now run the Okteto command below to set up the NodeJS application with a development container. The command below, will deploy the services that were set in the docker-compose file (api and frontend) and spin up a development container for any of the services you specify.

okteto up

The command above will display an output asking you to select the development container you’d like to activate, firstly press Enter to start the development container for the api service. The api service in this case houses the NodeJS backend application:

~/node-vue-app$ okteto up
 i  Using mercybassey @ okteto.example.com as context
 i  Development environment 'node-vue-app' already deployed.
 i  To redeploy your development environment run 'okteto deploy' or 'okteto up [devName] --deploy'
Select the development container you want to activate:
Use the arrow keys to navigate: ↓ ↑ → ← 
  ▸ api
    frontend

You can also bypass these questions by executing the okteto up service_name command.

Next, you will be asked if you’d like to infer defaults for the '.stignore' file? Type in y to continue. The .stignore file tells Okteto CLI which files not to synchronize to your development environment. If you're familiar with .gitignore, or .dockerignore, .stignore has a similar function.
Lastly, select the programming language for the api service, which in this case is  - Javascript:

Wait for a while for your Okteto development container for the api service to be ready. Once it is ready, you should have the below output which indicates that you can now develop the NodeJS application in Okteto:

Initializing the Vue.js application with Okteto​

Since you have already initialized the NodeJS backend with Okteto, you now need to do the same for the frontend service that houses the VueJS frontend application.

Open a separate terminal and run the below Okteto command to activate the development container for the frontend service:

okteto up frontend

Head over to your Okteto dashboard to view the services created by Okteto using the docker-compose file you created:

You are now ready to develop your application in Okteto.

Developing the Node.js Application in Okteto​

NodeJS is an asynchronous event-driven JavaScript runtime that is used to run JavaScript code outside the browser.

In this tutorial, you’ll be using NodeJS on the backend to handle asynchronous requests from the frontend.

Inside the api development container, run the following command to create a file called index.js. This file will contain all the backend code for the NodeJS application:

touch index.js

Paste in the following code snippets:

The code below will simply output a list of some programming languages, their uses, and when they were created on the home route that listens on port 4000.

const express = require('express')
const cors = require('cors')

const app = express()

app.use(cors())

app.get('/', (req, res) => {
 res.json([
   {
     "id":"1",
     "language":"JavaScript",
     "use":"Javascript is used by programmers across the world to create dynamic and interactive web content like applications and browsers.",
     "invented":"JavaScript was invented by Brendan Eich in 1995"
   },
   {
     "id":"2",
     "language":"Python",
     "use":"Python is a computer programming language often used to build websites and software, automate tasks, and conduct data analysis",
     "invented":"Python was created by Guido van Rossum, and first released on February 20, 1991"
   },
   {
     "id":"3",
     "language":"Go",
     "use":"Go (also called Golang or Go language) is an open source programming language used for general purpose. Go was developed by Google engineers to create dependable and efficient software.",
     "invented":"Go was developed by Google Engineers on the 10th of November 2009"
   },
   {
       "id":"4",
       "language":"Ruby",
       "use": "Ruby is mainly used to build web applications and is useful for other programming projects. It is widely used for building servers and data processing, web scraping, and crawling. The leading framework used to run Ruby is Ruby on Rails, although that's not the only one.",
       "invented":"Ruby was publicly released in 1995, but it didn't quite achieve mass acceptance until much later in 2006"
   },
   {
       "id":"5",
       "language":"Java",
       "use":"Developers use Java to construct applications in laptops, data centres, game consoles, scientific supercomputers, cell phones, and other devices.",
       "invented":"Java was first released in 1995, and Java's ability to provide interactivity and multimedia showed that it was particularly well suited for the Web."
   },
 ])
})

app.listen(4000, () => {
 console.log('listening for requests on port 4000')
})

Create a package.json file to track the dependencies for the NodeJS backend.

npm init -y

In the package.json file add a new script dev as shown below:

This script will use a library called Nodemon to watch for changes when the dev script is run.

"scripts": {
   "test": "echo \"Error: no test specified\" && exit 1",
   "dev": "nodemon -L index.js"
 },

Now run the following command to spin up the Node.js backend:

npm run dev

Go to your Okteto dashboard, and click on the api service endpoint, you should see the NodeJS application with the endpoint provided by Okteto:

Since you now have the NodeJS application working as expected on your local machine and in the cloud press ctrl c, to stop the  NodeJS application and press exit to exit the development container.

Now, run the command below to deactivate the development container for the NodeJS application:

okteto down api

Developing the Vue.js Application in Okteto​

VueJS is a JavaScript framework that is used to build single-page applications and user interfaces.
To initialize a VueJS project, you will use Vite which is a tool for setting up development environments for JavaScript libraries and frameworks.

Since you already have the frontend development container activated, run the command below to create a VueJS app. Type in y to allow npm to install the vite package, type in (.) so the vite package gets installed into the current directory (vue-frontend), and give it a package name. This tutorial uses vue as the package name.

Also, select No for other configuration settings to continue.

npm create vue@3

Now, run the npm install command so Vite can run your VueJS application

npm install

Setting up the VueJS application with Vite empties the folder you try to set it up in. If you head back to the vue-frontend folder, you’ll discover that the Dockerfile has been deleted. This is Vite-specific, so you’ll need to add the Dockefile again.

touch Dockerfile

Add the code snippets into the Dockerfile:

# Choose the Image which has Node installed already
FROM node:17-alpine

# make the 'app' folder the current working directory
WORKDIR /app

# copy both 'package.json' and 'package-lock.json' (if available)
COPY package*.json .

# install project dependencies
RUN npm install

# copy project files and folders to the current working directory (i.e. 'app' folder)
COPY . .

EXPOSE 8080

CMD [ "npm", "run", "dev" ]

Go into the package.json file, and edit the dev value inside the script block to look like the below:

"scripts": {
   "dev": "vite –-port 8080",
   "build": "vite build",
   "preview": "vite preview"
 },

The reason you’ll need to do is so that Okteto can serve up your frontend application. As the Okteto development environment listens on port 8080.
Go into the vite.config.js file and edit the configuration settings to look like the following, so that Okteto can serve up the frontend application:

import { fileURLToPath, URL } from 'node:url'

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
  server: {
    watch: {
      usePolling: true,
    },
    host: true,
    strictPort: true,
    port: 8080
  },
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

Now, confirm the VueJS frontend application is accessible over the browser by running the following command:

npm run dev

Now head over to your Okteto dashboard and click on the frontend endpoint to see the VueJS application:

Once you have clicked on the frontend endpoint, you should have the following output:

Now you will further develop the VueJS frontend application, by building a UI to serve up the NodeJS backend application.

Paste the code snippet below into the vue-frontend/src/App.vue file.

<script>
import {ref,onMounted} from 'vue'
export default {
 setup() {
  const languages = ref([])
  onMounted(() => {
      getResponse()
    })
  
   const getResponse = async () => {
    fetch('http://localhost:4000/') 
    .then((res) => res.json())
    .then(data => {
      languages.value = data;
      console.log(languages.value)
    })
    .catch(err => console.log(err.message)) }
   return {getResponse, languages}
 }
}
</script>

<template>
  <div>
    <table>
      <tr>
        <th>LANGUAGE</th>
        <th>USES</th>
        <th>YEAR OF INVENTION</th>
      </tr>
      <tr v-for="language in languages" :key="language.id" >
        <td>{{language.language}}</td>
        <td>{{language.use}}</td>
        <td>{{language.invented}}</td>
      </tr>
    </table>
  </div>
</template>



<style scoped>
div{
  margin: auto;
  width: 1000px;
}
table {
  margin: 0% auto;
  width: 100%;
}
th{
  font-weight: bolder;
}
td{
  width: 150px;
}
th, td {
  border-bottom: 1px solid #ddd;
  padding: 7px;
}
</style>

Head over to your Okteto dashboard and refresh your Frontend service endpoint to see your app.

You could notice that Okteto has picked up the changes in the VueJS application, and it keeps watching out for changes as you develop. This applies to the NodeJS backend too.

For the VueJS application, you should have it look like the below:

The VueJS application couldn’t display the NodeJs application because you deactivated the development container for the api service. As the NodeJS application listens on localhot:4000 which is only available on your local machine and not a public endpoint that is available over the internet.

To have the VueJS frontend serve up the NodeJS backend you’ll need to restart the development container for the api service.

Run the Okteto command below to spin up the development container for the api service.

okteto up api

Run the command below to start the NodeJS application:

npm run dev

Now, refresh the VueJS application in Okteto. You should see the below output:

Conclusion​

In this article, you have gotten a good grasp of how you can use the Okteto development environment to develop a full-stack application in the cloud. You have learned how to use docker-compose to deploy applications to Okteto. You now have the opportunity to see how your application behaves in a production-like environment with Okteto at your fingertips.

If you’d like to see the code used in this article, you can find it on GitHub.

That was precisely the debate and dilemma a leading digital healthcare unicorn faced when it came to decide whether to build or buy a cloud development platform. The first choice was to build, but the development team quickly discovered that building a cloud development platform was more trouble than they realized.

"We tried to build it in-house, but that failed"

The healthcare company quickly realized its local development tools and deployment strategy could not scale to meet the needs of the company's growing development team However, their decision to solve their local development problems by building a platform was a case of leaping out of the frying pan and into the fire.

The healthcare company attempted to solve its development issues with a homegrown dev environment solution but quickly discovered several problems; namely, using existing members from their 100-plus development team to develop the platform impacted time to market for core development commitments and essential releases and compromised the focus on current projects and morale.

"We tried to build it in-house, but that failed," says the company's Staff Site Reliability Engineer. "Companies don't understand the complexity of what's under the hood when building their cloud dev environments, such as the custom resource definitions and technical design needed to work with Kubernetes. Of course, you can create your development portal from scratch, but companies overlook that you need a dedicated team to manage this tool."

The healthcare company realized they were not equipped to assume the entire burden of building a customizable option, including R&D, writing documentation, QA, ongoing maintenance and support, and data storage. The irony is that even if they did cultivate that internal expertise to build a platform that could support Kubernetes and microservices, there was always the risk that in-house brain trust, which is often a single person, could walk out the door, taking all that knowledge with them.

Does your in-house solution work well with Kubernetes? Just asking

The company needed a platform out of the box that reduced merge issues, improved developer experience, supported Kubernetes best practices, and helped them manage and control critical data.

"A lot of people know Kubernetes but don't know how to use it well," says the Senior Software Engineer at the healthcare company. "We needed a platform that supported best practices when using Kubernetes as well as something that helped us move our development closer to production by allowing us to use production-like data."

When it came specifically to Kubernetes, the team soon realized they needed more internal expertise to design, develop, implement, maintain and support a solution that could simplify its complexities. And that's why they scrapped their build project and pivoted to buy a solution that could unlock a better development experience for the entire dev team.

"We deploy all our applications to Kubernetes, but Kubernetes doesn't live in our software development life cycle," says the Site Reliability Engineer. "And that's exactly where Okteto fits in perfectly as a development platform to manage that complexity with Kubernetes and the cloud."

The benefit of a cloud solution versus building an on-premise solution

Another benefit of Okteto's cloud development solution was it allowed both developers who had an expert understanding of Kubernetes and those that wanted nothing to do with it to thrive. That's a delicate balancing act that takes a lot of work to achieve with a homegrown solution. "With Okteto, developers do not need to know Kubernetes for development," says the engineer. "If developers just want to write python or JavaScript, they don't need to know the complexities of managing their Kubernetes cluster — they can learn it on their terms, and Okteto handles everything in-between."

This healthcare company is a classic example of a developer-first organization that understands how a positive developer experience translates to a productive engineering organization; buying allows developers to do what they love instead of burdening them with the exhausting maintenance of a troublesome homegrown solution. With Okteto, engineering teams got a cloud development environment that spins up in seconds and works with developers' favorite integrated dev environment (IDE), associated tool set, and pre-established workflows. As a result, developers no longer need to install, configure, and run resource-intensive tools.

"There's a cost-effectiveness to Okteto," says the company's Senior Software Engineer. "It offers a scalable, reliable, stable production-ready infrastructure that allows our team to shorten the gap from dev to prod and enables us to ship value to our customers faster. I can now deploy a helm chart, namespace, cloud integrations, and can go run through chaos scenarios. I can experiment, delete things and remove pods. I have immediate feedback as to how that might play out in production. And there's no way you can do that with local development or a homegrown solution."

What Exactly Is Developer Experience?​

Just like User Experience (UX) relates to how users feel when interacting with a product, Developer Experience (DX or DevEx) describes how developers feel when using a tool as part of their job. Think of your favorite code editor; the happy feelings you associate with it are part of your DevEx with that tool.

With so many emerging tools and technologies, DevEx has become more relevant than ever. After all, if you want to keep the developers on your team happy and productive, you must invest in solutions that enable them to work without friction. The processes you set up for your team and the tools you choose end up defining the development experience for your team. So what’s wrong with our current approaches?

The Sad State of DevEx Today​

Today, the state of development is slow, lengthy, and increasingly complex. It’s costing development teams hours of tedious work and lost productivity. Teams remain hindered by the limitations of their local machines that can no longer support the resources it takes to build distributed microservice applications and the lack of intuitive task automation to deal with the gap. To move into deployment, development teams are dealing with a confusing mixture of CI/CD tools, repos, security, and performance test environments. Developers have to work in unrealistic environments which are nothing like production and end up wasting several hours trying to replicate the production setup locally, trying to catch bugs that show up too late in the software delivery cycle.

We, as an industry, have always agreed that the dev environment should be as close to production as possible. But Kubernetes and the cloud shook up the landscape significantly, and we didn’t bother putting in efforts to bridge the now-increased gap between dev and prod. This led to frustrated developers who now found themselves burdened by additional responsibilities.

Simply put, cloud-native applications demand a cloud-based development platform approach.

Closing the Gap​

We’ve seen cloud dev environments contribute significantly to an improved DX because, with them, developers don’t have to waste time on things they don't like doing. They get to focus on what they love: writing code, innovation, and building cool applications. The cognitive load of configuring networking policies, Kubernetes manifests, etc., in order to get their development environments to resemble what’s happening in the production can be overwhelming and distracting, not to mention nearly impossible to perfect in a local environment. Cloud dev environments take away this worry by getting you right to the code-writing phase in a single command. What’s even better is that these environments are ephemeral and sharable, so collaboration across dev, product, and deployment teams is now easier as well.

Big companies like monday.com have reported a huge increase in productivity thanks to the better DevEx cloud dev environments provide:

Learn from the case study of monday.com and see how Okteto helped them take their developer experience to the next level!

Take it from these executives who tried building:

• Marc Campbell, founder of Replicated, says it best: “Easy to develop - impossible to maintain because every day something was broken."
• John Craft, CTO & Co-Founder, Privacy Dynamics: “We spent 12 months building our preview environment system ourselves, but it was never as good as we wanted. We didn't have the bandwidth to manage or maintain it, and it was distracting us from our primary engineering needs.”
• Engineering manager at a leading digital healthcare platform: “We tried to build it in-house, but that failed. Companies don't understand the complexity of what's under the hood when building their cloud dev environments, such as the custom resource definitions and technical design needed to work with Kubernetes.”

Internal Software Development Is Messy

Building software internally, to service your company’s developers, is often an endless, ongoing project to maintain and scale while also accounting for many evolving complex connecting technologies in the world. The blind desire for companies to have their own homegrown development platform is often like the youthful enthusiasm to get a cute puppy.

In both cases, enthusiasm quickly gives way to the realization that there are long-term, serious responsibilities associated with its care. In the case of both, you have to make sure they are safe, secure and bug-free. If there’s a problem, you have to stop what you’re doing and take care of them morning, noon and night. They both require a lot of attention.

5 Challenges to Internal Software Development

But, hey, if you're committed to building here are five simple ways to build your own internal development platform (IDP) and the problems with each approach:

1. Build a custom platform from scratch: This approach allows you to build an (IDP)tailored to your needs. But this costs significant time and resources and building a custom platform from scratch can lead to issues with scalability, security, and compatibility with third-party tools.
2. Use open-source software: Using open-source software can be a cost-effective way to build an IDP, as many open-source tools are freely available. However, open-source software can also introduce compatibility issues, security vulnerabilities, and the need for ongoing maintenance and updates.
3. Adopt a cloud-based platform: Cloud-based platforms, such as AWS or Google Cloud, can provide a scalable and cost-effective option for building an IDP. But relying on cloud-based platforms can also introduce issues with data privacy, vendor lock-in, and service reliability.
4. Utilize low-code development platforms: Low-code development platforms enable non-technical users to create software applications with minimal coding experience. However, this limits control over the development process, and can also introduce issues with scalability and compatibility with other tools.
5. Use a DevOps platform: DevOps platforms, such as Jenkins or GitLab, can automate the software development and deployment process, providing increased speed and efficiency. But this can be complex to set up and requires ongoing maintenance and updates to ensure reliability, security and security.

See? Turns out that owning a puppy - fleas et all - is a lot of work and costs a lot of money. So is building and managing a homegrown development environment. But it's easy to understand how engineering teams fall in love with the idea of building development environments. After all, who knows what engineers need better than the engineers themselves?

When software projects outside a company's core business are built, it usually starts when a developer or lead identifies a specific pain-point in isolation and engages internal engineering resources to come up with an in-house solution. At first glance, this approach makes sense, as internal engineering teams are good at building projects with a limited, well-defined scope. However, as your development team grows and your projects scale, so do the requirements of the platform; and complex business processes often span multiple departments, including collaboration with - but not limited to - DevOps, security, product, QA testing, and more.

Internal Software Development and Platform Building Is Hard

More projects, people, and product features means more potential problems. Sounds like rap lyrics, but this is the truth when it comes to building, especially a cloud development environment. You build it, you own it.

Daily responsibilities continue and challenges can mount. It's the same problem development teams have with their homegrown solution. This predicament begs the question: why spend countless hours having your most valuable resource capital (your engineers) architect a solution that already exists and is proven in the market?

For instance, generally, a vendor has already solved the same problem hundreds of times, bringing clients the benefits of best practices based on others' experiences. In addition, in most cases, the vendor gains efficiencies because of its large customer base, so it can often charge less for implementing and maintaining an established product than it would cost to support a one-off, homegrown solution.

When you flip the script, the solution provider owns the burden of product development, quality assurance, maintenance, platform migration, security,  and patch fixes. In contrast, in-house development requires years of continued development beyond the initial project scope. There’s an opportunity cost and total cost of ownership associated with that that is often overlooked.

Okteto customers who first tried building internally found it required an enormous allocation of resources and budget to create, implement and maintain something as comprehensive and proven. Whether to build or buy a cloud development environment revolves around these four key considerations:

*Ensuring features and functionality were best-in-class

*Supporting performance and maintenance at scale

*Managing the allocation of resources against core business needs

*Realizing the total cost of ownership is more than what it seems

Buying is Better Than Building an Internal Development Platform

Working with a proven partner to deploy a proven solution allows you to solve the problem more quickly and ensures complex questions, such as Kubernetes updates and security breaches, are answered with comprehensive support and development. Additionally, working with a reputable provider to deploy a proven development platform will allow companies to get up and running more quickly and generally ensures that teams can focus on what developers do best: innovation.

Ask yourself how much time and money it will take to either buy software that will fit most of your needs or build a solution from the ground up. And how much will either solution cost you long-term? For instance, creating a cloud development platform with the sophistication to work with Kubernetes could take three to five years.

While developing a solution in-house may initially seem like the best way to address your business challenge, more and more technology leaders are seeing the benefits of buying over building. Commercial solutions provide speed, scale, and efficiency that can’t be matched by in-house solutions.  Building a cloud development platform can be tough o manage and secure. As a result, more companies are asking cloud development vendors, "How much is that doggy in the window"?

The importance of tools that boost a positive developer experience can't be overstated. The industry is starting to recognize that an improved developer experience results in an increase of productivity. And that's exactly why more companies view cloud development environments as an essential investment that unburdens developers from tedious administrative tasks so they can focus on innovation.

The benefits of a cloud development environment include the ability to mirror production, support holistic testing across the entire stack, manage the complicated integrations between microservices and simplify the adoption of Kubernetes.

And while everyone from enterprise CTOs to startup engineering managers agree that shifting from a local to a cloud environment is the future of development, one question remains: "is it better to build or buy the solution?"

To build or not to build - that is the question

Historically, development organizations have built and managed their local development environments; however, the evolution of Kubernetes, containers and microservices have made designing and maintaining a modern development environment complicated — if not impossible. In addition, technology trends force organizations to quickly add new functionality while supporting familiar tools and processes. As a result, it's tough to create a secure, "enterprise-ready" cloud development environment that supports a wide range of developer tools, such as Visual Studio Code and Python, and yet is scalable enough to adopt updates to Kubernetes.

Most of the time, companies see the business benefits of buying software solutions that allow them to focus on their core competencies; however, some organizations, especially those with sophisticated engineering teams, are tempted to build their own solutions — especially when the tools in question help developers develop. It's easy to understand this philosophy: hey, who knows the needs of developers better than a company's own developers?

While developing a purpose-built in-house development environment may appear to be an obvious way to address specific development challenges, it often requires resources -- particularly budget and personnel -- to not just create but implement and maintain. It’s a problem that even some of the smartest engineering teams ignore.

“Easy to build, hard to maintain”

Today, many development organizations are challenged with local environments unable to meet the demands of modern complex cloud-native applications. Replicated, a company that provides delivery and management of Kubernetes applications, first attempted to solve their development problems by creating a homegrown cloud development platform. But unfortunately, they discovered allocating resources to tackle this project distracted from delivering more essential business value. And complicating the developer experience was just the tip of the iceberg - the platform was also buggy, expensive and costly to maintain.

"Our homegrown solution took a massive investment of our engineering to keep Kubernetes, Docker, and all kinds of cutting edge technologies updated and supported," says Marc Campbell, Replicated co-founder and CTO. "It was difficult, taking our engineering team’s time to support because every day something was broken."

Marc quickly realized it was impossible to devote a development team to maintain and support the solution over time. He also admitted that a buggy development platform was increasing the risk of application bugs making their way to production. It was clear that Replicated needed a dedicated development environment and homegrown solutions were incapable of, namely, continuing to add features regularly and provide support.

The business benefits of partnering with Okteto

While developing a solution in-house may initially seem like the best way to address your business challenges, Replicated discovered building a platform requires an enormous allocation of resources in budget and developer time, implement and maintain.

To overcome the challenges of a homegrown environment, Marc and the Replicated team turned to Okteto. Here are just a few of the benefits Okteto’s out-of-the-box suite of features offered Replicated:

• Simplified Kubernetes adoption
• Improved Troubleshooting with Shared Services
• Maximized Inner and Outer Loop Collaboration
• Mirrored production to reduce scrap and rework

"We chose Okteto because it removes the need for every engineer to have a deep understanding of the kubernetes infrastructure that we need to run our system, and it allows us to hire engineers without that level of expertise," says Marc. "Okteto just works; with it we can set the bar higher with what we expect from the dev environment and our team."

Working with Okteto allows you to solve development challenges immediately with comprehensive support and development. So why spend countless hours having expensive engineers — or hiring new ones —  to architect a proven solution that already exists? As the pioneer and market leader in cloud development, Okteto has already solved the same development problem for hundreds of developers.

As final words of advice to other companies considering building their own solution, Marc suggests asking yourself these questions: Are you planning for a support team to work on platform bugs and issues long term? And what are your time constraints to develop, QA, implement, and roll out an internal solution? Says Marc, “When it comes to building a development platform, remember this: Easy to develop - hard to maintain."

Docker's technology helps developers package applications into containers, while Kubernetes helps deploy, scale, and manage them. Both solutions have their strengths and weaknesses, and the choice of which to use depends on the application’s specific requirements. In this article, we’ll dive into the details of Kubernetes vs Docker and explore their differences to help you decide which you should learn first or adopt. We will explore both technologies’ features and examine their pros and cons. Finally, we will look at a comparison between the two orchestration solutions, Docker Swarm and Kubernetes.

What is Docker?​

Docker is an open-source containerization platform that enables developers to package their applications and dependencies into self-contained units known as containers. These containers can be easily deployed and run on any server, making it easier to develop and deploy applications consistently across different environments.

Docker is a container technology that tackles the compatibility and dependency installation challenges that software developers face. This means once you build the Docker configuration, your developers can simply run Docker commands to get started, irrespective of their OS.

Docker relies on two key components for container technology: the container itself and the container image.

Container Images​

These serve as a template for creating a container during runtime. Docker offers a toolkit that helps developers package their applications into container images. To create a container image, developers write a Dockerfile, a set of instructions that tells Docker how to build the image. They then use the Docker server to build the image by running the appropriate commands.

Container images can be used to deploy and run containers on any platform that supports them, including Kubernetes, Docker Swarm, Mesos, and HashiCorp Nomad.

Containers​

Containers are lightweight and portable packages that contain all the necessary code, libraries, and dependencies for an application to run. Developers can create containers without Docker; however, the Docker platform simplifies the process.

Docker’s Features​

The purpose of using Docker is to package applications and containerize them so they can conveniently be shipped at any time to any environment. Some of the features it offers include:

• Isolation: Docker containers isolate applications from the host system and other containers, providing a clean and predictable environment for each application.
• Easy and Faster Configuration: Docker helps you to configure the system quickly and without difficulty.
• Portability: Docker containers can be easily moved between different environments, including local development, testing, staging, and production.
• Consistency: With Docker, you are confident that the app runs the same across multiple environments.
• Scalability: Docker allows developers to build and deploy applications as small, modular components, making it easier to scale applications horizontally across multiple servers.
• Rollbacks and image version control: Docker enables developers to version and track changes to their container images, making it easier to roll back to previous versions if necessary.
• Integration: Docker integrates seamlessly with many tools and platforms, including popular continuous integration and delivery (CI/CD) systems, making it easier to build, test, and deploy applications.
• Resource management: Docker allows developers to set resource limits for containers, helping to ensure that applications do not consume too many resources and disrupt other applications running on the same host.

What is Kubernetes used for?​

Kubernetes (also known as K8s) is an open-source container orchestration tool responsible for managing your containerized applications. It provides a platform-agnostic way to run, scale, and manage numerous containers simultaneously in either physical, virtual, or hybrid environments. It is designed to simplify the management, deployment, and scaling of containerized applications. Kubernetes is one of the most prominent containerization technologies of our time because of how easy it makes to deploy and run microservices at scale.

K8s is a highly modular and extensible platform that offers a range of features such as self-healing, automatic rollouts and rollbacks, load balancing, and horizontal scaling. It was created by Google and is now managed by the CNCF.

Benefits of Kubernetes​

Kubernetes has become the most popular container orchestration platform due to its extensive characteristics. Some of the key features of Kubernetes include

• Deployment and scaling: Kubernetes allows you to deploy and scale your containerized applications quickly. You can specify the number of replicas you want for each application, and Kubernetes will ensure that the desired number of replicas is running at all times.
• Self-healing: Kubernetes includes features for self-healing, which means it can automatically detect and replace failed containers or nodes.
• Load balancing: Kubernetes consists of a built-in load balancer that can distribute incoming traffic across multiple replicas of an application.
• Rolling updates: Kubernetes allows you to perform rolling updates to your applications, which means you can update the application without downtime.
• Configuration management: Kubernetes includes a configuration management system that allows you to easily manage the configuration of your applications and the environment in which they run.
• Service discovery and networking: Kubernetes includes features for service discovery, which allows applications to find and communicate with each other, as well as networking and load balancing features.
• Monitoring and logging: Kubernetes provides several tools for monitoring the health and performance of your applications, as well as tools for logging and debugging.
• Extensibility: Kubernetes is designed to be extensible, which means you can customize and extend it to meet the specific needs of your applications and infrastructure.

If what Kubernetes has to offer excites you and you’re looking to learn more, check out our Kubernetes for Beginners series! We also have a Kubernetes cheat sheet to get you up to speed with all the relevant commands you need to know.

What is the Difference Between Docker and Kubernetes?​

Docker and Kubernetes are both popular tools in the field of containerization, but they serve different purposes and are intended to solve different problems. Docker is a container runtime that helps you build, deploy, and run containers. Kubernetes is a platform that automates the process of running and managing containerized, cloud-native applications created with Docker or other tools.

Kubernetes can be used with Docker and other container runtimes, like containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface). However, most developers consider Docker an excellent choice for container runtimes.

Docker offers an orchestration tool called “Docker Swarm,” which allows the orchestration of Docker containers across multiple systems. If a system needs to scale and add more containerized applications, it might face challenges with Docker that Kubernetes can help address.

Docker Swarm vs. Kubernetes​

Implementing Kubernetes can be complex, especially for beginners, but it provides additional flexibility and functionality. On the other hand, Docker Swarm is generally easier to set up and configure, especially when creating and maintaining your infrastructure. Looking at the current industry trends, though, the adoption of Kubernetes is much more than Docker Swarm!

Docker vs. Kubernetes: When to Adopt What​

Deciding between Docker vs. Kubernetes can be challenging. When you want to containerize your application and make it easier to deploy and operate in different environments, consider using a container runtime like Docker. Docker provides features and tools for creating and managing containers and a simple and effective way to package and distribute programs.

You can consider using Kubernetes to deploy, scale and manage containerized applications. Kubernetes’ features make it well-suited for applications in production environments and simplify managing large and complex deployments.

Conclusion​

In this article, we talked about Docker vs Kubernetes, two of the important solutions for containerization and cloud computing. We have seen the features of both solutions and what they are capable of. Kubernetes has become the go-to solution for deploying to production these days. But this has created a gap in the local environment in which development takes place and production. Okteto helps solve this problem by providing developers a cloud environment to develop in. Checkout out Getting Started guide to begin simplifying modern application development!

The Common Culprit: Secrets Management​

Application Secrets is a broad term that could refer to anything essential for the application's working, but you would want it to stay secret. Often these are API keys, database passwords, and other such things. If someone were to get access to these, they would have the potential to cause a lot of damage and even risk the privacy of your users! That is why keeping your secrets secure and safe is critical, even during your application development.

Secrets can be tricky to handle. Often, you think you have your Secret stored securely where no one can access it, only to learn the hard way that that wasn't the case. Secrets management as it is was a tough job, but ever since we shifted to microservices and container orchestrators - things have gotten a lot more tricky!

Even though it has been a good few years since we adopted these technologies, I feel we still keep seeing these breaches because of skill gaps. This world of Kubernetes was new for everyone, so it's no surprise that we did end up making mistakes in securing our Application Secrets. But to avoid making the same mistakes again and instead learn from them, we need to invest in tools and projects which help bridge this knowledge gap for developers.

If you're new to Kubernetes and looking for a comprehensive guide on the basics, check out our Kubernetes for Beginners article!

Learning From Our Mistakes: OWASP’s WrongSecrets​

The best way to prepare for something is to practice in an environment as close to the actual scenarios you'll be facing. OWASP's WrongSecrets project has a similar ideology. WrongSecrets is an open-source project containing exercises in finding Secrets that have NOT been stored securely. It's an excellent way to learn Secret management in cloud-native applications.

The project's intent is that after going through these exercises, you'll have a better idea of where to look for misconfigured Secrets in your application. The challenges will help you understand better how you've been storing Secrets and evaluate if you need to change your approach towards secrets management. The best part about the project for me is that all exercises are based on actual misconfigurations that have taken place. The maintainers (who are amazing people to talk to, by the way!) have poured their years of valuable experience trying to secure Secrets into the project to ensure others don't end up making the same mistakes.

You can check out the project at: https://github.com/OWASP/wrongsecrets.

The repository provides you with a Java application for which secrets have not been stored properly. These misconfigured Secrets are present in a bunch of different environments, like would be the case for an actual application - in Docker files, Kubernetes manifests, etc. Each challenge holds a lesson in secrets management and represents a real scenario for you to learn from.

To make it easier to run their Kubernetes-based challenges, The project provides users with an option to run them on Okteto. The benefit of using Okteto is not having to spend time configuring a cluster and getting right to the fun parts of solving the challenges! Okteto also makes it easier to deploy the application and spin up the environment with a single click of a button without installing tools like kubectl and downloading the kubeconfig.

Challenge 6 was an excellent learning experience. We often store important data as Kubernetes Secrets and think it's all secure. Still, we need to realize that we also need to configure RBAC around these secrets so that only the processes that require the Secret value can access it and not anyone else! Give them a try, and I guarantee you there's a lot you will learn about secrets management.

If you find the project useful, please consider giving WrongSecrets and Okteto a star on GitHub! :)

Shifting Left Application Security With Okteto​

Providing developers with tools that allow them to be sure that the code they're writing is secure earlier in the development process can be a game-changer if you're looking to secure applications. Okteto enables this by providing developers with a production-like environment to write code in. That means the dev environment now has all the Secrets configured the same way they would be in production. This shifts left the security and allows developers to catch any potentially vulnerable code they write much earlier in the dev cycle. Give it a try to see how Okteto's Cloud Development Environments change the game!

In DevOps, Kubernetes is a container orchestration tool. It is used to deploy and manage containerized applications in an automated way.

Kubernetes was first released in 2014. Since then, its adoption has grown phenomenally and continues to grow steadily. Now, it has become the de facto container orchestration platform of choice for organizations across the world.

In this blog post, we will take a closer look at the components that make up a Kubernetes cluster, which is the foundation of Kubernetes. This will help you understand Kubernetes better. If you're not familiar with Kubernetes basics you could check out our beginners guide.

Kubernetes Architecture Explained​

To understand the Kubernetes architecture better we can break it down into different components. There are different componenets making up a regular node than there are in a control plane node. But before that let's see what the two types of nodes are.

Nodes in Kubernetes Cluster​

A Kubernetes cluster provides the platform to deploy & host containers. It is made up of nodes (physical or virtual machines), which are of two distinct types: the control plane node and the worker nodes.

Control Plane Node​

The control plane node plays a very important role in the Kubernetes Architecture since it hosts the Kubernetes control plane, which is the brain behind all operations inside the cluster. The control plane is what controls and makes the whole cluster function. It stores the state of the cluster, monitors containers, and coordinates actions across the cluster.

Worker Nodes​

Worker nodes are the nodes used to actually run the containers. We never directly interact with the worker nodes. Instead, we send instructions to the control plane. The control plane then delegates the task of creating and maintaining containers to the worker nodes.

We understood that a Kubernetes cluster is composed of two distinct types of nodes. That was the first step to understand the Kubernetes Architecture. Now, let’s look more closely at the components running inside these nodes.

Kubernetes Control Plane Architecture​

The control plane is composed of several components, each of which is responsible for a different aspect of cluster management. Kubernetes Architecture can be explained by understanding them in detail. Some of the main components are:

API Server​

The API Server is the central component of the Kubernetes control plane. In simple terms, it is a web server that listens for HTTP requests. It exposes the Kubernetes API that external clients use to communicate with the cluster. For example, an external client could use the Kubernetes API to get a list of all the running Pods.

Scheduler​

The scheduler is responsible for scheduling Pods on nodes in a cluster. To find an appropriate node for a Pod, the scheduler uses two concepts: predicates & priorities.

• Predicates: Predicates are rules or conditions that the scheduler uses to determine whether a particular node is a suitable place to run a particular Pod. For example, a predicate might check whether a node has sufficient CPU & memory resources to run the Pod. If a node does not satisfy all the predicates for a given Pod, the scheduler will not schedule the Pod on that node.
• Priorities: Priorities are used by the scheduler to rank nodes in the cluster and to select the most suitable node for each Pod. The scheduler assigns a priority score to each node, based on various factors such as available resources on the node, the number of Pods already running on the node, and the overall health of the node. When it comes time to schedule a Pod, the scheduler will select the node with the highest priority score that satisfies all of the predicates for the Pod. This ensures that Pods are scheduled to maximize the utilization of cluster resources.

Controller Manager​

The controller manager is a component that runs a set of controllers that are responsible for managing the state of the cluster. It provides the controllers with access to the API Server, where they can access the current state of the cluster. It also gives them access to the etcd distributed database, where they can store and retrieve the desired state of the cluster.

In Kubernetes, a controller is a piece of software that continuously watches the state of the cluster. And it makes changes to the cluster to move the current state toward the desired state.

For example, a Deployment is a Kubernetes resource that specifies the desired state of a group of Pods, such as the number of replicas and the template used to create the Pods. The Deployment controller is a type of controller that watches the current state of Deployments in the cluster. It ensures that the actual state of the Pods matches the desired state specified in the Deployment. If the current state deviates from the desired state, the Deployment controller will make changes to the cluster, such as creating or deleting Pods, to bring the current state back into alignment with the desired state.

Etcd​

Etcd is a key-value data store, used by Kubernetes to store its configuration data & cluster state.

Etcd is used by other components of the Kubernetes platform to store and retrieve the data needed for their operation. This can include information about the containers and pods running on the cluster, as well as other data related to the state of the cluster.

The only component that talks to etcd directly is the Kubernetes API server. All other components read and write data to etcd indirectly through the API server. This way updates to the cluster state are always consistent. The API server also makes sure that the data written to the store is always valid and that changes to the data are only performed by authorized clients. You can learn more about etcd here.

Kubernetes Worker Node Architecture​

I hope you're now able to understand some of the Kubernetes components. Now we'll learn about the components making up the worker nodes in K8s.

Container Runtime​

Kubernetes is a container orchestrator. Yet, Kubernetes itself does not know how to create, start, and stop containers. Instead, it delegates these operations to a pluggable component called the container runtime. The container runtime is a piece of software that creates and manages containers on a cluster node.

Kubernetes supports multiple container runtimes, including containerd & CRI-O. In addition to containerd & CRI-O, Kubernetes also supports any other runtime that implements the Kubernetes CRI (Container Runtime Interface). It specifies the interface that the container runtime must implement to be compatible with Kubernetes. This makes it easier to integrate new or custom runtimes, allowing the users to choose one that best suits their needs.

Kubelet​

Kubelet is an agent that runs on each worker node. Its main responsibility is to run & manage the containers associated with a Pod.

When the control plane decides to schedule a Pod to a particular node, it sends the Pod definition to the API Server. The Pod definition specifies the containers that should be included in the Pod, as well as their requirements & dependencies. Then, the kubelet on the node receives the Pod definition from the API Server and uses it to run the containers.

To do this, the kubelet communicates with the container runtime & provides it with the necessary information, such as the image to use and the required resources. The container runtime then uses this information to pull images from an image registry and run the containers based on those images.

The Kubelet is also responsible for ensuring that the Pods are running and healthy. It does this by running health checks on the containers and monitoring their resource usage.

For example, the kubelet can use a liveness probe to periodically check that a container is still running and responding to requests. If the liveness probe fails, the kubelet will restart the container and try to get it back into a healthy state. Similarly, the kubelet monitors the resource usage of the containers to ensure that they are not exceeding their allocated resources. If a container is using more resources than it is allowed, the kubelet will take action to prevent the container from overusing the resources and potentially impacting the performance of other containers on the node.

Kube-proxy​

Kube-proxy runs on each worker node and is responsible for enabling communication between the containers on the node & the rest of the Kubernetes cluster. The kube-proxy uses a variety of techniques to enable this communication, including:

• Network Forwarding: The kube-proxy uses network forwarding to route traffic between the containers on the node and the rest of the cluster. This allows the containers to access services & other resources that are available in the cluster, such as databases & other services.
• Load Balancing: The kube-proxy can also provide load-balancing for the containers on the node. It helps to distribute incoming traffic across the containers on the node, ensuring that no single container becomes overloaded. This improves the performance of the application

Conclusion​

This was a simplified overview of the Kubernetes architecture. Now, you should have a big-picture understanding of how different components of a Kubernetes cluster communicate with each other & how Kubernetes functions as a whole. If you want to learn more about Kubernetes, you should check out our Kubernetes for Beginners blog for a comprehensive guide!

Containers quickly became the norm for how we built and packaged our applications. Containerization of applications made the software delivery and development cycle easy by providing a convenient way to run applications anywhere - without having to worry about setting the environment up from scratch every time. But, to run our containerized applications in production, we still needed to solve a few pieces of the puzzle. And that's where Kubernetes came in to the picture.

Problems With Containerization and Production Setups​

Since containerization became the norm, we started having a separate container for each of our application microservice. But containers are meant to be ephemeral, and things can and do go wrong in production. This can lead to containers going down unexpectedly. And this is just one of the many problems associated with containerization. Long story short, we couldn’t just run containers directly to serve our applications. We needed something to manage these running containers - a container orchestrator (like Kubernetes).

Managing a few containers to serve your application might still be possible with manual effort, but to run containers at scale, we needed some way to automate all the operational tasks associated with containerization. Container orchestrators like Kubernetes take care of all this. They are responsible for managing the complete container lifecycle and ensuring your applications are always up and running for users to access. They remove the manual effort of monitoring and managing containers by automating the whole process. Some of the tasks they generally take care of are:

• Deploying containers with the correct application images
• Monitoring provisioned containers and checking if they are healthy
• Scaling up or down the number of containers based on the application traffic
• Balancing load between different running containers using services

When it came to containerization, two prominent names appeared: Docker Swarm and Kubernetes (K8s). Let’s see how they differ and which one might be ideal for your use case.

Docker Swarm vs Kubernetes​

Containerization started a war between Docker Swarm and Kubernetes. Deciding between the two primarily depends on your use case. Docker Swarm is an easy to set up and maintain solution when you want to manage simple workloads. It has a lower learning curve and is lightweight. If you have a relatively simple application and don’t have the time to invest in a complex solution, Docker Swarm might be the better choice for you. Kubernetes, on the other hand, offers a lot more features and should be the choice if you want to run complex workloads at scale effectively. It has a lot larger open source community than Docker Swarm and is offered by all the major cloud providers. It also has a vast ecosystem of tools built around it which extend its capabilities and make it the ideal choice for enterprises managing their microservices based applications. But the problem with Kubernetes is that it can be tough to learn and set up when getting started initially.

If you’re looking to get started with containerization and Kubernetes, check out our Kubernetes for Beginners blog to get learning!

Migrating your existing applications and development workflows to containers running on Kubernetes can be a tough task. If you’re struggling with that, Okteto can help make the migration easy and simplify how you develop cloud native applications! Reach out to us to talk more :)

How Kubernetes Helps With Containerized Applications​

Now that you have an idea of why containerization with Kubernetes is helpful, you might be wondering how exactly does this work. K8s works on a declarative system to manage your containerized applications. You tell it how you want things configured by writing a YAML file, and then it will work towards bringing up all the required containers and other needed things.

Then it also continuously monitors the resources it has created and checks that they still match the state we had described in the configuration file. If that’s not the case, it takes the necessary actions required to get to that state. This is how Kubernetes functions as a container orchestrator and avoids application downtime.

Now that you recognize the usefullness of Kubernetes and will be using it to deliver, deploy, and run containers, give Okteto a try and immediately get the development environment to the K8s level and save development time and resources!

Developing Containerized Applications on Kubernetes With Okteto​

Containerization of applications has made Kubernetes the go-to tool for running things at scale. It has changed how we deploy our applications. But the development of these microservices based applications has still been an area that is lacking behind. Mainly because we’ve been using the same old tools for development that we used before containers came into the picture. Okteto simplifies the development of containerized applications by allowing you to write code in an environment that is exactly like production. This is done by leveraging Kubernetes during development as well! Check out our Getting Started Guide and learn how to simplify the development of your containerized applications.

Introduction to kubectl​

The most common tool to interact with a Kubernetes cluster is kubectl. This allows you to interact with the objects you create, view logs, etc. But as anyone who’s just starting to learn K8s will agree, THERE ARE JUST TOO MANY KUBECTL COMMANDS TO KEEP TRACK OF!

But don’t worry; this kubectl cheat sheet is going to be my attempt to simplify things. We’ll go over the most common commands you’d find yourself using throughout your K8s journey. Here’s a meme to ease you in before getting started.

Also, if you’re completely new to Kubernetes, you might want to check out our Kubernetes for Beginners blog before proceeding. Now let's begin with our Kubernetes command cheat sheet!

Cluster Info and Configuration​

Often you need to get information, not about the application but the cluster itself. Here are a few Kubernetes commands in our cheat sheet which help with that:

• kubectl version: Gives information about what version of Kubernetes the client and server are on.
• kubectl cluster-info: Displays the endpoint of the Kubernetes control plane.
• kubectl config get-contexts: Lists all the contexts present in the current kubeconfig.
• kubectl config use-context <context name>: Allows you to set the default context for all the kubectl commands you’ll run.

Namespaces​

Namespaces play a very important role in clusters. No kubectl cheat sheet can be complete without including commands which help you work with them. They act as a way to organize and isolate the different resources your application might need. By default, you’re in the default namespace (surprise, surprise!), and the resources Kubernetes needs for its functioning are in the kube-system namespace. Here are some other commands related to namespaces you’ll find yourself using frequently:

• kubectl get namespaces: Often, you’ll find that you’ve lost track of all the namespaces you’ve created. This command will help you out by listing them all.
• kubectl create namespace <namespace name>: This command would create a new namespace for you. Note that it will not set that namespace as the default one, though. So all resources you create will still be created in the default namespace unless you specify the --namespace flag explicitly.
• kubectl config set-context --current --namespace=<namespace name>: This allows you to change the default namespace for all the commands you’ll run while still keeping the same context. Just remember that the default namespace is called default in case you ever want to switch back.
• kubectl delete namespace <namespace name>: This deletes the specified namespace and all resources under the namespace! The deletion of resources is an asynchronous process, so don’t be surprised if you see your namespace in the “Terminating” state for a while before it’s completely gone.

Pods, Deployments, Secrets, etc​

Now there is a certain set of commands which you’ll find yourself using a lot when interacting with most of the Kubernetes resources. Just put in the resource name instead of X, and you should be good to go with these:

• kubectl get X: Lists all resources of that particular type in the current namespace.
• kubectl create X <name> <other properties>: Creates the “X” resource in the current namespace with the specified name. In most cases, you would have to specify some additional flags to actually create that particular resource.
• kubectl delete X <name>: Deletes the “X” resource with the given name in the current namespace.
• kubectl describe X <name>: You’ll find yourself using this one a lot when debugging things. This provides details and events related to the resource you specify.
• kubectl edit X <name>: This command will allow you to edit the specified resource directly without having to deal with any YAML. Remember to make the changes to your YAMLs once you’re satisfied with your edits because the edits don’t persist once the resource gets deleted!

Nodes​

Next up in our kubectl cheat sheet are commands related to nodes. Nodes are what build your cluster, so it’s no surprise that you’ll often find yourself interacting with them. The following commands are worth keeping a note of:

• kubectl get nodes: Shows a list of all the nodes along with their role (control-plane, worker, etc.) and the version of K8s they are running.
• kubectl top node <node name>: Shows the CPU and memory usage of the specified node.
• kubectl cordon/uncordon node <node name>: Cordoning nodes means marking them as unschedulable; that is, no pods will be placed on that particular node. This is useful when you want to isolate a node for something like updating its version or debugging.
• kubectl drain node <node name>: You’ll find yourself using this command when doing maintenance tasks for your cluster. Draining a node, cordons it as well, and deletes all pods running on it. If those pods are being managed by a Deployment, DaemonSet, etc., they will be recreated on the remaining nodes.

Other Common Kubectl Cheat Sheet Commands​

Finally to finish our kubectl cheat sheet let's discuss some commands which don’t exactly fit into any single category, but you’ll find yourself using them a lot.

• kubectl apply -f <filename.yaml>: If you’re creating K8s resources using YAML files, then this is the command you should be using to apply those YAMLs. If the resource specified in the YAML already exists, then this command would update that resource with the latest configuration specified in the YAML file.
• kubectl delete -f <filename.yaml>: This command deletes all the resources specified in the particular YAML file.
• kubectl port-forward <pod name> <local port>:<remote port>: Relying on services to expose your application to external traffic isn’t always convenient, especially when you’re debugging. The port-forward subcommand provides you with a simple way to do this by letting you forward a local port to a specified port in the mentioned pod.
• kubectl logs <pod name>: This is a very useful command for debugging your deployed application. This command prints the logs for the container running in the specified pod. If your pod is running more than one container, you can additionally specify the --container flag to mention which container’s logs you want to see.

Who Are These Kubectl Cheat Sheet Commands For?​

While we discussed some common Kubernetes commands in the form of a cheat sheet that you’d find yourself using when working with K8s, I believe that it is not developers who should be taking care of these K8s related tasks. Having developers deal with the infrastructure and deployment side of things during the development process takes a massive hit on productivity and also leads to a poor developer experience. With Okteto, you can define all the things you need to spin up your dev environment in a YAML and have developers skip right to the code-writing phase by running just one single command. Try our Getting Started Guide to see the magic for yourself!

In this article, we’re going to learn about one of such resources K8s provides right out of the box to make your deployed applications a bit more secure: Kubernetes Network Policies.

Why Network Policies in Kubernetes Are Important​

When learning about something new, I often find it easier to understand if I start with learning the “why” it was needed, even before knowing “what” it actually is. Let’s do the same with Network Policies, and I’m sure you’ll have a much easier time understanding them! :)

By default, Kubernetes allows traffic from all pods to reach all other pods. But this isn’t something you’d want in production. Why? Because this way, if a pod gets compromised, it will be able to affect other pods and potentially compromise the security of your entire application. Network Policies provide a way to restrict traffic in your cluster so that only legitimate traffic can flow - where the term “legitimate traffic” is for you to decide based on your application.

For example, if you’ve deployed a full-stack application by default, the frontend pods will be able to communicate with the backend as well as the database pods. But we know that the frontend pods don’t actually need to talk to the database pods directly.

In this scenario, it would be ideal for us to leverage Kubernetes Network Policies to allow traffic from the frontend pods only to the backend pods. This way, even if the frontend pods get compromised, we can be sure that our database won’t be affected!

Now that you have an understanding of what utility Network Policies serve let’s start learning about them in more detail.

What Exactly Are Kubernetes Network Policies​

Network Policies are a resource in Kubernetes responsible for controlling traffic to and from pods running in a cluster. With Network Policies, you select pods using labels and then specify rules for these selected pods. You can utilize a combination of the following three to precisely control traffic:

• Other pods: You can select other pods using labels that should be allowed to talk to the selected pods.
• Namespaces: You can select complete namespaces as well. In this case, all pods in the namespace would be able to communicate with the selected pods.
• IP blocks: You can specify CIDR ranges from or to which traffic is allowed for the selected pods.

Kubernetes Network Policy Example​

Let’s look at a Network Policy example resource and then see how we can define network policies in K8s. Warning: things aren’t as scary as they might look at first glance! :P

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sample-network-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: firstproject
        - podSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 4614
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              project: secondproject
      ports:
        - protocol: TCP
          port: 1010

Like most other K8s resources, the NetworkPolicy resource also has the usual apiVersion, kind, metadata, and spec fields. The spec field is where things get interesting! You’ll mostly see the following things under this field:

podSelector​

This is where we select the pods we want the policy to get applied to.

policyType​

NetworkPolicies have two types: Ingress and Egress. A NetworkPolicy resource can be of any of the two types (or even both!). Ingress refers to the traffic entering the pods we select under the podSelector, whereas Egress refers to the traffic leaving the pods. The policyType field indicates whether we will specify ingress rules or egress rules, or both for the pods we’ve selected in our NetworkPolicy resource.

ingress​

Ingress is where we list rules for what traffic is allowed to enter the selected pods. All the listed rules get ORed.

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: firstproject
    - podSelector:
        matchLabels:
          role: client

The above section in a network policy would allow traffic to the selected pods:

• from all pods in the namespace with the label "project: firstproject" and,
• from all pods with the label "role: client" regardless of which namespace they are present in.

In case you wanted a combination of both of these rules, your ingress section would look something like this:

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: firstproject
      podSelector:
        matchLabels:
          role: client

Now, this would allow traffic only from pods with the “role: client” label present in the namespace with the “project: firstproject” label.

The selection capabilities are quite powerful, no?

The ports section simply specifies the ports on which the selected traffic is allowed.

egress​

Similar to ingress in terms of selecting things, the only difference being that egress is where we select where traffic is allowed to go from our selected pods.

egress:
    - to:
        - namespaceSelector:
            matchLabels:
              project: secondproject

So in the above example, the selected pods are allowed to send traffic to all pods in the namespace with the label “project: secondproject”. The selection rules for egress get ANDed and ORed, similar to ingress rules. The ports section, too, like in the case of ingress, specifies what ports the rules are valid on.

Now that you have a general idea of what a NetworkPolicy does and looks like let’s see things in action!

Working With Network Policies​

We’ll keep things simple in this section but, at the same time, ensure that you’re able to understand Network Policies in detail. We’ll work with two pods: frontend and backend, and test the connectivity between them before and after creating some Network Policies.

Let’s first create both our pods:

$ kubectl run frontend --image=nginx
$ kubectl run backend --image=nginx

If you want to learn more about common kubectl commands check this blog out!

Next, let’s just expose both these pods by creating cluster internal services so that its easier for us to check the connectivity between them:

n commnandsn

$ kubectl expose pod frontend --port 80
$ kubectl expose pod backend --port 80

Confirm that everything is working as expected by running kubectl get all:

NAME           READY   STATUS    RESTARTS   AGE
pod/backend    1/1     Running   0          3m10s
pod/frontend   1/1     Running   0          3m18s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/backend      ClusterIP   10.120.37.122   <none>        80/TCP    67s
service/frontend     ClusterIP   10.120.39.94    <none>        80/TCP    72s
service/kubernetes   ClusterIP   10.120.32.1     <none>        443/TCP   257d

Now, if you remember, at the start, I mentioned that by default, all pods in K8s are allowed to interact with each other. Let’s confirm this by trying to ping the backend pod, using the cluster IP of its service, from the frontend pod by running the exec command:

$ kubectl exec frontend -- curl 10.120.37.122

You should get the following output:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="<http://nginx.org/>">nginx.org</a>.<br/>
Commercial support is available at
<a href="<http://nginx.com/>">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

We see the HTML output for the NGINX starter page, which confirms that we were successfully able to ping the backend pod.

You can also try this the other way around as well by running:

$ kubectl exec backend -- curl 10.120.39.94

Let’s now create a very common policy called “Default deny”. Once this is created, it will restrict ALL traffic for ALL pods in your cluster. This is a very convenient and common way to begin thinking about networking rules in your cluster. You begin by stopping all traffic and then create more network policies only for the traffic you want to allow.

Here's an example of a default deny network policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Specifying {} for podSelector simply selects all pods and not writing an ingress or egress section while mentioning them both under policyTypes blocks all traffic.

Try running the kubectl exec commands we ran before now. You’ll notice that it doesn’t show the HTML and just keeps loading. This is because of the Network Policy that we just created!

Now let’s make sure our frontend pod is able to communicate with the backend pod. For this, we would need to create two rules:

• One egress rule which allows outgoing traffic from the frontend to the backend
• One ingress rule which allows incoming to the backend from the frontend

The following policy will select the frontend pods and allow outgoing traffic from them to reach the backend pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      run: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              run: backend

Try rerunning the following command to test if things are working or not:

$ kubectl exec frontend -- curl 10.120.37.122

You’ll notice that it still doesn’t work. And that’s expected! Right now, we’ve only created a policy that allows traffic to leave from the frontend pods to the backend pods. The backend pods still need an ingress rule to allow incoming traffic from the frontend pods. Let’s create another policy to achieve this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      run: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              run: frontend

Once you’ve created both of these policies, try pinging the backend pods again, and it should work! You can also try pinging the frontend pods from the backend ones and confirm that it still does not work because of our default deny policy.

Wrap Up​

I think you can now start to appreciate how Network Policies can play a crucial role in helping you ship secure applications. We learned why Network Policies are needed and how they work and then saw them in action. If there is one piece of advice I want to leave you with before concluding, it's that when managing traffic in your clusters, it is best to only allow the required traffic and block everything else!

Okteto allows developers to work on their applications in a production-like environment. This means you can use Kubernetes resources like Network Policies right during the development phase. This allows developers to be sure that the code they write is secure and won’t break in production. Check out our Getting Started guide to learn more!

The Challenge Kubernetes Created​

GitOps emphasizes a declarative state for your infrastructure stored in a version control system. But why would we need to apply this to development environments? Why can’t we simply just continue writing code the way we did before?

One reason is that the modern applications we work on these days have multiple components. Because of this, developers now have a really hard time setting up their development environment. They have to go through numerous READMEs, full of instructions about setting up dev infrastructure, which they might not even fully understand or run hacky bash scripts, which might fail and are tough to maintain. All of this leads to developers spending hours of pre-work to get to the “code writing” phase. This makes for a terrible developer experience in teams. It is not fair to expect developers to configure and debug things in “Kubernetes land” instead of writing code.

Today’s reality is that developers have two options:

• To continue developing locally. Which meant they would not get genuine feedback when developing since locally bringing up applications is impossible to reflect production of microservice applications.
• Or to spend hours configuring a production-like development environment for themselves. This is not only wasted dev time but also requires developers to keep up with the ever-growing cloud native ecosystem of tools.

GitOps to the Rescue​

Okteto solves the problems we discussed above by leveraging GitOps principles. Using Okteto, you can have all the configuration required to set up a production-like development environment defined, as code, in a version control system. Once that is done, any developer on your team can simply run a single command to get right to the “code writing” phase without worrying about the nuts and bolts of configuring Kubernetes.

Okteto deploys your application to an actual Kubernetes cluster using the same manifests you use in production and then allows you to develop it there directly. The best part is that just like GitOps advocates, the entire configuration for your dev environment is stored in Git. Okteto leverages the idea of “development environments as code” by allowing you to specify all the configuration needed to spin up a dev environment in a single file: the Okteto manifest. This file is committed along with the application source code to a version control system. Once that is done, any developer on your team can simply clone the repository, run okteto up, and have a production-like environment ready for them to develop in.

Utilizing GitOps principles for your dev environments significantly improves developer experience by making things simple for everyone:

• The infrastructure team now only has to manage a single file per application where all the configuration for development environments lives
• Updating the dev environment is now as simple as making a change in your Okteto manifest and sending a PR
• Developers have to spend ZERO time configuring things and can have the dev environment launched in one command

Benefits​

With Okteto, just like in GitOps, a single source of truth can power development environments for all developers on your team. This approach has numerous benefits which make working on cloud native applications a lot easier than before:

1. Developer Experience When the entire configuration needed to spin up a development environment has been defined as code, developers on your team don’t have to spend hours with configuration or spent cognitive load. A single command gets you right to the code writing phase. This also enables new developers on your team to get up to speed much more quickly than possible before!
2. Consistency Having a single file power every developer’s dev environment ensures that there is consistency in workflows across your entire team. This leads to easier debugging and more effective collaboration because the focus can now be shifted to the actual application problems instead of worrying about infrastructure and configuration related issues.
3. Reliability Since your development environment is defined as code and stored in Git, you can leverage all the benefits of working with a version control system. From having a log of all the changes made to being able to easily revert back in case of things going wrong, this approach ensures you always have a safety net to fall back on.
4. Security Having developers write code in secure environments is very important. Using vulnerable container images during development can be a huge risk compromising the security of your organization. With Okteto, you can periodically check the committed manifest for vulnerabilities and ensure that your mean time to recovery is minutes and not hours in case of an incident. Fixing things for everyone on your team is as simple as raising a pull request which updates your Okteto manifest!

A couple of years ago, the benefits you would get from “GitOpsifying” your development environments wouldn’t have been that significant. But now, I would say that if you’re looking to unblock dev productivity, it’s absolutely essential for you to have your development environments as code in a version control system. Go try our Getting Started Guide to see how Okteto helps with this!

We captured that conversation here…

Introduction​

Ramiro Berrelleza, CEO & Co-Founder, Okteto: When Pablo, Ramon and I started Okteto, the idea came out of common frustrations we each had. We had worked in similar companies, building SaaS products in the early days of Kubernetes and Docker. We saw these same problems across companies; complex environments, slow onboarding, it was hard to validate if changes worked or not until you got production, we had shared test environments that were broken half the time and the other half they just didn't work. These pain points led us to starting Okteto.

I'm excited to talk to Lior and Ron about what they're building, the why behind their decisions and the benefits and challenges of building DevEx initiatives.

How did you start recognizing that Development Experience mattered for your company?​

Ron Barabash, Chief Architect, Yotpo: For us it’s a story of growth in headcount and especially in R&D. COVID also changed a lot of the way we work in our day to day.

In the past, you have your developer paired with likely a more senior developer or somebody that is your buddy when you're onboarding, so you can speak with them and they help you out with setup of things like a development environment. And as we kept growing in headcount and with COVID everything moved to be more distributed globally - you no longer had that person sitting at the desk next to you. We saw that it became very difficult to onboard new teammates.

I started my current position 2 years ago. At first, I mapped out all phases of the SDLC (Software Development Lifecycle). I analyzed stages from creating new services, to development, testing, and build to CI/CD deployment of services. I started mapping out where the challenges were for the entire R&D team and we saw that the first major pain point for us was setting up a remote environment for our monolith application. And that journey of high-growth in headcount, moving to a distributed company policy and also the decomposition of our monolith to microservices is what led us to evaluate our internal development experience.

Lior Rabin, DevEx Team Lead, monday.com: Yeah, I totally relate with what Ron said. I started at Monday.com in the height of COVID. I was assigned an onboarding task and my goal (and every new developer joining) was to deploy something to production in the first week. I started off by setting up my dev environment. Here I was, a developer with 10 years of experience, trying to setup the environment and it doesn't work. I'm sitting at home and I tell my buddy on Slack that this setup doesn’t work. I’m sending him snapshots and trying to figure it out but it’s really hard to do async. It’s like the last thing you want to do on your first week as the new person is to have a zoom call for setting up your environment - that looks a little strange. So in summary, I didn’t hit my goal and I deployed to production on the second week.

That experience really annoyed me. We had also just moved to Docker and Docker Compose, and this was the shiny new environment. And I said, oh my god, what was this like a month ago? I think this was one of the first moments that I thought I came to a big company and everything should go smoothly and this can’t be how it should work.

And as Ron mentioned, we were experiencing hyper-growth at monday. We almost tripled ourselves in the R&D department. At monday, the developers have full ownership end-to-end, so they're a bit of a product people, a bit of QA, (we don't have dedicated QA) they also own metrics of their features and the data. They don't need to "waste" their time on setting up stuff for their local environments. They just need to sit on their laptops and start developing and doing impactful work.

This was one of the big motivations that drove us to creating a DevEx team.

What is the team structure?​

Lior, monday.com: As we grew, we understood that we needed to split the Infrastructure group into Production Engineering and DevEx. The production team are the engineers serving monday’s customers. And the DevEx team is "serving" a different type of customer, which are the monday engineers. This is also how we present it in job interviews - you have a responsibility to your customers which happen to also be monday employees.

How do you see your team's responsibilities evolving as you continue to grow?​

Ron, Yotpo: We are currently building what I call our entire platform engineering department at Yotpo. Since it’s so new, we thought about having a developer platform. You see that in a lot of companies right now, where R&D is growing and you want to have a centralized, internal and kind of like an opinionated platform. This is your product as an internal team. And it’s the team's responsibility to figure out how to expose your services to your [internal] customer.

The way I treat it is that we have our developer platform and part of it consists of our cloud environments. Developer Experience something that is being molded into and thought about with everything that you do. Like if you create a new service, what is the developer experience there? If you do monitoring, observability, etc, how is the development experience? So basically in every part of the software pipeline we ask ourselves is the developer experiencing something that we are proud of and something we are satisfied with.

Another aspect, especially with Kubernetes and cloud services becoming a lot more distributed is that everything is becoming a little bit more complex. And similar to Monday, at Yotpo developers have an end-to-end responsibility and ownership of their services. So we really want to reduce the cognitive load for them.

And because of that, we're using our platform engineering groups and improving developer experience on all fronts. I think it's a blowing up trend and I'm not seeing it go away anytime soon.

Lior, monday.com: Yeah, I totally agree. It’s funny, it’s like we are working at the same place - our story is so similar. We did not prepare for this talk, we’ve never met before, I promise!

At monday, we're also building an internal platform and my team, the Developer Experience team, is the team responsible for it. It’s a collaborative effort and not only us building it, but we lead it. In this platform we create a lot of services and we want this flow seamless, fast and as fail-proof as possible.

For example, when a developer creates a microservice, it's a click of a button and two check boxes. After two minutes, you can start developing because it's on Okteto from a template and it's all working with no friction. A few more button clicks and it goes to staging. It's amazing. It's a process that used to take us a couple of weeks, plus a few internal tickets for the team to create those resources and the helm charts or whatever. Today it’s just automated and it's a super, super good experience for the developers.

With this workflow the infra team is no longer the bottleneck. We're around one infra team member for every nine developers. The developers work a lot and we [the infra team] were a huge bottleneck to their work. Now that we have this platform and these automated processes, it reduces our tickets influx and things are moving fast while we can reinvest our time back to important infrastructure work like monitoring, building more regions, more clusters, etc.

Another benefit of this has been improved developer experience for the infra team. Our goal and vision is to automate as much as possible. The first part was setting up dev environments but then by using those environments we can reduce the load from staging environments. With faster inner loops, we don’t need multiple staging environments now, we could have one staging which is production-like. At one point I think we had 5 to 6 staging environments and it just doesn’t make sense when you can develop remotely. We aren’t completely there yet, but this is the vision.

Do you think Development Experience is something only for larger teams at big companies, or should startups be thinking about it from the beginning?​

Ron, Yotpo: Yes, I think you should take a proactive approach when it comes to building a decent developer experience. Because it’s something that can actually grow, in a bad way, and blow up in your face.

As we saw with both of us at Monday and Yotpo, our first use case for Okteto started with our legacy applications, our monolith. Mostly because it's very hard to work with and having a one click deployment made it really easy.

So in that regard, smaller startups might not have these legacy apps and monoliths to see the immediate use case, but eventually you’re going to want to think about how your teams are organized and what they consume, and teams that need services from other teams. It’s going to happen where you’ll need a way to deploy something that is not your direct responsibility or project. And if you can deploy that in one-click and work against it in a cloud development environment with no friction, that’s super powerful.

Lior, monday.com: I think the main advantage is that you can deploy it and just forget about it. So I think for a small team it’s still very powerful to think about this workflow. Maybe you didn’t develop a service yourself, you didn’t work on that project and maybe the other developer is unavailable and you don’t have context or know how it works exactly, but you just need it to work. It can be simplified from the beginning.

Maybe at a three-person startup you don’t need a dev platform in your first days, but there are things like what we are talking about that will help you along the way. In some ways, at a startup you might have more to work on as an individual than at a big company. So if you can save time and some headaches by using cloud environments, why not? The technology is there - just use it!

How do you get Developer buy-in for something that’s a big shift in culture or workflow?​

Ramiro, Okteto: I’ve worked in developer tooling for a long time and I’ve learned over the years that it’s really hard to convince developers to change their tools or the way they work. You can’t force developers to adopt something new. At Okteto, we of course dogfood and use cloud environments because they believe in the technology and see the value. But if I we’re to say hey let’s use Jira (disclaimer: I worked for Atlassian for many years), they would say “yeah, yeah, you use Jira, we’re going to use something else”. My point is, it’s a hard drive and I think you have to really pull out the use case for them. What have you found to be helpful as you shape new development experience paths for your teams?

Ron, Yotpo: We started off by launching an internal survey for our R&D organization. The whole purpose of the survey was to identify what the most painful points of their jobs were. We learned that their highest pain point was development environments. So we took that information and found a solution. We said hey, if that's your biggest problem, try this tool, Okteto, that we just implemented and see if it helps. And today I think Okteto is the most adopted tool across the entire R&D organization at Yotpo.

That’s because we actually solved a really big pain for our customer (internal developers) The way we went about it was to do a POC and a POC team which created the entire infrastructure for it. They led the POC and worked alongside our developers to create a really good experience for them. Because of that, the adoption just blew up.

In summary, if you want developers to adopt something, solve something that is really painful for them and they will come.

Lior, monday.com: I think that is an important point. If you help them, you don't need to force them.

We did find a similar thing. We already knew that people had a lot of problems with their environments. We started the POC with Okteto and defined every touch point with one microservice to work on. I posted a question in Slack asking if some developers wanted to join the experiment to solve the environment issue. I needed help on this because I’m not a developer on my day-to-day. I wouldn’t be the one using this every day and I needed their input.

I was a bit surprised when 10 developers said they wanted to join the POC. And it quickly spread across the organization and in a matter of days the POC experiment team grew to 30 developers. It was really crazy the adoption rate with Okteto. All 120 developers we had at that time moved to Okteto quickly after the POC was done and we finalized an agreement.

How do you measure success in your DevEx initiatives?​

Ron, Yotpo: It's a really good question. Right now one of the biggest things that we actively seek to measure is your R&D velocity. You can start off by looking at DORA metrics and lead time is probably the most meaningful one when you talk cloud development environments.

This can also be one of the hardest things to measure when not everything is streamlined and you have unified pipelines for example. It's very hard to measure so the first thing that we do in order to prove the value of that kind of project, or any developer experience initiative, is to show adoption usage and also what I call customer testimonials.

I did this recently when I was presenting to management. I wanted to communicate how successful the initiative was. So I presented customer testimonials, stuff that the developers said to me when they started using Okteto. I also showed adoption and how many people are using it.

Those are helpful when showing success and I also believe DORA metrics is a very good way to kind of understand if the things you are doing are actually meaningful in terms of velocity. So we are not there yet, but we’re working on it.

Ramiro, Okteto: How do you track DORA metrics? What are using?

Ron, Yotpo: We did a POC with a bunch of companies like LinearB and OKAY Engineering. Basically those tools are sitting on top of your GitHub and JIRA and are digesting all the activity that is happening and showing you lead time, which is how long it takes to take something from development into production.

Again, we had some trouble initially understanding if those metrics are right for us and how they are being measured. We need to do a lot of work to streamline the interim process along GitHub and Jira before we get value out of using a tool like that.

Lior, monday.com: For us it’s almost entirely usage that we’re tracking. We have some manual surveys around developer experience that gives us good feedback, but we don’t have too many success metrics outside of usage.

What were some challenges you had integrating Okteto into your environment?​

Ron, Yotpo: One initial challenge was that we had to pick the use case that we wanted to do the first POC implementation around. It was important to us that the project solved a real, painful problem for developers, and that was the key success criteria for the POC. So for us we started off with something small and we didn’t build anything new and in the end it didn’t solve a big problem, so it didn’t seem successful to us.

But eventually we found the right use case. It was the biggest pain point and most hard thing to do for a dev at Yotpo. So we figured if we can solve that, it’s very valuable.

My advice when selecting or introducing any new technology is to frame it in regards to solving a real problem and work with your customer or employee peers to scope and solve it. Usage is super important so I’m going to make sure I do everything I can to troubleshoot and help the customers, because onboarding any new tool is a big lift. Developers have many other things to do so you need to be very proactive if you are going to ask them to experiment and onboard a new tool. Take a very hands on, engaging and supportive approach.

Lior, monday.com: The most challenging thing was to make our monolith work because it had a lot of moving parts at the time (and has even more today). It was a very deprecated old version of rails and it had a lot of dependencies of some very hard coded stuff that was mostly technical. We chose this as the POC project because it was the most difficult thing for us. We said, if we solve this, all those other node.js microservices are peanuts.

During the first month of the POC, Okteto’s CTO Pablo, really dug into the repos - he probably knows our code better than me now - and he fixed and optimized a lot of the code to make it work. But we have some technical limitations on our side that are preventing us from using all of Okteto’s features like Preview Environments. We still need to solve that part.

What’s next in terms of Dev Experience that has you excited?​

Ron, Yotpo: In terms of vision, I'm sticking with the developer platform. This is the biggest initiative that I'm trying to promote in my company. It’s all about having a centralized piece of infrastructure where you can go and create new services, understand knowledge bases and know where to see ownership of things. I want to keep investing in that.

And the other thing that has my interest is remote IDEs like Code Spaces and GitPod. We are interested in using one of those tools with Okteto then we have a full cloud experience when developing so you’ll never need to come back and install an IDE. You could work from an iPad if you wanted and that’s very cool to me.

Lior, monday.com: It’s also about the developer platform for us. It’s about providing developers a way of self-service for the infrastructure, where it makes sense of course. The vision is that you come to work, you open Slack, you open monday internal platform (Sphera), you run "okteto up" and that’s all you need. You can go from your CI and your monitoring tools, there are some notifications and diff detections. You can create secrets, create services, whatever else you could want in that same platform. That’s great DevEx.

• How do you ensure a minimum number of containers are always running?
• What happens when a container goes down?
• How do you update your application without any downtime?

Kubernetes solved all these and many more problems for us. But its architecture has always been an object of mystery when looked at from far. How is it managing all these containers for us? What inputs does it need from us to do this? All of this can be scary if you haven’t gotten the basics of Kubernetes right. In this article, we will focus on one of the basic objects it has to offer: Deployments.

A Bit About Pods First​

Learning about Deployments directly before knowing about Pods is like learning to read without knowing the alphabet. We won’t go into much detail about pods here, but I’ll cover enough so the rest of the article makes sense.

Pods are the most fundamental unit in the K8s world. The simplest way to understand pods without getting confused is to think of them as a wrapper for containers. Kubernetes doesn’t run containers directly. Instead, it runs Pods, where we specify which containers we want to run. Another thing to remember about pods, which we’ll get back to later, is that in the K8s world, pods are meant to be ephemeral: a single pod runs a single instance of your application, and that’s all there is to it. A running pod is only responsible for ensuring an instance of your application is running.

You can learn more about Pods via our Kubernetes Tutorial for Beginners.

Kubernetes vs Docker Deployments​

When we talk of Deployments in Kubernetes, it is very different from what we mean when we refer to deploying your application using just Docker. This is why I wanted to have a separate section to clarify the difference, so you don’t get confused.

When we talk about deploying using Docker, we usually mean the process of building container images from our Dockerfiles, pushing them to a registry, and then running our application containers.

In the world of Kubernetes, however, Deployments are an object. As per the official documentation:

A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists.

These objects are accompanied by controllers. So for the Deployment object, there is a Deployment controller. The controllers ensure that the object's current state matches the desired state we specified.

Deployments in Kubernetes​

So now we know two things: Pods are the fundamental unit in the world of K8s, and Deployments are a type of Kubernetes object. With this, we’re ready to understand the Deployment object in more detail. Let’s consider the following scenario:

You run a bunch of pods to serve your application to the users. Now let’s say there’s a sudden increase in traffic, and your pods start running out of resources. What should Kubernetes do in this case? If you recall, I mentioned that Pods only have the single function of running your application. They alone can’t bring up more pods if existing pods run out of resources.

To help manage pods, we need another Kubernetes object. And that’s where Deployments kick in. Instead of creating individual pods to serve our application, we create a Deployment object. The Deployment controller is then responsible for the management of these pods. All we have to do is create our Deployment object, and then the controller will handle the task of making sure that our specified number of pods is always running. What’s more, is that it also allows us to do other useful things like scale the number of pods, update the version of our application (without any downtime!), and even roll back to a previous app version if we discover a bug. We’ll soon see all of these in action. But let’s now learn how we can create them.

Creating a Deployment​

I'll assume you have a K8s cluster ready to work with. If you don’t, you can use the free one provided by the Okteto Platform. If this is your first time interacting with Kubernetes, I will recommend you read our Beginners’ Guide to Kubernetes before continuing with this.

Let us look at what the YAML for a typical Deployment object would look like:

# nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Looking at the spec section, you’ll notice we have a property called replicas. This refers to the number of pods we want our Deployment to run. The Deployment controller will continuously check if these many pods are up and running at any given time. If that’s not the case, it will work towards reaching this number by creating more pods or deleting existing ones.

Then under the selector, we specify the labels of the pods for the Deployment controller. This is so that it knows which pods it is supposed to manage. Let’s say in our Deployment object, we specify that we want three replicas, but two pods with the label app: nginx already exist before we create the object. In this case, the controller will only create one additional pod for us. Had we not specified any labels, then the controller wouldn’t have been able to identify that two of the needed pods were already running.

The template section is nothing but a Pod template's metadata and specification section. The metadata section lets the Deployment controller know what labels to attach to any new pods it creates, and the spec section has information about the containers which would run in the pod.

You can create this Deployment just like you would any other object by using the kubectl apply command:

kubectl apply -f nginx-deployment.yaml

After creating the Deployment, if you now look at all the objects in our K8s cluster by running:

kubectl get all

you’ll notice that we not only have the Deployment, but we also see the three pods which the Deployment created for us!

NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-877f48f6d-2zp4p   1/1     Running   0          15s
pod/nginx-deployment-877f48f6d-8tf9g   1/1     Running   0          15s
pod/nginx-deployment-877f48f6d-ptgz8   1/1     Running   0          15s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/kubernetes   ClusterIP   10.120.32.1     <none>        443/TCP     223d

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           16s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-877f48f6d   3         3         3       16s