Architecture Considerations : Part 2
Before coding an application, it’s necessary to understand the design considerations.
It depends on :
- Business Requirements -> understanding who the stakeholders are, the functionalities, the input/output process, and finally, the end-users.
- Available resources -> which include engineering resources, financial resources, time frames, and internal knowledge.
So, before diving, let us take a look at the Application Architectural designs.
Monolithic architecture:
In the monolith, all the components are coupled to each other and distributed as a single unit. As a result, all the business logic functions have the same repository, share resources, and have the same programming language. As a result, the development is simple; deployment is straightforward, and communication between components happens in the same process.
But what happens when you have to scale the application?
Yes, you are correct; it becomes much more complicated to maintain it since the change in one component would imply modifying another. Likewise, the deployment becomes more complicated since a change means redeploying the entire system again. It’s no longer a simple task since, generally the only way to scale this type of application is to replicate the whole application over and over again.
Microservice Architecture:
This type of architecture proposes to have lightweight decoupled services with a single responsibility isolated from each other with independent storage and autonomous deployability.
According to Sam Newman, “Microservices are the small services that work together.”
The Application tiers include:
- User Interface -> Handles HTTP request.
- Business Logic -> refers to the functionalities for the specific service.
- Data Layer -> for communicating with the Database.
For better understanding, take a project, e.g., design an Airplane Booking System and compare the architectures.
There is no “golden path” to design a product, but a good understanding of the trade-offs will provide a clear project roadmap.
Let’s look into the trade-offs:
- Development complexity
- Scalability — focuses that there are enough replicas of an application to satisfy all user requests.
- Time to deploy — refers to ship new features efficiently using the pipeline.
- Flexibility
- Operational cost
- Reliability- ability to respond quickly to failures by having insightful logs and metrics.
So, what can be the best practices for Application deployment?
- Health Checks
- Metrics
- Logs
- Tracing
- Resource consumption
Always remember the choice of an application structure is highly impacted by available resources, requirements, and involved trade-offs.
Beginner ? Read the Introduction to Cloud Native.
