Managing Serverless Multi-Tier Architectures in OpenSooq
The multi-tier application (three-tier, n-tier, etc.) has been a cornerstone architecture pattern for decades. The multi-tier pattern provides good guidelines for you to follow to ensure decoupled and scalable application components that can be separately managed and maintained (often by distinct teams). Multi-tiered applications are often built using a service-oriented architecture (SOA) approach to using web services. In this approach, the network acts as the boundary between tiers.
I show how we design multi-tiered architectures for popular patterns such as microservices, mobile backends, and our website. Architects can now use an implementation pattern that reduces the development and operations cycles required to create and operationally manage multi-tiered applications.
The multi-tier architecture pattern provides a general framework to ensure decoupled and independently scalable application components that can be separately developed, managed, and maintained (often by distinct teams).
As a consequence of this pattern in which the network (a tier must make a network call to interact with another tier) acts as the boundary between tiers, developing a multi-tier application often requires creating many undifferentiated application components. Some of these components include:
- code that defines a message queue for communication between tiers,
- code that defines an API and a data model,
- and security-related code that ensures appropriate access to the application.
Conclusion
The multi-tier architecture pattern encourages the best practice of creating application components that are easy to maintain, decouple, and scale. When you create a logic tier where integration occurs via Amazon API Gateway and computation occurs within AWS Lambda, you realize these goals while reducing the amount of effort to achieve them. Together, these services provide a HTTPS API front end for your clients and a secure environment to execute your business logic all while removing the overhead involved with managing typical server-based infrastructure.
