Software Architecture Patterns: Navigating the Landscape

Software Architecture Patterns

In part one of this blog post series, we discussed the role of software architecture with regards to functional and non-functional requirements. Next, let us discuss some fundamental patterns when thinking about software architectures.

Software architectural design patterns are language and implementation-independent, well-known, and established solutions to non-functional problems common to various software systems with potentially vastly different functional requirements. Software architecture patterns are not to be confused with software design patterns, e.g., as the well-known patterns defined by the Gang of Four which are language-type dependent (i.e., only apply to object-oriented languages). Software design patterns are concerned specifically with how to implement a single software component, how to organize its code, and how to improve the general coding experience. Software design patterns do not consider non-functional requirements at all.

Software architecture patterns, on the other hand, enable you to achieve specific architectural goals like serving millions of customers at the same time without slowdowns, or guaranteeing that data that is entering the system is not lost in any circumstances, not even in case of natural disasters. Other goals may be concerned about low costs, energy efficiency or having a low memory footprint. With a software architecture you address such goals specific to your software and work out a solution. Typically, they target large-scale systems that potentially include multiple services written in various languages, but they are equally important for smaller, entry-level systems, too.

Let us look at a few examples of software architecture patterns that can be found in today’s software systems and that may show a transition from the traditional to the modern (but each serving valid use cases):

Monolithic Architecture

An architectural pattern where all components are tightly coupled and run on a single server and are part of the same codebase. Typically, all components also run within a single process and share the same memory.

A non-exhaustive list of advantages:

• Components can efficiently communicate synchronously or asynchronously with each other with little to no overhead by using in-memory structures
• Easy initial development and low deployment complexity

A non-exhaustive list of disadvantages:

• Typically, suitable for non-complex business logic (although there seem to be a few counter examples out there, e.g. stackoverflow, shopify)
• Lacks flexibility
  • • Code changes in a single component requires re-deployment of the entire software system with all its components
    • Changing technology in one component can lead to changes in all others
    • Development, maintenance, and manageability become harder while software evolves, and business logic becomes more complex
• Weak scaling capabilities. Scaling needs in one component requires scaling of all components, e.g., by replicating the entire application
• Coordination overhead for development teams increases with team size due to the single code base

Multi-Tier Architecture

A client-server architecture, which typically is realized as a 3-tier architecture and is separating the rendering logic, the application processing logic, and the data management logic by physically isolated components. It can be considered as a first step towards microservice architecture. Hence, advantages and disadvantages are a mixture of the monolithic and the microservice architecture. In the simplest case, however, the processing logic remains a monolith, the rendering logic is taken over by the end-user device, e.g. a cell phone, and the data management logic is modulated by an SQL database.

Microservice Architecture

The gist of microservice architecture is to have fine-grained, distributed components that are only loosely coupled, and which can communicate through lightweight protocols.

Each microservice component can have its own architectural features with distinguished non-functional requirements and is maintained in dedicated code bases.

A non-exhaustive list of advantages:

• Very flexible
  • • Code changes or entire technology changes in one component affect only the individual component
    • Typically, components can be deployed independently of other components
    • Team responsibility can be distributed over components
• Scales well by replicating only individual components as needed

A non-exhaustive list of disadvantages:

• Communication costs depend on number and size of messages and can be high
• Complex and Challenging
  • • Initial design and statements on performance of the design
    • Data consistency and state synchronization over all components
    • Logging, debugging, and tracing over multiple components
    • Initial deployment, maintenance, and monitoring
• Requires hardware that allows a high degree of parallelism. Potentially, a distributed environment with fast network connectivity is needed

Event-Driven Architecture

The event-driven architecture can be a microservice or a monolithic architecture. The pattern focuses specifically on how components collaborate. Components of an event-driven architecture are inherently decoupled and interact by triggering or receiving asynchronous events. There is no direct dependency between components. Instead, there are two main types of components: producers and consumers of events. An event represents a notable change in the system’s state and requires some action by one or multiple components. An event is an abstract concept that can be freely defined, e.g., an event can be a user interaction like a button click; it can be data driven, e.g., the storage backend was modified, or it can be anything else, e.g., a long-running task finished. The routing of events happens over a channel or bus (e.g., via a message broker like RabbitMQ or a service bus like MassTransit), which is a component taking care of getting events from the producers, validating, storing, and delivering them to consumers.

A non-exhaustive list of advantages:

• Flexible and modular due to its inherent, decoupled event handling nature. To a certain extent, this is also true for monoliths as module-threads can act as consumers and producers
• Scalable, as consumers or producers can be individually replicated
• Flexible handling of events. Handling can be deferred and done when needed or when processing resources become available
• Fault tolerant as failing components can be replaced without losing events

A non-exhaustive list of disadvantages:

• Data and workflow can be complex and hard to understand
• Logging, debugging, and tracing of multiple components can be challenging
• Operational overhead for deployment, maintenance, and monitoring can be high and can involve external components like message brokers
• Events may unexpectedly be processed with delays

Event-Sourcing Architecture

The event sourcing architecture is a variant of the event-driven architecture in which all events are stored as a sequence of changes to the system’s state. The system’s current state is established by the appliance of all events in the sequence. Consumers can read and project the sequence of events into their own, dedicated representation for providing a specific functionality. In this way, various specialized representations can help to efficiently support different use-cases.

A non-exhaustive list of advantages:

• Robustness: an event sequence represents historical data which can be used to rewind the system state to any earlier point in time
• Traceability: you easily can reproduce issues as the exact order of events which have led to an issue is part of an event sequence
• Flexibility: more use cases can be supported by dedicated consumers

A non-exhaustive list of disadvantages:

• High complexity: logic to roll back to a previous state or managing various projecting components with specialized data representation can be difficult.
• High Storage costs: keeping all events over time and various projections can require high storage costs
• Compatibility Issues: Changing the data or event schema implies complex decisions regarding existing event sequences. Converting events and data can be costly and breaks compatibility. Applying versioning to events is not trivial

Cloud-Native Architecture

In contrast to applications following the monolithic architecture and which may be adapted later to host them in the cloud, a cloud-native architecture is targeting the cloud from the start and is explicitly utilizing features and benefits of a cloud computing environment. See also our article series about Cloud-Native. Cloud-native architecture takes the notion of microservice architecture to the next level. Cloud-native components are realized as a set of microservices which are hosted in containers, each providing a coherent execution environment specific to the inner service.

A cloud-native architecture makes it possible to work with virtually unlimited resources in contrast to conventional architectures designed for hardware-based server environments. Resources required by your applications can be provided on-demand by cloud providers as Infrastructure as a Service (IaaS), platform as a service (PaaS), and software as a service (SaaS). However, cloud-native does not mean your software must run remotely in a public cloud, but, depending on your non-functional requirements, it is a valid option. The architecture, however, allows also for targeting a private cloud provider, or setting up and configuring a software platform, like Kubernetes, on own hardware servers to manage and run cloud-native components locally.

A non-exhaustive list of advantages, especially in combination with public or private cloud providers:

• Pay-As-You-Go: Instead of paying for setup, maintenance, and operation of own servers (even when idling), you only pay for used or reserved resources
  • • Transition from capital expenditures (CapEx) to operating expenses (OpEx)
    • Low entry costs to start with building up own services
• Allows to utilize mature tools, features, and high-availability services from cloud providers, e.g., databases, load balancers, diagnosing tools for own software, etc.
• Extremely flexible as inherently scalable, reliable, and available by nature
• Fail-safety: clouds can distribute services worldwide for increased availability
• Locality: services can be hosted close to your customers for faster response times
• Security: a shared responsibility model reduces security risks for cloud customers
• Hybrid setups are possible with cloud-native components hosted locally on own hardware and remotely in a public or private cloud

A non-exhaustive list of disadvantages, especially in combination with public or private cloud providers:

• Pay-As-You-Go: difficult to understand cost model & costs can grow significantly with rising resource needs and cloud features
• Complex software architecture design with an additional focus on costs
• Hardware is either out of your control (in the case of cloud providers) or imply excessive costs for maintaining own cloud platforms
• In case of locally hosted cloud platforms, the hardware can be over- or under provisioned and scaling hardware according to software needs is difficult

The bottom line

Spotting all requirements of a software system, understanding them in detail, choosing the best-fitting software architecture pattern, potentially adapting the design, and tailoring it to the needs of your software system can be challenging and makes designing a software architecture at the same time daunting and intriguing. In any case, it must be well thought out. It is inherent to all software architecture designs that once implemented, changing it later again is very time-consuming, work-intensive and extremely costly.

We at CID have decades of experience in planning and designing software architectures. As CID is hosting a private cloud at a large scale, we specifically have long-term knowledge and experience with all kinds of cloud related topics. Whether it is a digital cloud transformation process, e.g., to bring an old-fashioned monolith into the cloud, or the development of cloud-native components from scratch, you will always find a reliable partner at CID.

Author © 2024: Dr. Tom Crecelius – www.linkedin.com/in/tom-crecelius-65a16949/