Repository files navigation

This is a shopping application designed with microservices architecture. My main goal is to learn aboutdevops and microservices, but I am also improving the domain part as much as possible. The project is about recordingtransactions of a shopping application.Check to see how to run.

In development mode, microservices are running as separate processes on your computer. The API Gateway, database,RabbitMQ, Redis and Keycloak runas Docker containers. Since all microservices run on the same device, they should expose a different port. Thecommunication between clientand microservices is done through the API Gateway. Databases are in the same instance for the sake of simplicity in thisenvironment.

In test mode, the whole application lives in a Kubernetes cluster which runs on your computer. Microservices, APIGateway, databases, Redis, RabbitMQ and Keycloak nowrun as Kubernetes deployments or statefulsets.

The communication between components is done through services (another Kubernetescomponent, shown as triangles). In terms of scalability, microservices can have more than one instances, calledreplicas. With Kubernetes, we can easily definea new replica for a microservice if we need more instances to distribute upcoming traffic. For example account servicecan have 1 replica and inventoryservice can have 3 replicas. Distributing the traffic across the replicas is also done with services.

Production environment is very similar to the test environment. However, the cluster is on remote servers now, just likea real worldproduction environment.I used AWS as a cloud provider for this environment. I also provisioned the databases on AWS, not inside Kubernetes.Please note that I'm not keeping the production environment up7/24, that would be very costly.Let's explain each component shown in the diagram one by one:

• Route 53: This service is responsible for managing DNS in AWS. When the client types a url, suchaswww.solidvessel.com , it is resolved to the url of the ALB.This process is done by Route 53.
• ALB: The ingress resource defined for the K8S cluster is converted to an ALB (Application Load Balancer). AWSreads the routing rules, services and the SSL configuration we defined in the ingress file and applies all of them inthe ALB which will route the traffic to the cluster. Each ingress defined in K8S has a correspondence in ALB.
• Target Groups: These are subcomponents of the ALB. A target group is solely responsible for load balancing. Forexample if a deployment has 3 replicas, it's the target groups responsibility to distributethe traffic across the replicas. Each Kubernetes servicedefined in the ingress file is converted to a target group in ALB.
• Private Subnet: Giving nodes (servers) of the cluster public IP addresses poses a security risk. Anyone could seethe nodes andtry to exploit them. To prevent this, all servers are inside a private network, making them invisible from the outsideworld.
• NAT Gateway: Since our nodes don't have a public IP address, they can't directly access to the internet. We need aserver that does a network address translation (NAT), making our nodes access the internet in a more secure way.
• Public Subnet: This is where servers are publicly visible. We need ALB to be public to access our application. Wealso need NAT Gateway to be public to give internet access to our nodes. The security of these two are handled by AWS.
• Master Nodes: These are responsible for managing worker nodes. We don't really have any control over master nodes,they are fully managed by AWS.
• Worker Nodes: These are where our applications run. The Kubernetes cluster drawn in the test environment isspanned acrossthe worker nodes here.
• CloudFormation: The whole infrastructure (nodes, subnets, ALB, NAT gateway etc.) is built on CloudFormation. Thisserviceprovides a way to manage AWS resources easier using declarative approaches.
• RDS: All databases are provisioned by using RDS (Relational Database Service). The engine is still PostgreSQL butbackups,monitoring, high availability and disaster recovery is much easier. When the environment is going up, the databasesareprovisioned from previous snapshots, so the data is never lost.

• Run options
• Hexagonal Architecture
• Synchronous Communication
• Circuit Breaking
• Asynchronous Communication
• API Gateway
• Authentication & Authorization
• Horizontal Scaling
• Load Balancing
• Entity Relations
• Caching
• Shared Module
• Infrastructure as Code
• GitOps
• From Zero to Prod In Minutes
• Testing

• Domain enrichment (add more features)
• Data enrichment (add millions of records for prod environment)
• Monitoring (Prometheus, Grafana etc)
• AI assistant (agents to perform tasks on Kubernetes)
• Maybe it's time to create a frontend ??
• Apply CQRS in one of the microservices
• Migration from RabbitMQ to Kafka
• Microservice with different framework
• Microservice with different programming language