In recent times, it appears that there are many more problems waiting to be solved. While there is an increase in the need to get these problems solved, there is also an important obligation on the part of builders to ensure that this solutions are well architected for their various use-cases and requirements (both technical and functional).

What is the Essence of Having an Architecture?

I am starting with addressing this question because a lot of us have heard about software/solutions architecture and we just think we have an idea of what it is, we think (not sure) we are already using an architecture. This uncertainties in the minds of builders is why we will address the question of what architecture is in software engineering in first finding out the essence of software architecture.

Now, in building a house, there is first a design of the house structural plan and then the outlook of the house on the interior and exterior. So also when dealing with software;

Architecture serves as a blueprint for a system. It provides an abstraction to manage the system complexity and establish a communication and coordination mechanism among components that makes up the system.

Architecture defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security.

It is important to note that:

1. You should allow architecture to grow all through the lifecycle of the project. Only architect what is possible at the level the business is, the reason is; business models, requirements and technologies are bound to change, so must the architecture.

2. You should create a domain-specific architecture. Understand the business you are architecting for. (the industry trends, business requirement, business goals and business direction)

Having noted that, we would look at some of the most common architectures of recent times their appropriate use cases and their trade-offs.

Microservices Architecture

This happen to be one of the most fashionable architectures in the last decade and even till now. Microservice Architecture can be said to be one that combines individual services which run their own processes independently into one single suite that forms an application. The individual services which are completely independent, communicate via a defined mechanism usually HTTP API resource(s).

In others words, microservices architecture tries to breakdown the entire application into smaller components that can stand alone and be deployed independently as well. This means that the different component of the application have the capability of been developed with different programming languages, have different database services but communicate via HHTP APIs mostly.

Given the definition above, here are why a lot of people are drawn to this architecture

Benefits:

1. Tends to reduce application break when adding new features i.e. makes feature releases easy.
2. The application is decentralized, hence you don't always have to fix all and deploy all components if there are no reasons to.
3. Looks a lot cleaner. You don't have to know the implementation of all components (especially ones built b different teams) but you can communicate with the components through APIs.

Take for example you want to build an E-commerce product. We could break that down into say 4 components by way of example. The components: Authentication services, Order services, checkout service, purchased-items service.

Looking at the use-case above;

Each service can be handle by different teams and endpoints are exposed for communication for other services. Another possible thing is, each of this service can be implemented by with different technologies, the most important thing is the API endpoints that provides access to communicating with other services. Let's describe what each service entail:

• Authentication service: responsible for authorizing the user and storing the user profile in state throughout the period while the authentication details are valid.
• Order service - this is responsible for managing cart and verifying items in cart as well as their prices.
• Checkout service - this handles payment, and ensuring payment records for users buying items with appropriate references from payment gateways.
• Purchased-items service - this is responsible for fetching items previously bought as well as purchase details by authenticated users in their different accounts.

Now each service is built in different teams and deployed differently, concerns have been hugely separated. You will noticed that all these services will need to talk to each other and that is made simple by exposing necessary HTTP APIs for communication.

Assuming our e-commerce product base URL is product.com

Communicating with endpoints then goes like:

For auth service:
Deployed on base URL https://product.com/auth/

You can have endpoints like;
https://product.com/auth/login
https://product.com/auth/logout

For checkout:
Deployed on base URL https://product.com/checkout/

You can have endpoints like;
https://product.com/checkout/makePayments
https://product.com/checkout/paymentCallback

As good as this architecture is, let us it its tradeoff

Best used:

• for websites with small components
• for corporate data centers with well-defined boundaries
• for rapidly developing new businesses and web applications
• for Development teams that are spread out, often across the globe

Limitations

• The architecture becomes uneasy to maintain as the application grows more complex.
• Maintaining a strong consistent is difficult for distributed system. Consistency here means the ability of your app changes to reflect in production to users are quickly as the release is done. For large systems these changes might not reflect in time. It in-turn affects the business.
• You need a mature operations team to manage lots of services, which are being redeployed regularly. A mature team in many cases still not "sooooo" easy to come by especially if you are not in the Fortune 100 companies. However this is not a yardstick to having a solid team.

Layered Architecture

Also known as multi-layered or n-tier architecture. This architecture gained grounds as it seems to be one of the commonest architectures that exists till today. It is built in a conventional manner of passing IT communications through four different layers namely: Presentation, Business (logic), Persistent and Database Layers. In essence, looking at the chain of layers you will see the entry point which happens to be data has to ended up in a database with a mechanism to check for data consistency at each layer. The architecture revolves round database. Example system using this Architecture are java EE, Drupal and basically most MVC framework tools.

MVC Model layer defines the data types and schema for storage also presents data to database. This can easily be likened to the business logic layer View- can be likened to the presentation layer. provides an interface through which customers interact with the entire architecture. Controllers - manipulates data and forms a connection between view and model. This would be the persistent layer

Benefits

Separation of concerns: each layer can stand alone, which makes maintainability easy. Modification is made easier, you will only address the layers that needs fixes.

Well layered architectures will have isolated layers that aren’t affected by certain changes in other layers, which makes refactoring easier.

Best used:

• When applications needs to be built quickly

Limitations

Layer isolation, which is an important goal for the architecture, can also make it hard to understand the architecture without understanding every module.

Small changes can require a complete redeployment of the application.

Source code can turn into a “big ball of mud” if it is unorganized and the modules don’t have clear roles or relationships.

Event-driven Architecture

Event-driven architecture like the name implies that this architecture functions when certain events are initiated within the system that the architecture defines. The good part it receives and processes the event asynchronously, making it supereasy to get thing done faster.

This architectures works with two topologies – mediator and broker. Mediator is used when multiple steps are needed to be orchestrated within an event through a central mediator. And, Broker is used when the events are required to be chained together without the use of a central mediator.

Just like we sited an ecommerce application as an example in Microservice Architecture, we will use that to explain the capability of the Event-driven architecture as well.

An ecommerce application receives requests from different source almost at the same time. The event-driven architecture can be applied in this case to respond to different events by different users on the ecommerce site synchronously (at the same time) without breaking or stressing the application.

Benefits:

• Are easily adaptable to complex environments
• Can scale easily
• Easily extendable when new event types appear

Best used:

For the applications in which individual data blocks interact with only a few modules

Limitations

• Error handling can be difficult to structure, especially when several modules must handle the same events.

• Developing a systemwide data structure for events can be complex when the events have very different needs.

• Messaging overhead can slow down processing speed, especially when the central unit must buffer messages that arrive in bursts.

Microkernel architecture

This architecture is one that is made of two components namely the core system and then plugins. You would have seen software that does particular functions on its own but also has the capability of extending itself to accommodate other modules that can render their on function(s) inform of plugins. The VS code IDE could be used as an example.

Best used:

• for the applications that have a clear segmentation between the basic routines and higher-order rules
• for the applications that have a fixed set of core routines and dynamic set of rule that needs frequent updates

Limitations

• The plugins must have good handshaking code so that microkernel is aware of the plugin installation and is ready to work
• Changing a microkernel is very difficult or even impossible if there are a number of plugins dependent on it. The only solution is to make changes in the plugins as well.
• Though it is difficult to choose the right granularity for the kernel function in advance, it is even more difficult to change it in the later stage.

Space-based Architecture

The idea of distributed shared memory is the basis of the name of this architecture. It comprises two primary components – processing unit and virtualized middleware. The processing unit component contains portions of application components including web-based components and backend business logic. However, the virtualized-middleware component contains elements that control various aspects of data synchronization and request handling. They can be custom written or can be purchased as third party products.

Benefit

There is no central database, this removes that bottleneck-providing near-infinite scalability within the application.

Best for:

• High-volume data like click streams and user logs

• Low-value data that can be lost occasionally without big consequences—in other words, not bank transactions

• Social networks

Limitations:

• Transactional support is more difficult with RAM databases.

• Generating enough load to test the system can be challenging, but the individual nodes can be tested independently.

• Developing the expertise to cache the data for speed without corrupting multiple copies is difficult.

Major Take-Aways

• Every software architecture has its benefits as well as its shortcomings
• Your choice of architectural pattern depends of your workload, functional and business requirements.
• Your architecture should be flexible as the business requirements changes , you should be able to make your changes easily.
• Do not over-architect your software. Proffer solutions that the business needs per time to avoid introducing complexities.

Credit: Techbeacon, Simform