.svg "kloia.png"){kind=logo}
The Problem
No company context
AI tools write code without knowing your codebase, your specs, your stored procedures, your standards. Generic in, generic out.
Zero audit trail
Nobody knows what changed, by whom, against which spec, at what cost. When something breaks, the log is empty.
Knowledge stays siloed
The senior engineer's head is still the source of truth. The pipeline learns nothing. That person leaves, the knowledge walks out.
Pilot never becomes default
The shiny demo works. Then adoption stalls. The new way of working never replaces the old one.
Why AIDLC?
Faster delivery
Tens of dollars per feature, hours of elapsed time. Not weeks.
Built-in compliance
Every action audited. Every dollar attributed to an issue.
Institutional memory
The pipeline learns. The org's knowledge stops walking out the door.
Faster onboarding
New engineers ramp on a pipeline that already knows the codebase.
A pipeline that improves
Each cycle's retro feeds the next cycle's configuration.
Humans stay in control
Agents propose. Humans approve. Every merge is gated.
Problems
No company context
Zero audit trail
Knowledge stays siloed
Pilot never becomes default
Why AIDLC?
Faster delivery
Built-in compliance
Institutional memory
Faster onboarding
A pipeline that improves
Humans stay in control
OpenTelemetry:
Baked in, not bolted on
Auto-instrumentation of .NET and Java services → ADOT collector sidecars on EKS → AWS X-Ray for distributed tracing → CloudWatch for metrics and logs → custom dashboards and SLO alerting. All traces, metrics, and logs flow through a single OTel pipeline, swap backends without re-instrumenting.
VM → Container replatforming
Move off bare VMs onto EKS with proper orchestration, autoscaling, and workload isolation.
Custom metrics
Business and technical KPIs exported via OTel metrics SDK to CloudWatch and Managed Prometheus.
Structured logging
JSON-structured logs with trace correlation IDs, shipped to CloudWatch Logs Insights.
SLO alerting
Composite alarms and SLO burn-rate alerts wired from day one not as an afterthought.
What changes in your architecture
AWS Landing Zone & multi-account governance
AWS Control Tower
Security baseline
Identity & access
Network architecture
FinOps & cost governance
Compliance as code
Measurable results our clients achieve
60-80%
infrastructure cost reduction vs on-prem VMs
10x
faster deployments via GitOps pipelines
99.9%+
availability through EKS self-healing & multi-AZ
<5 min
MTTR with full OTel trace-to-log correlation
Case Study
Splitting a .NET Monolith into Domain Services
60%
Performance Increase
42
Cost Reduction on EC2
Situation
Epos Now's REST API was a monolithic .NET Framework API bundled into a single repository with almost 20 projects and 1 host. Its infrastructure relied heavily on flexibility and scalability, but running on Windows instance types drove up cost, and the legacy .NET Framework structure restricted the use of modern libraries.
Task
The modernization had to address five main challenges:
- Splitting the monolith: break the .NET Framework-based monolithic application into .NET Core-based domain services, and split the code repository.
- Performance: achieve lower response times and reduced memory and CPU usage.
- Windows licensing cost: move to Linux instance types to cut the higher cost of Windows hosting.
- Lack of agility: remove the legacy dependency so up-to-date libraries built only for .NET Core could be used.
- Limited scalability: scale only the specific part of the application under load, rather than the entire application.
- Seamless modernization: keep the same interface so the Epos Now REST API could be consumed without any client-side changes.
Action
After analyzing domains and bounded contexts, the dependencies between contexts were defined and the Strangler-Fig pattern was applied to split them one by one, based on the complexity of each pattern. Traffic was diverted at the ALB layer in a path-based manner to the split domain services.
- Framework: the latest version of .NET Core was used for the .NET Framework modernization.
- Container orchestration: EKS (Kubernetes) was used to reap the benefits of container orchestration.
- Preserving the interface: nginx-ingress provided path-based routing on top of the infrastructure so existing clients kept the same interface.
- Logging: the approach was changed from push-based to pull-based (best practice for containerized environments), using the Serilog library for structured logs.
- Infrastructure: following an "everything is code" principle, the entire infrastructure was managed with Terraform.
- DevOps/DevSecOps modernization: GitLab (code repository and CI/CD), Helm, Snyk, Terraform, EKS, API Gateway, Lambda, and ALB.
By the end of the project, the domain services became independently deployable and independently scalable.
Figure 1 — Domain service architecture on EKS with API Gateway, nginx-ingress, and Auto Scaling
Results
Kloia used .NET Core and EKS to modernize Epos Now's legacy REST API into a cloud-native architecture. By converting monolithic legacy applications from .NET Framework into .NET Core and EKS, the project unlocked the agility, scalability, and cost-savings benefits of the cloud.
- Transaction
- User
- Customer
- Stock
- Product
- Management
- Setup
- Report
Figure 2 — Moving from a monolith to independently scalable domain services
Related AWS APN blog post:
How Kloia used Porting Assistant for .NET to accelerate EposNow API modernization
Case Studies
Open-Source Observability Transformation on AWS
Open-Source Observability Transformation on AWS