Scalable micorservices based architecture
Download as PPTX, PDF0 likes110 views
The startup intends to migrate its monolithic application to a microservices architecture to improve scalability, availability, and maintainability. Key objectives for the new architecture include service discovery, autoscaling of microservices, database design, load balancing, and avoiding downtime. The proposed architecture uses Kubernetes for container orchestration, includes an API gateway and load balancers for traffic routing, allows each microservice to have its own database, and implements fault tolerance techniques like retries and caching. The architecture would be deployed on AWS for its managed services.
Scalable micorservices based architecture
- 2. Problem Statement > A Start-up has - A monolithic application - Traditional 3-tier architecture (web server, JBoss, MySQL) - Intends to migrate to an architecture that can handle future needs > Futuristic Architecture needs - Highly-scalable, highly-available, highly-performing - Secure, efficient and elastic - Easy to maintain
- 3. Customer's Specific Objectives ⢠Service Discovery ⢠Granularity of a microservice ⢠Autoscaling of microservices ⢠DB design (1 DB instance per microservice or 1 common DB instance) ⢠Data consistency across Microservices ⢠Loadbalancer configuration for distributing load ⢠Logging ⢠Avoiding Downtime ⢠Use of managed services to manage the microservices
- 4. Scalability & High-availability > Network & Infrastructure load - Load balancer for web servers to handle exponential growth in web traffic - Cluster of web servers are run to ensure high-availability - Based on rate limits or CPU/RAM usage limits, new containers will be automatically spawned via Kubernetes > Application load - Incoming traffic is routed through an API gateway, - Kubernetes Ingress & Application Load balancer (Layer 7) are used to manage very high spurts
- 5. Modularity & Communication > System is reduced to a number of much smaller pieces of independent business logic (microservice) > Each microservice will have its independent data persistence capability - Depending on the service, the database could be RDBMS or NoSQL > Each service can communicate with several or every other service - IPC mechanism and data exchange mechanism for each communication will be driven by the specific need (REST, XML/JSON or pub-sub with queues) > Server-side services discovery pattern using Kubernetes DNS
- 6. Fault Tolerance > Service Failures - Limit the number of waiting requests per service instance - If number of failed requests breach threshold, mark the instance as "unresponsive" for a specified period of time - For non-transactional / information requests, cached data could be provided as a response > Data Consistency Issues - Services that deal with non-transactional information are recommended to have NoSQL databases (scalable & flexible for different structured/unstructured formats of data) - As much as possible, transaction logic should be contained within least number of services (preferably 1) to prevent data inconsistency