Cloud Architecture Series #2 - Application Architecture Patterns

In the previous post Cloud Architecture Series #1 - Application Architecture Fundamentals we briefly started with application architecture on cloud. Today let's have a look at some of the well known patterns we can use based on the application architecture, service requirements and complexity.

Though architecture patterns have their own characteristics, it does not really tie to use of a particular technology. It generally provides recommendations for technologies that can be well-suited for a particular architecture.

Architecture pattern help identify the common ground for building the application as well as the guidance for post development efforts such as integration with cloud and/or third-party services, deployment considerations, operational support, customer onboarding, etc.

Some of the well known architectural patterns for designing applications on cloud are,

• Existing enterprise applications which have a layered stack of dependent components/services that built the complete application are generally for the N-tier application pattern. It is generally a natural fit while migrating existing applications to cloud. The highly-coupled components can help distinguish logical functions in an application but can be a challenge to manage frequent changes to the application.
• Similar to enterprise applications, some of the domain specific, resource intensive applications design take advantage of messaging for communication across different components in an application. The Web-queue-worker pattern is suitable for such applications. It helps distribute the communication barrier in large enterprise applications but individual components can easily become large, monolithic silos and get challenges similar to N-tier applications.
• If your application is complex and you are luxury to rearchitect it, moving to a Microservices architecture is for you. In this pattern, the application is composed of many small, independent, loosely-coupled services implementing a single business capability. This pattern is more complex to build than the previous patterns discussed and requires a mature development & DevOps culture, but when done right can help with more resilient architecture.
• Event-driven architecture or pub-sub model is a good pattern, when you have an applications which is built using highly distributed (in)dependent components, they generally rely on asynchronous communication and are generally data intensive.
• For applications that run large batch processing tasks, work on a large data sets for analytics/reporting or are high-performance computing tasks are generally modeled after the big-data or big compute architecture pattern.

Though this list can grow to accommodate any number of patterns based on use-case, it is generally recommended to understand the application design principles and constraints to use a particular pattern. It is also recommended to be pragmatic and relax on certain constraints or using mix-match approaches of known patterns than to insist on a architectural parity.

More updates to subscribe to the?Cloud Native Hero! Newsletter

LinkedIn?|?Twitter?|?GitHub?|?Blog