Posts Tagged ‘EKS’
[AWSReInvent2025] From Legacy EC2 to Modern EKS: The Tipalti Transformation to Windows Containers
Lecturer
Aiden is a Senior Solutions Architect at AWS, focusing on the modernization of Windows workloads and high-availability container strategies. He has extensive experience helping fintech enterprises transition away from legacy virtualization models. Maya Morv Freeman is an AWS Technical Account Manager who serves as a primary advisor to Tipalti on cloud governance and architectural excellence. Denny Teller is the Lead DevOps Architect at Tipalti, where he oversees the global infrastructure for the company’s payment automation platform. Denny is a pioneer in implementing GitOps and containerization for complex, regulated Windows environments.
Abstract
For many growing enterprises, legacy Windows applications are “constrained” by the scaling limitations and high operational overhead associated with traditional virtual machines. This article examines Tipalti’s successful migration from a monolithic Amazon EC2-based architecture to a highly scalable, containerized solution on Amazon Elastic Kubernetes Service (EKS). The methodology focuses on the implementation of Windows Containers, which allowed Tipalti to achieve a 50% performance improvement while enabling the adoption of advanced auto-scaling and GitOps workflows. The analysis explores the technical challenges of managing process-heavy Windows workloads, the integration of custom logging and monitoring solutions, and the shift toward an immutable infrastructure model. This transformation has provided Tipalti with a resilient foundation for continuous modernization in the competitive fintech market.
The Evolution of Compute: Overcoming the Limitations of Virtualization
The history of enterprise Windows computing has long been defined by an inefficient “one app per server” model, which often led to significant hardware waste and high management costs. While the introduction of hypervisors and virtual machines improved hardware utilization, these systems still carried the heavy overhead of running multiple full operating system instances for every application. Tipalti recognized that to support their rapid global expansion, they needed to move beyond the constraints of traditional Amazon EC2 instances.
The transition to Windows Containers represents the next critical phase in this evolution. Unlike virtual machines, containers share the host’s kernel, which drastically reduces the resource footprint and allows for much higher density on underlying hardware. This efficiency is paired with improved portability, ensuring that the application environment remains identical from a developer’s local machine to the production EKS cluster. For a fintech company like Tipalti, the most vital benefit of this shift is agility; containers can be spun up or down in seconds, allowing the infrastructure to respond instantly to the volatile traffic patterns inherent in global payment processing.
Methodology: Modernizing the Fintech Infrastructure
Tipalti’s transformation followed a rigorous technical roadmap that sought to move their infrastructure from a “legacy” state of manual server management to a “modern” state of automated orchestration. A central component of this strategy was the use of Amazon EKS for Windows, which allowed the team to manage both Linux and Windows workloads through a unified Kubernetes control plane. This eliminated the need for separate management tools and simplified the overall operational landscape.
The implementation methodology addressed several specific Windows-related challenges. Because many of Tipalti’s legacy applications were not originally designed for the ephemeral nature of containers, the team had to implement sophisticated process management techniques. Furthermore, the adoption of GitOps workflows ensured that the entire infrastructure could be managed as code. In this model, every change to the environment is tracked in a version control system and automatically deployed to the cluster, providing a clear audit trail and reducing the risk of human error. To ensure complete visibility, the team also developed custom logging and monitoring solutions tailored to the telemetry requirements of Windows containers, ensuring that the DevOps team could maintain high availability even during rapid deployment cycles.
Technical Analysis of Performance and Scalability Gains
The move to a containerized EKS environment delivered immediate and measurable technical advantages for Tipalti. One of the most significant outcomes was a documented 50% performance improvement for core payment processing services. This gain was achieved through more efficient resource allocation and the ability to leverage Kubernetes’ native auto-scaling capabilities, which ensure that compute power is always perfectly matched to the current workload.
Operational simplicity also improved as the team moved away from the administrative burden of patching and maintaining hundreds of individual EC2 instances. By using container images, Tipalti shifted toward an immutable infrastructure model, where updates are performed by replacing containers rather than modifying them in place. This has resulted in better “bin-packing,” where more applications are packed onto fewer EC2 nodes, leading to substantial cost savings without compromising on throughput or reliability. A technical hurdle overcome during this process involved managing legacy Windows behaviors that expected persistent file systems; this was resolved by integrating modern Container Storage Interface (CSI) drivers that provide persistent storage to ephemeral containers.
Consequences: Establishing a Foundation for Continuous Innovation
For Tipalti, the successful implementation of Windows containers was not viewed as a final destination but rather as the essential foundation for continuous modernization. By adopting Kubernetes, the organization has unlocked several strategic advantages. They are now able to implement the most modern DevOps practices and tools, which are natively designed for containerized ecosystems. This has significantly accelerated their release cycles and improved the overall quality of their software.
Furthermore, the new infrastructure is inherently more resilient. The automated health checks and self-healing properties of Amazon EKS ensure that the global payment system remains available 24/7, even in the event of hardware failure. Most importantly, the platform is now “future-ready.” Having a containerized environment makes it far easier to integrate advanced cloud-native services, such as AI-driven fraud detection or serverless functions, which would have been prohibitively difficult to implement in the previous VM-based architecture. Tipalti’s journey demonstrates that modernizing the compute layer is the primary enabler for broader business innovation.
Conclusion
The journey of Tipalti from Amazon EC2 to Amazon EKS provides a definitive roadmap for any enterprise seeking to modernize legacy Windows applications. By embracing the efficiency of Windows containers and the power of Kubernetes orchestration, Tipalti has transformed a traditionally rigid system into a high-performance engine for global fintech growth. Their experience highlights that successful modernization requires a combination of strategic technical decisions, a commitment to DevOps excellence, and a focus on long-term scalability. This transformation proves that even the most “constrained” legacy applications can be revitalized to meet the demands of the modern digital economy.
Links:
[DevoxxFR 2018] Deploying Microservices on AWS: Compute Options Explored at Devoxx France 2018
At Devoxx France 2018, Arun Gupta and Tiffany Jernigan, both from Amazon Web Services (AWS), delivered a three-hour deep-dive session titled Compute options for Microservices on AWS. This hands-on tutorial explored deploying a microservices-based application using various AWS compute options: EC2, Amazon Elastic Container Service (ECS), AWS Fargate, Elastic Kubernetes Service (EKS), and AWS Lambda. Through a sample application with web app, greeting, and name microservices, they demonstrated local testing, deployment pipelines, service discovery, monitoring, and canary deployments. The session, rich with code demos, is available on YouTube, with code and slides on GitHub.
Microservices: Solving Business Problems
Arun Gupta opened by addressing the monolith vs. microservices debate, emphasizing that the choice depends on business needs. Microservices enable agility, frequent releases, and polyglot environments but introduce complexity. AWS simplifies this with managed services, allowing developers to focus on business logic. The demo application featured three microservices: a public-facing web app, and internal greeting and name services, communicating via REST endpoints. Built with WildFly Swarm, a Java EE-compliant server, the application produced a portable fat JAR, deployable as a container or Lambda function. The presenters highlighted service discovery, ensuring the web app could locate stateless instances of greeting and name services.
EC2: Full Control for Traditional Deployments
Amazon EC2 offers developers complete control over virtual machines, ideal for those needing to manage the full stack. The presenters deployed the microservices on EC2 instances, running WildFly Swarm JARs. Using Maven and a Docker profile, they generated container images, pushed to Docker Hub, and tested locally with Docker Compose. A docker stack deploy command spun up the services, accessible via curl localhost:8080, returning responses like “hello Sheldon.” EC2 requires manual scaling and cluster management, but its flexibility suits custom stacks. The GitHub repo includes configurations for EC2 deployments, showcasing integration with AWS services like CloudWatch for logging.
Amazon ECS: Orchestrating Containers
Amazon ECS simplifies container orchestration, managing scheduling and scaling. The presenters created an ECS cluster in the AWS Management Console, defining task definitions for the three microservices. Task definitions specified container images, CPU, and memory, with an Application Load Balancer (ALB) enabling path-based routing (e.g., /resources/greeting). Using the ECS CLI, they deployed services, ensuring high availability across multiple availability zones. CloudWatch integration provided metrics and logs, with alarms for monitoring. ECS reduces operational overhead compared to EC2, balancing control and automation. The session highlighted ECS’s deep integration with AWS services, streamlining production workloads.
AWS Fargate: Serverless Containers
Introduced at re:Invent 2017, AWS Fargate abstracts server management, allowing developers to focus on containers. The presenters deployed the same microservices using Fargate, specifying task definitions with AWS VPC networking for fine-grained security. The Fargate CLI, a GitHub project by AWS’s John Pignata, simplified setup, creating ALBs and task definitions automatically. A curl to the load balancer URL returned responses like “howdy Penny.” Fargate’s per-second billing and task-level resource allocation optimize costs. Available initially in US East (N. Virginia), Fargate suits developers prioritizing simplicity. The session emphasized its role in reducing infrastructure management.
Elastic Kubernetes Service (EKS): Kubernetes on AWS
EKS, in preview during the session, brings managed Kubernetes to AWS. The presenters deployed the microservices on an EKS cluster, using kubectl to manage pods and services. They introduced Istio, a service mesh, to handle traffic routing and observability. Istio’s sidecar containers enabled 50/50 traffic splits between “hello” and “howdy” versions of the greeting service, configured via YAML manifests. Chaos engineering was demonstrated by injecting 5-second delays in 10% of requests, testing resilience. AWS X-Ray, integrated via a daemon set, provided service maps and traces, identifying bottlenecks. EKS, later supporting Fargate, offers flexibility for Kubernetes users. The GitHub repo includes EKS manifests and Istio configurations.
AWS Lambda: Serverless Microservices
AWS Lambda enables serverless deployments, eliminating server management. The presenters repurposed the WildFly Swarm application for Lambda, using the Serverless Application Model (SAM). Each microservice became a Lambda function, fronted by API Gateway endpoints (e.g., /greeting). SAM templates defined functions, APIs, and DynamoDB tables, with sam local start-api testing endpoints locally via Dockerized Lambda runtimes. Responses like “howdy Sheldon” were verified with curl localhost:3000. SAM’s package and deploy commands uploaded functions to S3, while canary deployments shifted traffic (e.g., 10% to new versions) with CloudWatch alarms. Lambda’s per-second billing and 300-second execution limit suit event-driven workloads. The session showcased SAM’s integration with AWS services and the Serverless Application Repository.
Deployment Pipelines: Automating with AWS CodePipeline
The presenters built a deployment pipeline using AWS CodePipeline, a managed service inspired by Amazon’s internal tooling. A GitHub push triggered the pipeline, which used CodeCommit to build Docker images, pushed them to Amazon Elastic Container Registry (ECR), and deployed to an ECS cluster. For Lambda, SAM templates were packaged and deployed. CloudFormation templates automated resource creation, including VPCs, subnets, and ALBs. The pipeline ensured immutable deployments with commit-based image tags, maintaining production stability. The GitHub repo provides CloudFormation scripts, enabling reproducible environments. This approach minimizes manual intervention, supporting rapid iteration.
Monitoring and Logging: AWS X-Ray and CloudWatch
Monitoring was a key focus, with AWS X-Ray providing end-to-end tracing. In ECS and EKS, X-Ray daemons collected traces, generating service maps showing web app, greeting, and name interactions. For Lambda, X-Ray was enabled natively via SAM templates. CloudWatch offered metrics (e.g., CPU usage) and logs, with alarms for thresholds. In EKS, Kubernetes tools like Prometheus and Grafana were mentioned, but X-Ray’s integration with AWS services was emphasized. The presenters demonstrated debugging Lambda functions locally using SAM CLI and IntelliJ, enhancing developer agility. These tools ensure observability, critical for distributed microservices.
Choosing the Right Compute Option
The session concluded by comparing compute options. EC2 offers maximum control but requires managing scaling and updates. ECS balances automation and flexibility, ideal for containerized workloads. Fargate eliminates server management, suiting simple deployments. EKS caters to Kubernetes users, with Istio enhancing observability. Lambda, best for event-driven microservices, minimizes operational overhead but has execution limits. Factors like team expertise, application requirements, and cost influence the choice. The presenters encouraged feedback via GitHub issues to shape AWS’s roadmap. Visit aws.amazon.com/containers for more.
Links:
Hashtags: #AWS #Microservices #ECS #Fargate #EKS #Lambda #DevoxxFR2018 #ArunGupta #TiffanyJernigan #CloudComputing