What is Architecture

There are many definitions of the term “Software Architecture”, from outdated and informal to too abstract and pretentious. For example, we can mention the website of the Software Engineering Institute (SEI) of Carnegie Mellon University, whose electronic library contains the corresponding document.

Next, I will give my definition in order to completely confuse everyone (no).

Architecture – a set of key decisions when designing a system that meets the following criteria:

• Abstractness

• Limitation

• Changeability

• Have quality criteria

Abstractness

The architecture is (ideally) abstract and independent of implementation: protocols, programming languages, libraries, etc.

Abstraction allows you to focus on key aspects of a system, such as its structure, behavior, and interaction with other systems, while minimizing details that are not critical to understanding or implementation.

Sometimes when writing documentation (for example, on a model C4), you can see the names of protocols and file formats at the container and component levels. Only common sense decides here.

Overall, abstract architecture helps create systems that are easier to understand, change, and maintain throughout their life cycle.

Limitation

Architecture is limited by architectural style.

This follows from the definition of architectural style as a set of restrictions imposed on architecture.

A more rigorous definition can be found in dissertations REST author and one of the key developers of HTTP, Roy Fielding:

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

An architectural style is a coherent set of architectural constraints that limit the roles/features of architectural elements and the permitted relationships between those elements in any architecture that conforms to that style.

Let me give you an example of a system with the following architecture:

This architecture matches the style N-Tier Architecture and limited by it. Some restrictions:

• Layers are clearly expressed

• Each layer has its own functionality

• The top layer sees the bottom one, but not vice versa (in the picture above, the left layer sees the right one, and the arrows show the direction of the data, so Cache’s left arrows should not confuse you)

At the same time, the architectural style does not determine the number of layers and their names. These aspects are determined by the specific architecture that follows the chosen style. The implementation, consistent with the architecture, will in turn define protocols, languages, and algorithms.

Changeability

Architecture changes, “before” and “after”.

Before. The architecture presupposes a sequence of steps by which it will be implemented. The most obvious example is migration.

For example, we have a system in a data center and we want to move it to the cloud. There are the following migration strategies:

• Rehosting. Transfer without changes. If we had PostgreSQL, then it is transferred to the virtual machine without changes.

• Replatforming. Transfer with minor optimizations provided by the cloud provider. The database from PostgreSQL is migrated to managed service (AWS RDS).

• Repurchasing. We throw it away and buy another ready-made one.

• Refactoring / Re-architecting. We rewrite using all the capabilities of the cloud. We are rewriting the old monolith in serverless and lambda.

• Retire. We are getting rid of the old system. Witty.

• Retain. We don't do anything. Also witty.

Often, when migrating to the cloud, they first migrate through rehosting and replatforming, and then begin to rewrite component after component through refactoring and re-architecting.

The architecture must include all these steps.

After. We should have answers to questions like:

• How will scaling happen? What will change if the load increases by an order of magnitude or two orders of magnitude?

• How will new functionality be added?

• What features, if any, will be implemented in the foreseeable future?

• What will they want to get rid of in the future?

Has quality criteria

The global cloud market is divided between three companies, which occupy the majority of it. All three companies have a Well-Architected Framework, a set of rules that describes application development principles and practices:

These three documents are excellent examples of quality criteria for architecture, processes and more.

Regarding architecture, several examples can be given:

• Design applications to be easily scalable and loosely coupled to each other. This will allow their components to be updated regularly. Automatic deployment of small changes reduces the scope of possible problems and allows you to quickly rollback them if problems arise. (AWS, Operational excellence – Make frequent, small, reversible changes)

• Implement the principle of least privilege and ensure separation of duties for working with resources. Manage identity centrally and strive to eliminate dependencies on long-term static credentials. (AWS, Security – Implement a strong identity foundation)

• Use many small servers instead of one big one. This will reduce the impact of one failure on the operation of the entire system. Eliminate the single point of failure. (AWS, Reliability – Scale horizontally to increase aggregate workload availability)

• Deploying across multiple regions will allow you to reduce latency and improve customer experience at minimal cost. (AWS, Performance – Go global in minutes)

• Pay only for the resources you need and increase or decrease your consumption as needed. (AWS, Cost Optimization – Adopt a consumption model).

Some Well-Architected Framework practices also depend on architecture. For example, frequent updates are a DevOps issue, not an architecture issue, but they are not possible for some architecture solutions.

I will expand on this topic in more detail.

If releases are made frequently, several times a day, then usually the system cannot be stopped during the update – it must be updated unnoticed by the user. This can be achieved using update strategies (Deployment strategies, AWS Elastic Beanstalk deployment strategies) blue/green, rolling, canary deployment and some others. These strategies deploy the new version seamlessly, but require backward compatibility so that both the new and old versions can run simultaneously.

If a relational database is used, and it is used only for storage, then any operation that breaks backward compatibility can be represented as a set of operations, each of which does not break compatibility, and migrate in several stages. For example, instead of renaming a column, you can create a new one and then delete the old one.

If the architecture involves complex logic in the database, then a seamless update can be given up – maintaining backward compatibility will be more expensive than the changes for which the update takes place.

Thus, the architecture can influence how we update, monitor the system, its security, and so on.

Epilogue

Architectural decisions are key to design, development and operation. They determine not only the structure and behavior of the system, but also affect its scalability, flexibility and security. The relationship between architecture and development practices such as DevOps highlights the importance of designing and maintaining architecture well throughout its lifecycle.