loader

Migration from traditional DC to Amazon Web Services AWS with Terraform

ABOUT THE PROJECT

A company in the enterprise sector is looking for partner to migrate a Java Monolith Application to Containerized environment in Amazon Web Services AWS. Thus improving the release cycles, overall operations, activities, and availability of services.

THE CHALLENGE

The customer has multiple suppliers in different world locations and all of them are involved in the development of their product.
The product itself is in the form of a Monolith Application which is considered outdated and difficult to go through all CI/CD phases. It is slowing down the development cycles, operations are becoming  more complex as the new deployments involve downtime of multiple services.


THE SOLUTION

The situation is quickly assessed and the solution is to break the application into microservices and utilize technologies such as Docker, Kubernetes, and Jenkins – for doing the CI/CD. In terms of hosting the Containers, it is decided to use Amazon Web Services AWS.

The company requests professional services from ITGix and we work on establishing a plan to:

  • set up a secured and automated environment in AWS;
  • integrate the on-premises datacenter of the company with Amazon VPC;
  • set up an automated and centralized monitoring, log aggregation and scalable container management system.

For the project we advise the Customer to use Amazon Web Services which would not lock him with a specific custom solution. ITGix is completely responsible for the deployment, monitoring, and the update of the Kubernetes cluster.

Setting up a secured and automated environment in AWS:

The approach in that specific case is using Terraform with S3 and DynamoDB for a state locking. Moreover, the environment code is broken down into multiple modules for efficient usage and easy recreation for DR scenarios and replication. We follow the approach of infrastructure-as-a-source-code and git for preserving that code. Naturally we managed to improve the cycles as using the trunk-based approach and git review for each new improvement. Moreover, we see a good opportunity to switch the configuration language to Ansible and create roles for provisioning where it is needed.

Integration of AWS and DC:

We face challenges to keep the same authentication mechanisms and DNS principles for the VPCs. We secured the connection for services by implementing an integration with SimpleAD and utilized the HA VPN connectivity with a good organization of routing for all VPCs.

Centralized Monitoring and Log Aggregation:

We have difficulties using Cloudwatch so we decide to utilize a hybrid approach with Icinga and Prometheus. Having mixed types of applications and servers require a deep look into the solutions. However, we manage to run them in containers and utilize Grafana for segregation of different data-sources and correlation dashboards.
Container Management System:
Last but not least we have to work on a container management system that is going to improve the overall experience and management of the core component. The non-functional requirements for each application are clear, so we decide to build our container management system with Kubernetes. This decision is taken based on the “non-vendor lock” requirement and future development of the hybrid cloud strategy.