Unprecedented disruptions are unavoidable, so failure can happen. So, failure design must be considered to avoid service unavailability for customers. Failure for design aims to recover applications or services from failure. It is designed for self-healing or auto-recovered infrastructure. It makes the services highly available, delivers greater uptime, prevents outages, and thus gains customer trust. Few key factors for failure design for microservices are to be considered as below –
Disposability
Create lean or tiny container images to deploy services or applications so it can be started so stopped very quickly – in few seconds. So Fast startup and quick graceful shutdown is prerequisite for failure design.
Dev/Prod Parity
Developer must maintain Dev, Test and Production environments as close/similar as possible.
Logs
Capture traces of failure events in logs to do troubleshooting.
The principle of ‘failure design’ is – ‘Consider everything fails, avoid single point of failure’. It means applications or services continue to run or operate even the hardware fails/removed or replaced. There are many AWS fault-tolerant services available to consider while designing the applications – multi-AZ app deployments and data replication, EBS (Elastic block storage) snapshots, Auto-scaling etc.
4.2 Monolith to Microservices Migration
Monolith application means all the application components are bundled together and deployed as one unit of execution. For Java based applications, one monolith application includes everything put into a single WAR file and running it in an Application Server or in ASP.Net applications deployed and run in IIS.
Monolith applications starts with simple and became giant slowly getting more functionality added and suffers from below disadvantages-
Each component or functionality cannot be scaled independently as each one is tightly coupled with another.
High code maintainability due to many hidden dependencies.
More error prone as one change might affect other components.
Takes time to get into production release.
Organizations started long back to design microservices instead of monolith applications. Each business functionalities can be designed as microservices having its own unit of execution, deployment, business logic and database (sometimes it can use shared database as well). It is more generally decentralized and loosely coupled system. It has following benefits –
Microservice is small in nature, scaled based on user’s demand alone.
Microservice can be updated/modified independently without impacting other components.
Development cycle is faster. Features can be delivered to production quickly. Shorter go-to-market time. Multiple production releases can be made easily in a week.
Each microservice is isolated, so more fault-tolerant system can be developed. It can avoid single point of failure. Entire application will not be suspended if one service fails.
