Epos Now Case Study

Problem

Bring the benefits of modern code-base and technical needs of their infrastructure, it relies heavily on flexibility and scalability. However, EposNow REST API was built as a monolithic .NET Framework API bundled in a single repository with almost 20 projects and 1 host.

EposNow’s REST API presented five main challenges:

- Splitting the monolith - Splitting the .NET Framework-based monolithic application to .NET Core based domain services as well as splitting the code repository.
- Performance - Lower response times, lower memory, and CPU resources.
- Windows licensing cost - Hosting applications into Windows instance types means higher cost than Linux instance types.
- Lack of agility - .NET Framework-based applications can count as a legacy. So, it may not be possible to keep libraries up to date and may not be possible to use featured libraries that are only developed for .NET Core applications.
- Limited Scalability - Scaling with the increased volume in traffic involves scaling the entire application even scaling at a specific part of the application is enough.
- Seamless modernization - Keeping the same interface to ensure EposNow REST API can be consumed without any kind of change required on the client-side.

Client: Epos Now

Project type: .NET Modernization

Website: eposnow.com

Solution

One of the most critical tasks was splitting the monolithic application into domain services while keeping the same interface of the EposNow REST API. Splitting a monolith causes complexity. Struggling with that complexity poses many challenges. Branching models, code level abstractions, patterns, DevOps/DevSecOps, service to service communications, authentication/ authorization, centralized logging, monitoring, API Gateways, and many other concerns should be taken into consideration.

We also changed the logging approach from push-based to pull-based, which is the best practice for containerized environments. The Serilog library was used to get structured logs with ease.

The latest version of the .NET Core was the framework we used for the .NET Framework modernization.

The modernization was not only splitting the monolith but also the overall modernization of DevOps/DevSecOps, which uses the latest tools and technologies such as GitLab, Helm, snyk, terraform, EKS, API Gateway, Lambda, ALB.

EposNow had CI/CD implementation for their API to build it and deploy to Windows instances. We decided to keep the same tool as GitLab for the code repository and CI/CD tool as well.

We believe that one of the most important approaches is “everything is code” so Terraform was the tool we used to apply it to the overall infrastructure.

To reap the benefits of container orchestration, we decided to use Kubernetes with EKS.

Even though we split the monolithic application to domain services, to keep the same interface for developers/clients who currently use the EposNow API, we decided to use nginx-ingress for path-based routing on top of the infrastructure.

Splitting the Monolith

After our analysis on domain and bounded-contexts, we have defined the dependencies between the contexts and decided to apply the Strangler-Fig pattern to split the contexts. Based on the complexity of each pattern, we began splitting one by one and the traffic is diverted on ALB layer in a path-based manner, to the splitted domain services.

By the end of the project, domain services are now deployable and are scaled independently.

eposnow-diagram-06

Results

By converting monolithic legacy applications from the .NET Framework into .NET Core and EKS, enterprises can reap the agility, scalability, and cost-savings benefits of the cloud.

Kloia used .NET Core and EKS to modernize EposNow’s legacy REST API into cloud-native.

We at Kloia, are interested in hearing about your application modernization approach, the challenges you face, and the solutions that work for you.

Here is the related Blogpost on AWS APN Blog:

https://aws.amazon.com/partners/success/epos-now-kloia/

Some of our results:

60%
Performance Increase
42%
Cost reduction on EC2