"OMO. What are those? I barely understand what you mean by what a system is, talk more of the term architecture."
Alright alright. Before I go into introducing what system architecture and design are, let's go down to what an actual system is.
A system is a set or collection of hardware and software operating in a computer. See? Not that hard.
An architecture is a family of CPUs sharing a common instruction, bla bla bla. Let me break that down into something you'd understand. An architecture is the structure and design of a system.
And what is a design, in terms of computing? Err, well... A plan with more or less detail for the structure and functions of a system. Do you understand now? System architecture is the conceptual model that defines the behaviour, structure, and views of a system.
Systems are a class of software that provides foundational services and automation. Architecture can be planned upfront or emerge over time. It includes elements such as services, layers, components, relationships, technologies, standards, principles, conventions, and constraints.
Architecture can be evaluated based on business objectives in areas such as cost, functionality, reliability, maintainability and operability. In other words, a poor architecture can be costly, unreliable and difficult to maintain, operate, change and extend.
Factors Every Developer Must Consider When Designing a System
Now that you understand what system architecture is, take a look at several pivotal factors to keep in mind while designing the system.
- The number of concurrent users session, operations, transactions, and operations it can support
- The utilization of resources, such as memory, Thread, CPU, etc
- The time consumed per action, like getting information from the server
- The system's availability at any given time
- The impact of a server, resources, or service going down
- The cost and time consumption for the system's development and maintenance
- Whether the system is capable of handling a huge amount of data
- What are the scalability requirement for the system
- What's the throughput requirement i.e, the number of requests per second
Four Examples of System Architecture
A basic approach to architecture is to separate work into components. These may be designed to be reusable.
Components also serve to reduce extremely complex problems into small manageable problems. The difference between a costly, unstable, low-performance system and a fast, cheap and reliable system often comes down to how well it has been architected into components.
It is common to separate components into layers. Components in different layers are loosely coupled such that they hide their implementation behind an interface. This allows for complexity reduction and can reduce the cost of future changes.
For example, if a business layer knows nothing of how data is stored then you can change your database without any changes to your business layer.
A service is a piece of functionality that can be separately deployed and managed. Services are loosely coupled such that you can rework a service without impacting the rest of the architecture.
As services are separated and deployed, they allow for extreme scalability and reliability. Services can also cut your computing costs as they allow large systems to be deployed to many instances of inexpensive hardware.
When you scale up a system's hardware capacity, you want that the workload scales up too. If you double the hardware capacity of your system, you'd like your system to be able to handle twice the workload too. This situation is known as "linear scalability".
Linear Scalability is often not the case though. Very often there is an overhead associated with scaling up, which means that when you double your hardware capacity, your system can handle less than twice the workload. The extra workload on your system can handle when you scale up your hardware capacity is your system's scalability factor. The scalability factor may vary depending on what part of your system you scale up.
Vertical and Horizontal Scalability
There are primarily two ways to scale up a system: Vertical and Horizontal scaling.
- Vertical scaling means that you scale up the system by deploying the software on a computer with a higher capacity than the computer it is currently deployed on. The new computer has a faster CPU, more memory, faster and larger hard disk, etc than the current.
- Horizontal scaling means that you scale up the system by adding more computers with your software deployed. The added computers typically have about the same capacity as the current, or whatever capacity you would get for the same money at the time of purchase.
The easiest way to scale up your software from a developer perspective is vertical scalability. You just deploy on a bigger machine, and the software performs better.
However, once you get past standard hardware requirements, buying faster CPUs, bigger and faster RAM modules, bigger and faster hard disks, faster and bigger motherboards etc. gets really, really expensive compared to the extra performance you get. Also, if you add more CPUs to a computer, and your software is not explicitly implemented to take advantage of them, you will not get any increased performance out of the extra CPUs.
Scaling horizontally is not as easily seen from a software developer's perspective. To make your software take advantage of multiple computers (or even multiple CPUs within the same computer), your software needs to be able to parallelize its tasks. The better your software is at parallelizing its tasks, the better your software scales horizontally.
A scalable system can handle rapid changes to workloads and user demands. Scalability is the measure of how well that system responds to changes by adding or removing resources to meet demands.
The architecture is the hardware, software, technology and best practices used to build the networks, applications, processes, and services that make up your entire system.
Your system, which includes the architecture, services, products, and everything that defines your brand is considered scalable when:
- It can add resources and scale up to seamlessly handle increased customer demand and larger workloads.
- It can easily and seamlessly remove resources when demand and workloads decrease.
The idea is to build a system that can adjust capacity to meet constantly changing demands. The system needs to be highly accessible, and it needs to be available to all of your computers whenever and wherever they need it.
If you appreciate what we do here on DigitalStade,
consider sending us an appreciation token;