Teams outgrowing one server
An application that needs more instances at peak and fewer at night, without a rewrite.
Cloud native development
Cloud native development services
Putting an application in a container is easy. Running it well on a platform your team can afford to operate is harder. Agnotic Technologies builds and moves applications onto containers and Kubernetes, choosing the platform from your workload, then adding image security, GitOps releases and telemetry your team can read.
Twelve-factor readinessPlatform choiceSigned imagesGitOps and OpenTelemetry
Trusted by global innovators
Cloud native
What are cloud native development services?
Cloud native development services build or rework applications to run as containers on a managed platform such as Kubernetes. Agnotic Technologies checks twelve-factor readiness, chooses between managed Kubernetes and simpler container services, secures image builds, sets up GitOps releases and wires OpenTelemetry so each service can scale, recover and be observed on its own.
Cloud native is not the same as microservices. One well-built service in a container is cloud native; whether to split it is a separate decision with its own page.
Functions and event-driven designs sit under serverless development. This page is about containers as the runtime.
Who moves to cloud native, and why?
The trigger is rarely fashion. It is usually one of these.
SaaS products adding regions
The same images deployed to clusters in several regions from one Git repository.
Companies leaving hand-built virtual machines
Servers configured by hand replaced by images built in a pipeline, so every environment runs the same thing.
Startups planning for scale
Cloud native development services for startups often mean one managed container service now, with a clear path to Kubernetes later.
Regulated workloads
Restricted pod settings, signed images and audit logs that shorten security reviews.
Readiness check
Is your application ready for containers?
We run this twelve-factor check before writing a Dockerfile. Every gap becomes a task in the plan.
- Configuration comes from environment variables or a secrets store, not from files baked into the build
- The application keeps no session or upload state on local disk
- Logs go to standard output as structured events, not to log files
- Databases, queues and caches are attached by URL and can change per environment
- The process starts quickly and shuts down cleanly on a termination signal
- Dependencies are declared and pinned, so the image builds the same way every time
- Admin jobs such as migrations run as one-off tasks, not inside the web process
- Health and readiness endpoints tell the platform when to send traffic and when to restart
Decision table
Managed Kubernetes, a container service or serverless?
We choose the platform from the workload, then write down the operating work it leaves to your team.
| Workload trait | Managed Kubernetes (Amazon EKS, AKS, GKE) | Managed container service (Amazon ECS, Azure Container Apps, Cloud Run) | Serverless functions |
|---|---|---|---|
| Team size and platform skills | Needs people who will own cluster upgrades, add-ons and policies | Fits a small team that wants containers without running a cluster | Fits a small team with event-driven code |
| Number of services | Many services sharing networking, policies and tooling | A modest number of services with simple networking | Many small functions, which get harder to trace as they grow |
| Stateful parts | Possible with StatefulSets and operators, though managed databases are usually the better home | Keep state in managed databases and storage | Keep state in managed databases and storage |
| Burst traffic | Pod and node autoscaling, with node capacity to plan | Scales with requests; some of these services can scale to zero | Scales per request; watch concurrency limits and cold starts |
| Compliance scope | Fine-grained network and pod policies, with more to configure and evidence | Fewer controls to configure and evidence | The smallest surface, with the provider running most of it |
| Operating work left to you | Version upgrades, node pools, add-ons, policies and cost | Service definitions, scaling rules and images | Function code, permissions and limits |
Comparing the cloud providers is a separate question. Here the provider is usually chosen already, and the decision is how much platform to run on it.
Migration path
How do we move an application onto containers?
Small, reversible steps, with the old deployment kept until the new one has carried real traffic.
Fix the readiness gaps
Configuration, logging, state and shutdown changes from the checklist, shipped to the current hosting first.
Write the image build
A multi-stage Dockerfile on a minimal base image, running as a non-root user and built in CI with pinned dependencies.
Scan and sign
Every image is scanned for known vulnerabilities, signed and given a software bill of materials before it reaches the registry.
Define the platform as code
The cluster or service, networking, secrets and policies in infrastructure code, reviewed like application code.
Release through GitOps
A Git repository holds the desired state and an agent in the cluster applies it, so every change has a commit and a rollback.
Shift traffic and retire
Move a share of traffic, watch the telemetry, move the rest, then switch off the old servers.
Container security
Which controls secure each layer of a container platform?
We design against NIST SP 800-190 and the CIS Kubernetes Benchmark and enforce the Kubernetes Pod Security Standards. These are the controls we set at each layer.
01
Images
Example: A base image carries an outdated system library nobody noticed
Approach: Minimal base images, rebuilt on a schedule, scanned in CI and blocked when findings pass the agreed severity.
02
Registry
Example: Anyone with push rights can overwrite a tag that production uses
Approach: Immutable tags, deploys by digest and push rights limited to the pipeline identity.
03
Orchestrator
Example: A default service account can read secrets in other namespaces
Approach: Namespaces per team or tenant, least-privilege Kubernetes RBAC and admission policies that reject unsigned images.
04
Running containers
Example: A pod runs as root with a writable filesystem
Approach: The Restricted Pod Security Standard where workloads allow it: non-root users, a read-only root filesystem and dropped capabilities.
05
Hosts and nodes
Example: Nodes patched by hand on different schedules
Approach: Managed node groups or container-optimized node images, replaced rather than patched in place.
What do we set up for running in production?
The parts that decide whether the platform is still easy to run a year after launch.
GitOps release flow
Desired state in Git, applied by an in-cluster agent, with drift detection and rollback by reverting a commit.
OpenTelemetry instrumentation
Traces, metrics and logs from each service through the OpenTelemetry Collector to the backend you choose, with trace IDs in every log line.
Secrets from a managed store
Secrets read at run time from AWS Secrets Manager, Azure Key Vault or Google Secret Manager, never stored in images or Git.
Autoscaling rules
Pod and node autoscaling, or service scaling rules, tuned from load tests rather than left at defaults.
Network policies
Default-deny traffic between namespaces, opened only for the calls each service makes.
Cost visibility
Resource requests and limits sized from real usage, with labels that show cost per team or service.
Facts and sources
Facts behind cloud native design
Definitions and controls from the CNCF, the Kubernetes project, NIST and OpenTelemetry that shape the platform work on this page.
The CNCF Cloud Native Definition v1.1, approved in February 2024, says cloud native architectures typically combine containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless and declarative APIs.
Source: CNCF Technical Oversight Committee: Cloud Native Definition v1.1The Kubernetes documentation describes Kubernetes as a portable, extensible, open source platform for managing containerized workloads and services that supports both declarative configuration and automation.
Source: Kubernetes documentation: overviewThe Kubernetes Pod Security Standards define three cumulative policies, Privileged, Baseline and Restricted, that range from highly permissive to highly restrictive.
Source: Kubernetes documentation: Pod Security StandardsNIST SP 800-190, the Application Container Security Guide, explains the security concerns that come with using containers and gives recommendations for addressing them.
Source: NIST SP 800-190OpenTelemetry is an open source, vendor and tool agnostic framework for generating, collecting and exporting traces, metrics and logs, and it is not an observability backend itself.
Source: OpenTelemetry documentation: what is OpenTelemetry
References
Which standards guide our container platforms?
The specifications and baselines behind the platform choices above.
NIST SP 800-190CIS Kubernetes BenchmarkPod Security StandardsCNCF Cloud Native DefinitionOpenTelemetryOCI image specification
Scope and cost
What drives the cost of cloud native development?
We do not publish prices. These are the factors we size on the scoping call.
Readiness gaps
State on disk, file-based configuration and slow startup must be fixed before containers help.
Number of services
Each service needs an image, a deployment definition, scaling rules and telemetry.
Platform choice
Managed Kubernetes takes more setup and upkeep than a managed container service.
Security and compliance scope
Signed images, admission policies and audit evidence add design and test work.
Environments and regions
More clusters or regions mean more GitOps targets and more failover tests.
Team hand-over
Runbooks, training and on-call support after go-live, if your team will run the platform.
Frequently Asked Questions
It depends on how many services there are and how many gaps the readiness check finds. We agree the first service to move, and the platform it lands on, on the scoping call.
No. A managed container service such as Amazon ECS, Azure Container Apps or Cloud Run gives you containers, autoscaling and rolling deploys without running a cluster. Kubernetes pays off when you have many services and people to own the platform.
Yes. Containers keep calling your databases, queues and third-party APIs through configured endpoints, and we route traffic between the old servers and the new containers during the move.
GitOps keeps the desired state of each environment in a Git repository that an agent applies to the cluster. Every change is a reviewed commit, drift is detected, and rolling back means reverting a commit.
Often, if you start small. One managed container service with a pipeline and telemetry is enough for most early products, and the same images can move to Kubernetes later.
Yes. A common first phase is one service containerized, signed, released through GitOps and instrumented with OpenTelemetry. That service then becomes the template for the rest.
AI tools may draft Dockerfiles, manifests or tests, but each change is reviewed by an engineer, scanned in the pipeline and deployed to a test environment before production.