Designing a Scalable and Highly Available Infrastructure for Microservices on AWS

Designing a Scalable and Highly Available Infrastructure for Microservices on AWS by Nicolas El Khoury

Transcript

5. Explanation Zip code locally. SSH to the remote machine. Unzip the code. Start the Service Manually. Disadvantages Time Consuming / Downtime. Non Scalable / Not Production Ready. Single point of failure. Requires extensive manual intervention.
6. Explanation Ability to run one instance of each service. Start the container manually. Process runs independently from the host machine. Service restarts automatically. Disadvantages Time Consuming / Downtime. Non Scalable / Not Production Ready. Single point of failure. Requires extensive manual intervention.
7. Explanation Ability to have multiple instances of each service. Provides availability, scalability, and load balancing. Suitable for production. Start the Service Manually. Disadvantages Time Consuming (Relatively). Requires considerable manual intervention.
8. Automate the build and deployment. Centralize the deployment. Allow every developer to deploy at will.
9. Logging: Dumped logs on AWS, giving access to all the developers. Monitoring: Every node, service, and container. Traceability: Tracing every request, revealing system errors, latencies, etc.
10. THINGS WENT WRONG!!
11. Overprovisioning of Resources. Risky Resource Monitoring Setup: Prometheus setup inside the Swarm. Manual Scaling: On the machine and service level. Risk of System Failure.
12. All the services were migrated to AWS Fargate All the workers (Event-driven applications) were migrated to lambda functions
13. Autoscaling: set up with a few clicks. Enhanced Monitoring System: AWS cloudwatch. No Risk of System Failure (Contained Risk). Less things to worry about: Docker Swarm, EC2 machines, Third party monitoring system. Decreased Cost: ~17%.
16. Catalog Module Customer Module Order Module Payment Module Catalog Service Customer Service Order Service Payment Service Monolithic Architecture Microservices Architecture Catalog Module Customer Module Order Module Payment Module
17. Fault Tolerance: Failure in one service does not impact other services. High Scalability: Ability to scale up/down distinct services on demand. Ease of Maintenance: Smaller and simpler code blocks. Technological Freedom: Different microservices can be built using different technologies. Ease of Deployment: using containers (e.g. Docker).
18. Security Availability (fault Tolerance) Scalability Visibility: Logging, monitoring, tracing
23. Security Availability (fault Tolerance) Scalability Visibility: Logging, monitoring, tracing
24. VPC Level: • Ingress Traffic Control: Network traffic entering a VPC. • Egress Traffic Control: Network traffic leaving a VPC. Load Balancer Level: • Security Groups: A security group acts as a virtual stateful firewall that controls the traffic. • Host/Path/Port based Routing Instances Level: • Security Groups • Deployed in private subnets
25. Example of AWS ALB Routing Policies, AWS Documentation
26. Container Level: replicating containers of each service. Load Balancer Level: managed by AWS. Availability Zone: Spreading instances across multiple availability zones
27. Ability to scale Microservices on demand, automatically, with a few clicks of a button.
28. Logging: AWS Cloudwatch Logs. Monitoring: • Instances: CPU Utilization, Network in, Network Out, etc. • Load Balancer: Target Response Time, 4XX Count, 5XX Count, etc Tracing: The load balancer saves important information of each request.