The goal of architecture is to provide the best structure to fulfill all functional and non-functional requirements, and to achieve the best results in terms of customer satisfaction with a bit of overhead to, we have to manage any future need the application may have during the release.

Decisions about selecting software architecture are about performance. An important distinction is between decisions that affect the whole software and decisions that can be made as optimization or tuning.

There is a performance architecture that focuses on the performance concerns that always persist as time changes, and an optimization time, when performance concerns fit the underlying system and its configuration (OS version, middleware version, .NET version, the database version, and so on). After a system change, the architectural vision should not change, whereas the optimization against the new system must be made to fit the requirements. When dealing with software architecture, performance concerns may change from time to time. Let's take a look at a couple of instances.

Suppose that we have a web application that serves hundreds of users, and we need to decide how to store data in single or multiple relational repositories. A simple solution is to use a single relational DB for all the data, because using an association to retrieve data from referenced tables is easy with an object-relational mapping (OR/M) and because a DBMS is fast at executing joins. We might say that this solution brings very good latency and throughput in data extraction from 100 to 10,000 users online. This is what usually happens in 2-tier architectures.

However, as time changes, things may become different because as powerful as a system may be, scaling up (with all the trouble of changing the hardware of a critical system) is not always possible. Think about when we already have the fastest system available. Splitting the data persistence on different DBMS breaks constraint-based associations between entities, but gives us great scalability over time. This is what usually happens in 3-tier architectures. Adding new modules to the whole application will also mean adding more module-oriented DBs, so the application scalability need is linear to the available persistence storage scalability.

In Chapter 1, Performance Thoughts, we talked about performance requisites and aspect maps. The two solutions have different maps. The first is winning latency while the second is winning scalability. Different performance requisites might move us away from choosing one solution or another. It depends on how far away the analyst that made the requisite has been able to see the needs of the customer.

Bear in mind that if we used the second option, the one with multiple persistence systems, the system would have performed slightly worse on latency (compared the first option) at the beginning. Further, if the web application would have scaled to 10,000 or 100,000 online users, we could have chosen the winning architecture, after all. Scaling to fulfill thousands of requests is obviously different from responding in as few milliseconds as possible. This is a choice. The architect deals with such choices all days of their life. That is the simplest truth and definition available of a software architect. This shows how difficult it is to find the right design for a system, even if we're talking about a single module, such as the relational persistence module.

Another important aspect is choosing whether to optimize the software to work in the given environment or not, and if yes, how to do it.

If we have to make a software module or tier that can operate indistinctly on a premise (on our systems) or on a cloud Infrastructure as a Service (IaaS) or a Platform as a Service (PaaS) subsystem, we must create something more system agnostic—a software module that is able to scale up and down from the premise to the cloud. Otherwise, by using idioms of specific systems such as a specific DBMS function (for instance, SQL Server File Table), we cannot ensure that such a feature is always available in all environments. A module that should execute in the same way in our virtual machine or a public cloud virtual machine without configuring nothing more than what is available in a .config file is definitely an agnostic software module. On the contrary, when the highest performance is required, by sacrificing some code reusability, we can use all dialects or idioms of any language to get the best from each one.

In this chapter, we will focus on performance architecture, while in the following chapters, we will focus on code optimization and performance instrumentation.