Architecture Styles for Azure
An architecture style can be defined as a family of architectures that share some common characteristics. The right architecture is a critical aspect of any systems development process. Although an architecture should be independent of any specific technology, certain technologies may greatly facilitate the implementation of certain architectures. In this article, we will look at some architecture styles commonly used in cloud applications.
N-Tier
N-Tier is the most common and traditional architecture style for enterprise applications. Applications are designed by segregating into layers that perform some kind of logical function. Common examples are user interface, business logic, and data access layers. Layers can only call into a layer that sits directly below it. This kind of horizontal layering may make it difficult to introduce changes to a layer without affecting the associated layers (cascading changes between layers). In such cases rolling out changes frequently might become a challenge. Solutions involving Infrastructure as a Service (IaaS) and managed services are good scenarios to consider a N-Tier architecture style.
Microservices
Complex applications involving a lot of different components can be designed using a Microservices architecture style. This style involves dividing the entire application into small, independent services which are loosely coupled and where each service performs a specific business function. These services communicate through API contracts. This kind of design also facilitates smaller and frequent deployments by assigning a separate team to develop and maintain each service. This architecture style is more complex to build with and maintain and also requires a sophisticated development and operational culture. However, the benefits include faster deployments, independent development teams, and more robust architecture.
Web-Queue-Worker
As the name suggests, this architecture style depends on three structural components – web, queue and worker. Requests are sent using web APIs (HTTP requests). These requests are stored and maintained in asynchronous message queues. These messages/requests are picked up from the queue and services by back end worker jobs. These jobs are usually CPU and resource-intensive. Care must be taken so that the web and worker processes don’t become monolithic and hard to manage. This style of architecture is often recommended for applications with simple domains.
Event-Driven architecture
Event-driven architectures depend on having two categories of components – publishers and consumers. Hence these are termed as pub-sub models. Publishers publish events that can be consumed by consumers. Producers and consumers are mutually independent. Even multiple consumers should be designed independently of each other. This style of architecture is best suited to applications where the same event data needs to be processed differently by different dependent components. A good example is the IoT solutions.
Big Data, Big Compute
These are specialized architecture styles for very specific scenarios. Big data divides a big data into chunks for parallel processing. Big compute divides workloads into a large number of cores for High-Performance Computing (HPC). Examples include simulations, 3D modeling etc.
Challenges and Benefits
One must consider the challenges and the trade-off with benefits before deciding on an architecture style. Some common challenges to consider are:
Complexity – Is the higher complexity justified for the domain?
Synchronicity – Asynchronous messaging is useful to decouple components but at the same time introduce implementation challenges.
Inter-Service communication – Decomposing an application leads to challenges in data loss prevention, error handling, and latency.
Manageability and deployment cycles – Is the choice of architecture affecting the manageability or deployment velocity?
