Drive Growth with High-Quality Solutions

What is a dev container? Development containers, or  dev containers, are a way to package the entire development environment (tools, dependencies, and configuration) into a containerized format. What this gives us is a way to have code that you are working on behave the same no matter where you run it, no matter if it is your local machine, someone else’s, or in the private or public cloud. They rely on the Development Container Specification, which is a way to provide containers with more content and metadata needed to enable development inside of them. It is a way to define a repeatable development environment that includes the execution environment that the application needs. For this, the devcontainer.json file serves as the central configuration file in the project repository. Now, how can a dev container be created and configured from that? Well, that is done through the development container CLI. This is actually used by tools like code editors when they detect a devcontainer.json file, but it can also be used by individual users. So no need for some tool, as this can be installed via “npm install -g @devcontainers/cli” This means that it is tool-agnostic, and no matter if you are using some IDE or your terminal, the same devcontainer.json file will be used to produce the same development environment for a dev container. How to set up dev container Prerequisites For starters, there are some prerequisites you need before setting up the dev container itself. And those are: Container runtime – This is needed to create and manage your containers. Docker is the most commonly used and best documented runtime. On Mac and Windows, you would use Docker Desktop (with the WSL2 backend required on Windows) and Docker Engine for Linux. Integrated Development Environment (IDE) – While not obligatory, it is easier to use them, and not all IDEs support dev containers, so you will need one that supports it. Two of the most popular ones are VS Code (with the Dev Containers extension) and JetBrains IDEs. The setup Now, after all of that is installed and set up, let’s start with the setup of the development container itself. The first thing you would need to add is the .devcontainer folder that will be located in the root of your repo. Then, inside, you will add a devcontainer.json file, which acts as a config file used to build and run the container. Example of devcontainer.json file: { “name”: “Python Project”, “image”: “mcr.microsoft.com/devcontainers/python:3.14.7”, “features”: { “ghcr.io/devcontainers/features/docker-in-docker:4.1.0”: {} }, “customizations”: { “vscode”: { “settings”: { “python.defaultInterpreterPath”: “/usr/local/bin/python” }, “extensions”: [ “ms-python.python”, “ms-python.vscode-pylance”, “ms-python.pylint” ] } }, “forwardPorts”: [8000], “portsAttributes”: { “8000”: { “label”: “Flask app”, “onAutoForward”: “notify” } }, “postCreateCommand”: “pip install -e .”, “remoteUser”: “vscode”} Let’s break down what this configuration includes: name – is a human-readable label for your dev container, which is shown in your IDE. image – the name of an image in a container registry that supporting services/tools should use to create the dev container. features – tools to be added to the primary container. In this example, Docker-in-Docker will allow Docker commands to be run from within the dev container itself. This is useful when your development depends on running Docker commands for different purposes like building and testing images as part of the project, or running tests, for example. customizations – these are config for tools and are scoped by IDEs. forwardPorts – an array of port numbers that should be forwarded from the primary container to the local machine. portsAttributes – this property allows you to set default properties for specific forwarded ports. postCreateCommand – A command string or list of command arguments to run after the container is created. remoteUser – defines the user that supporting services and tools, defined in devcontainer.json, run as in the container It is worth noting that an image is one of the options for configuring dev containers, but for that, we have two other options, and those are: build – instead of pulling a pre-build image, with build.dockerfile you can point to the local Dockerfile, with the path relative to the devcontainer.json. With this, you can fully customize container setup if you need specific packages or custom installation steps, as well as a base image that is not publicly available. dockerComposeFile – references docker-compose.yaml file, which allows you to define and run multiple services together, like for example, your app and database. Lifecycle hooks Now, besides the already mentioned postCreateCommand command, let’s mention other lifecycle hooks available, with an explanation of at which point in the container’s life they are run: HookTime of executioninitializeCommandRuns on the host machine during initialisation, and on container creation on subsequent starts.onCreateCommandRuns first when the dev container is created and executes inside the container.updateContentCommandRuns after onCreateCommand whenever new content is available in the source tree during the creation process.postCreateCommandThe third and last command that finalises container setup, it runs once the dev container has been assigned to a user for the first time.postStartCommandRuns each time the container is successfully started.postAttachCommandRuns each time a tool has successfully attached to the container. When and why to use it Are dev containers perfect for every project? Not quite. So let’s see when to use them. If you have a setup that matches the following scenarios, you could improve your development experience by adopting them and utilizing the advantages that they offer. These are some of the cases where you would want to use them: CI/CD parity – an underrated benefit of dev containers is the ability to closely mirror, or even reuse, the same container image used in your CI/CD pipeline. With the usage of tools like devcontainers/ci you can run existing devcontainer.json or Dockerfile setup inside of CI providers. This gives you better assurance that if something runs successfully on your local machine that it will work the same in the CI. This eliminates the potential drift between local and CI that can come over time. Enforcing team-wide tooling – this is especially useful for bigger teams, and when you want to standardize the development environment, since the container is pre-configured with needed tools, dependencies, and so on. This allows programmers to focus less on setup and more on coding. In this case, you are also potentially reducing “works on my machine” situations.An alternative for this could be having documentation-based onboarding, where you would have detailed README with instructions, or setup script to run, though this still requires a developer to follow certain steps to make it work correctly. The multi-project version conflict – in cases where you have multiple projects, and let’s say project A needs Python 3.9 and project B needs Python 3.12 version, in that case it can become a problem to maintain versions, and system paths could eventually break. Dev containers solve this by isolating these runtimes by project directory and keeping the host machine clean.For comparison, you could maybe try to solve this with the use of a lock-based package manager (uv.lock, package-lock.json, for ex.), and though they do handle dependency isolation, dev containers go further by also isolating system-level tools and OS packages. Fast onboarding – for expanding teams, fast onboarding is key, and with the use of dev containers, this becomes much quicker and more efficient, as it doesn’t require a manual installation of specific versions of languages, dependencies, and extensions.Again, teams try to solve this with onboarding documentation to explain what is needed to start working on your project, which requires a new developer to manually set up the needed things, and can take significant time to make it all work. When and why NOT to use it Now that the use cases for when to use it have been covered, even though dev containers have powerful capabilities, let’s see when it is not a good approach. Cases to rethink their usage: Lightweight and solo projects – if you are building a simple website or a project, and especially if it is a solo project, in that case, the overhead of the setup might not be valuable to what it offers you.  Configuration management – besides the initial configuration setup, it later becomes something extra that the team needs to manage. And with project growth, the configuration will probably change as well. Secrets and credential management – some secret management tools rely on host-level interaction or browser-based authentication flows, which aren’t easily accessible from isolated containers, it can get tricky to make this work and can require some additional workarounds. In cases like this, teams often just run certain tools or scripts outside the container to authenticate or access secrets. Usage of Git – actions like git push that need a commit signature can run into friction when running from inside a container. This is because verified commits often rely on SSH and GPG signing, which require access to certain resources on the host machine, such as private keys and cryptographic tools. Resource-intensive – this comes up especially when you are running multiple containers at the same time, which may require better hardware. This is noticeable on Macs, as Docker runs inside a VM rather than natively. As a workaround, Windows runs the Linux kernel directly. Loss of unsaved state on rebuild – dev containers are frequently rebuilt, and every time this happens, everything that existed just inside of a container is wiped out. Then it needs to be recreated from scratch, and those are things like manually installed packages, shell history, or cached build artifacts, to name a few. Dev containers and AI sandboxing As artificial intelligence becomes more widely used, especially vibe-coding, it is reaching a point where isolating code agents is increasingly important. The problem with running an AI agent on a local machine is that it acts like you and has your privileges, and in some cases it can take unwanted actions after it starts “hallucinating”. That is now becoming a security concern that needs to be handled. This is where dev containers come into play. With them, you create a fully isolated environment for your AI agent to run in, with your host protected as it can’t touch your home directory. Dev containers give you control over customization by writing your own Dockerfile to set up the development environment per your needs. The concern with AI agents is that they have access to the host filesystem, which, with this, can be configured so that it only has access to projects it’s working on. Setting up AI agents in devcontainers is quite simple. For example, for Claude Code, as per their official guidance, you just need to add this to the features property: “features”: { “ghcr.io/anthropics/devcontainer-features/claude-code:1.0.5”: {}}, After adding this, you rebuild the container, sign in to Claude Code inside it, and every command you run stays in that isolated environment, while edits show up in your local repository as your work. Today, this is probably the safest path you can take to minimize the harm that agents can do. Though nothing is completely safe, it is best to still watch out for anything that is suspicious. Conclusion To conclude, dev containers are useful in modern development, as they boost productivity. They ensure a consistent development environment without the need to install any tools manually, besides the prerequisites. Using this approach means some setup complexity at the beginning, but it allows for quick, easy onboarding for new team members while maintaining consistency and portability. That said, dev containers are not a one-size-fits-all solution. As covered in one of the previous sections, there are some cases where they introduce their own overhead. This can introduce more friction then it helps out with the project, especially for smaller or solo projects.  If used in the right setting, dev containers can be powerful and helpful, so make sure you weigh your needs before committing to one.

Introduction Kubernetes is not just a container orchestration platform. It is a platform that can be extended with custom APIs. In this blog, the following topics will be covered: what the Kubernetes API is and how it can be extended using a Custom Resource Definition (CRD for short), what a Kubernetes operator is and how it can be implemented, a practical example of extending the Kubernetes API using a CRD, a practical example of implementing an operator that manages objects of the new CRD. As part of the hands-on example, a Website CRD and an operator will be implemented. Based on Website objects, the operator will automatically create a Deployment, Service, and Ingress. Kubernetes API Kubernetes is an API-driven platform, meaning all resources in the cluster are managed through the Kubernetes API server. Creating Kubernetes resources (e.g., Deployment, Service, Ingress, etc.) is done by sending a request to the Kubernetes API server, which: validates the object stores it in etcd and makes it available to other Kubernetes components It is important to understand that the API server does not execute changes directly. It only stores the desired state, while background controllers reconcile and try to align the system’s current state with it. This model makes Kubernetes a declarative system so the user defines what they want, and Kubernetes tries to achieve it. How CRDs Extend the Kubernetes API Although Kubernetes comes with a large number of predefined resources, there is often a need to create custom types of objects, like: Database KafkaCluster BackupPolicy Website A CRD allows you to create new types of resources without modifying the Kubernetes source code. After creating a CRD, the new resource becomes part of the Kubernetes API and can be used through: kubectl YAML manifests API calls just like standard Kubernetes resources. CRDs therefore, turn Kubernetes into an extensible platform capable of managing resources from any domain. It is important to understand the difference between a CRD, which defines only the schema of a new Kubernetes resource, and a Custom Resource (CR for short), which represents an instance (an object) of that CRD. Kubernetes Operator and reconciliation loop A Kubernetes operator is a controller that, by observing a CRD and its instances, implements defined logic and automatically brings the system into the desired state. Its main responsibility is the reconciliation loop, which continuously compares the desired state defined in the custom resource with the actual state of the system. If there is a difference between the desired and actual state, the operator performs the necessary actions. In the hands-on example, it will be shown how the operator creates the required objects based on a Website resource, and it is going to be: Deployment Service Ingress In addition to being event-driven, meaning it reacts to events related to the resources it watches, an operator is also state-based, meaning that every time it reacts, it tries to bring the system into the desired state. Lifecycle from CRD to Managed Resource The lifecycle of an operator can be described through the following steps: CRD registration The Kubernetes API is extended with a new resource type. Creating a custom resource The user defines the desired state through a YAML manifest. Validation and storage The API server validates the resource based on the CRD schema and stores it in etcd. Change detection The operator receives an event through the watch mechanism. Reconciliation loop The operator compares the desired state with the current state of the system. Creating or updating resources Required resources are created or updated, and they can be inside or outside the cluster. Status update The operator updates the observed state in the CR status section. This process runs continuously throughout the entire lifecycle of the resource. OwnerReferences and Finalizers Operators not only manage resource creation, but also their lifecycle. OwnerReferences OwnerReferences define the relationship between the parent CR (e.g., Website) and child (Deployment, Service, Ingress …) resources. If an operator creates a Deployment, Service, or Ingress and links them to a Website resource, the Kubernetes garbage collector will automatically delete the child resources when the parent is deleted (cascading deletion). However, if a child resource is deleted first, the operator will recreate it during the reconciliation loop, as it always aims to restore the systemto the desired state defined in the Website resource. How it looks in the child resource definition: ownerReferences: – apiVersion: website.demo.atlantbh.com/v1 blockOwnerDeletion: true controller: true kind: Website name: abh-demo-website uid: 9be6fcb1-cf19-40ce-bfed-8f7c13c23057 Finalizers Finalizers allow additional cleanup logic before a resource is permanently deleted. When a resource contains a finalizer: Kubernetes sets the deletionTimestamp the resource remains in the cluster the operator performs cleanup logic Typical examples include: deleting cloud resources DNS cleanup backing up data before deletion Only after the cleanup is complete does the operator remove the finalizer, and Kubernetes permanently deletes the resource. A finalizer can be seen as a blocker during deletion, meaning the resource cannot be deleted until all finalizers are removed, i.e., until the entire cleanup process is finished.nalizer can be seen as a blocker during deletion, meaning the resource cannot be deleted until all finalizers are removed, i.e., until the entire cleanup process is finished. Implementation Using Kubebuilder For implementing a Kubernetes operator, one framework to consider  is Kubebuilder, which is built on top of the controller-runtime library. Kubebuilder provides: generation of CRD and RBAC manifest files controller skeleton controller-runtime integration standardized project structure for operators This keeps the focus on business logic rather than boilerplate code.  The complete source code of the hands-on example of the blog is available in the GitHub repository. Hands-on Example: Website CRD A simple example demonstrates the implementation of a Kubernetes operator and CRD. The complete CRD is available at the following location.Based on the previously defined CRD, the user defines a custom resource through a YAML file: apiVersion: website.demo.atlantbh.com/v1kind: Websitemetadata: name: abh-demo-websitespec: image: nginx:latest replicas: 3 port: 80 env: – name: ENV value: “production” resources: requests: cpu: “100m” memory: “128Mi” limits: cpu: “500m” memory: “256Mi” What Does the Operator Do? After this custom resource is created, the operator runs a reconcile loop: creates a Deployment (image, replicas, env, resources) creates a Service (exposes the port) creates an Ingress (exposing the application) Then, through the reconciliation loop, it ensures: the number of pods matches replicas the resources are available routing is functioning correctly CRD Validation CRDs use OpenAPI v3 schema validation. In this example: image is a required field – repository replicas must be between 0 and 100 – repository port must be between 1 and 65535 – repository In this way, invalid resources are rejected by the Kubernetes API before they ever reach the operator. Conclusion Custom Resource Definitions enable extending the Kubernetes API and creating custom resource types within a cluster.  When combined with the operator pattern, Kubernetes becomes a platform for automating complex systems, not just container orchestration. Kubebuilder significantly simplifies operator development, allowing developers to focus on business logic rather than infrastructure boilerplate code. This example demonstrates how a simple Website resource can become a declarative interface for automatically managing a web application.

gRPC: a high-performance Remote Procedure Call (RPC) framework, initially developed by Google and later released as an open source project. It was designed specifically to handle fast, platform-independent communication between services, making it crucial for both backend architectures and mobile clients. It lets your services communicate as if they were just calling local functions. Its speed and efficiency come down to three main components: Protocol Buffers (Protobuf) This is both the Interface Definition Language (IDL) and the binary message format. Instead of loose JSON payloads, gRPC requires a strict contract defined in .proto files. Because Protobuf messages are compiled into binary, they are 50-85% smaller and 3–10x faster to parse than text-based formats (Source: Zuplo, “Protobuf vs JSON: Choosing the Right API Serialization Format,” May 2026). HTTP/2 Transport Unlike REST APIs relying on HTTP/1.1, gRPC takes advantage of HTTP/2. This unlocks advanced network features like multiplexing (sending multiple requests over a single connection), header compression, and bi-directional streaming – all of which reduce latency. Automated Code Generation You write the .proto file, and the protoc compiler handles the rest, generating client stubs and server skeletons in almost any language. When a client makes a call, the stub automatically encodes the request into binary and fires it over HTTP/2. The server receives it, decodes it, runs the method, and sends it back. No manual serialization required. gRPC vs. REST Choosing between the two frameworks usually comes down to a few fundamental differences in how they handle data and the network FeatureRESTgRPCProtocolHTTP/1.1 (usually)HTTP/2PayloadJSON (Text-based)Protobuf (Binary)ContractOptional (OpenAPI/Swagger)Strict (.proto files)StreamingRequest-Response (No native streaming)Unary, Server, Client, & Bi-directional Who is Using It? Major tech companies lean on gRPC for their most critical, high-throughput operations. Some known examples of gRPC usage are: Uber: Relies on gRPC for its real-time push platform and its GitFarm service, which provides a unified, high-speed Git checkout system for monorepos (Sources: “Uber’s Next Gen Push Platform on gRPC,” Aug 2022 & “GitFarm: Git as a Service for Large-Scale Monorepos,” July 2026), both of which need high reliability and low latency. Netflix: Netflix’s GraphQL DGS layer calls downstream gRPC microservices (like Recommendations and Watch-History) for internal speed, while GraphQL fronts the external API, as illustrated in their architecture below:  gRPC vs. REST Choosing between the two frameworks usually comes down to a few fundamental differences in how they handle data and the network FeatureRESTgRPCProtocolHTTP/1.1 (usually)HTTP/2PayloadJSON (Text-based)Protobuf (Binary)ContractOptional (OpenAPI/Swagger)Strict (.proto files)StreamingRequest-Response (No native streaming)Unary, Server, Client, & Bi-directional Who is Using It? Major tech companies lean on gRPC for their most critical, high-throughput operations. Some known examples of gRPC usage are: Uber: Relies on gRPC for its real-time push platform and its GitFarm service, which provides a unified, high-speed Git checkout system for monorepos (Sources: “Uber’s Next Gen Push Platform on gRPC,” Aug 2022 & “GitFarm: Git as a Service for Large-Scale Monorepos,” July 2026), both of which need high reliability and low latency. Netflix: Netflix’s GraphQL DGS layer calls downstream gRPC microservices (like Recommendations and Watch-History) for internal speed, while GraphQL fronts the external API, as illustrated in their architecture below: Google: Beyond using gRPC to power its own global services, Google Cloud is currently contributing a gRPC transport package for the Model Context Protocol (MCP). This bridges a gap for companies that already run gRPC-heavy infrastructures and want to plug AI agents into their microservices without falling back to JSON-RPC over HTTP. Practical Example: Product Service Let’s look at a practical example. Imagine an e-commerce platform where a Node.js frontend needs to fetch inventory data from a Java backend. We’ll define a Product Service that allows a Java (Spring) server to provide product details, while a TypeScript client consumes them with end-to-end type safety. The Contract (ProductService.proto) syntax = “proto3”;option java_multiple_files = true;package com.techbite.inventory;service ProductService { // Returns product details based on an ID rpc GetProductById (ProductRequest) returns (ProductResponse); rpc SearchProducts (stream ProductRequest) returns (stream ProductResponse);}message ProductRequest { string id = 1;}message ProductResponse { string id = 1; string name = 2; int32 price_cents = 3; int32 quantity = 4; repeated string categories = 5; // List of strings} The Java Server Implementation Note: The @GrpcService annotation below is typically provided by the grpc-spring-boot-starter dependency (e.g., net.devh.boot.grpc.server.service.GrpcService). Base classes are not in your repository right away, they are generated when you compile the project. Running a build command such as mvn compile or ./gradlew build triggers the protoc compiler, which generates the ProductServiceGrpc class and its inner ProductServiceImplBase stub. From there, your actual service class just: Extends that generated base Overrides the contract methods Uses a StreamObserver to stream responses back to the client @GrpcServicepublic class ProductServiceImpl extends ProductServiceGrpc.ProductServiceImplBase { @Override public void getProductById( ProductRequest request, StreamObserver<ProductResponse> responseObserver ) { // Mocking a database lookup ProductResponse response = ProductResponse.newBuilder() .setId(request.getId()) .setName(“Mechanical Keyboard”) .setPriceCents(99999) .setQuantity(2) .addCategories(“Components”) .addCategories(“Peripherals”) .build(); responseObserver.onNext(response); responseObserver.onCompleted(); } @Override public StreamObserver<ProductRequest> searchProducts( StreamObserver<ProductResponse> responseObserver ) { return new StreamObserver<ProductRequest>() { @Override public void onNext(ProductRequest request) { // Process incoming request stream and send back responses ProductResponse response = ProductResponse.newBuilder() .setId(request.getId()) .setName(“Mechanical Keyboard”) .setPriceCents(99999) .setQuantity(2) .addCategories(“Components”) .addCategories(“Peripherals”) .build(); responseObserver.onNext(response); } @Override public void onError(Throwable t) {} @Override public void onCompleted() { responseObserver.onCompleted(); } }; }} The TypeScript Client Just like on the server, these TypeScript definitions aren’t committed to your repository out of the box. Instead, you manage them through your frontend build pipeline by running a custom script like npm run compile-protos, which uses a tool called proto-loader-gen-types to compile the .proto file into type stubs. If the API contract ever changes, you simply rerun this script to instantly overwrite and regenerate the definitions, keeping your end-to-end type safety intact. import * as grpc from ‘@grpc/grpc-js’; import * as protoLoader from ‘@grpc/proto-loader’; import { ProductServiceClient } from ‘./types/com/techbite/inventory/ProductService’; import { ProductRequest } from ‘./types/com/techbite/inventory/ProductRequest’; import { ProductResponse } from ‘./types/com/techbite/inventory/ProductResponse’; const packageDef = protoLoader.loadSync(‘./proto/product.proto’); const proto = (grpc.loadPackageDefinition(packageDef) as any).com.techbite.inventory; const client = new proto.ProductService( ‘localhost:9090’, grpc.credentials.createInsecure() ) as ProductServiceClient; const request: ProductRequest = { id: ‘7b32a1e4-5f91-4c20-8d3b-92e7411fb2d6’ }; client.getProductById( request, (err: grpc.ServiceError | null, product?: ProductResponse) => { if (err) { console.error(`RPC Error (${err.code}): ${err.message}`); return; } if (product) { console.log(`Retrieved: ${product.name} ($${(product.priceCents / 100).toFixed(2)})`); console.log( `Stock: ${product.quantity} | Tags: ${product.categories?.join(‘, ‘)}` ); } }); const stream = client.searchProducts(); // 1. Listen for incoming responses from the server stream.on(‘data’, (response: ProductResponse) => { console.log(`[Stream] Received: ${response.name} ($${(response.priceCents / 100).toFixed(2)})`); }); stream.on(‘error’, (err: grpc.ServiceError) => { console.error(`[Stream] Error: ${err.message}`); }); stream.on(‘end’, () => { console.log(‘[Stream] Server closed the stream.’); }); // 2. Push multiple requests to the server over the same connection stream.write({ id: ‘12345-a’ }); stream.write({ id: ‘67890-b’ }); // 3. Tell the server we are done sending requests stream.end(); The Drawbacks Browser Support: Browsers do not provide the level of control over HTTP/2 that gRPC requires. To make it work in a web app, you usually have to rely on proxies like gRPC-Web, which adds architectural complexity. Not Human-Readable: Unlike JSON, which you can easily inspect in a browser console or Postman, Protobufs are binary. If you don’t have the .proto file to decode the message, you can’t read the payload. Steeper Learning Curve: Compared to a REST API, gRPC requires more upfront work. You have to actively manage your .proto files across multiple services and configure the right tools for code generation in your build pipeline. Missing Semantic Layer for AI: While gRPC’s server reflection tells you the structure of the data (method names, parameters), it lacks the natural-language descriptions that AI agents and LLMs need to understand why or when to use a service. This creates friction with AI-first protocols like MCP. So, REST or gRPC? While the drawbacks are worth considering, the performance and type-safety benefits of gRPC make it an excellent tool. Instead of trying to replace REST entirely, you’ll generally want to reach for gRPC in a few specific scenarios: For internal service-to-service communication where high throughput is critical, gRPC is practically unmatched. This is especially true if you’re dealing with polyglot environments, those strict .proto contracts guarantee that your Java backend, Node.js service, and Go microservices are speaking the exact same language without runtime surprises. Need real-time, bi-directional streaming? gRPC over HTTP/2 handles this natively (and much more elegantly than WebSockets or long-polling). But REST and GraphQL aren’t going anywhere. Standard HTTP is also way easier for browser-to-server calls, unless you actually want the headache of maintaining gRPC-Web proxies. Ultimately, if you’re just building a basic CRUD app to push JSON around, gRPC is complete overkill.