Every structure must have a foundation, and every piece of software must have an architecture that defines what it is and how it serves users.
Mark Richards, a software architect in Boston, has been thinking about how software should function for more than 30 years. Software Architecture Patterns, his free book, outlines five architectures that appear frequently in software systems.
Richards’ five core architectures have been condensed into a fast reference to their strengths and limitations, as well as recommended application cases. In many circumstances, a single architecture is the best option for bringing your code together. Others may find it more practical to optimize each portion of code using the best architecture available.
Layered (n-tier) architecture
This strategy is a logical way to break down large tasks into smaller, more manageable chunks that can be allocated to other teams. Some believe it to be the most common type of architecture, yet this is a self-fulfilling prophecy. Many of the most popular and best software frameworks—React, Java EE, Drupal, and Express—were designed with this structure in mind, and as a result, many of the applications produced with them have a layered architecture by default.
The code is structured in such a way that data enters the top layer and works its way down to the bottom layer, which is usually a database. Each layer has a specific job to do along the process, such as validating the data for the correctness or reformatting the numbers to maintain consistency. It’s not uncommon for multiple programmers to work on different layers individually.
Model-View-Controller (MVC) is the typical software development approach offered by most prominent web frameworks, as shown in the diagram below. It’s evident that the architecture is layered.
The model layer sits just above the database and often contains business logic as well as information about the database’s data kinds. The view layer is at the top, and it’s usually made up of CSS, JavaScript, and HTML with dynamic embedded code. The controller is in the middle, with numerous rules and techniques for altering data as it moves between the display and the model.
The major benefit of a layered architecture is that it separates issues, allowing each layer to focus only on its function. As a result,
- Maintainable
- Testable
- Easy to assign separate “roles”
- Easy to update and enhance layers separately
- Well suited to some data science and artificial intelligence applications because the various layers clean and prepare the data before the final analysis
Layered architectures with isolated layers are less likely to be influenced by changes in other layers, making refactoring easier. Additional open layers, such as a service layer, can be used to access shared services exclusively in the business layer but can also be bypassed for speed.
The architect’s largest issue is dividing up the responsibilities and designing various levels. The layers will be straightforward to divide and allocate to different programmers once the requirements fit the pattern effectively.
Challenges of this approach
- If source code is disorganized and modules don’t have clear roles or relationships, it might become a “huge ball of mud.”
- The “sinkhole anti-pattern,” as some developers refer to it, can cause code to become slow. Without utilizing any logic, much of the code can be devoted to passing data across layers.
- Layer isolation, which is a key purpose of this architecture, can make it difficult to comprehend the architecture without knowing every module.
- Coders can skip over layers in order to generate tight coupling and a logical jumble with complex interdependencies. Then it may begin to resemble the microkernel approach described further down.
- Because monolithic deployment is frequently necessary, even minor changes may necessitate a complete re-deployment of the application.
This architecture is best for:
- New apps that must be built in a timely manner
- Business or enterprise applications that must replicate typical IT organizations and processes
- Teams made up of unskilled developers who are unfamiliar with different architectures
- Applications that must adhere to tight maintainability and testability guidelines
- Data pipelines are written in languages like R and Python for data science.
Event-driven architecture
For many programs, waiting is a huge part of existence. This is especially true for computers that interact directly with humans, although it also occurs frequently in domains like networks. These machines spend most of their time waiting for work to arrive.
By constructing a central unit that accepts all data and then delegating it to various modules that handle each type, the event-driven architecture makes developing software for this purpose easier. This handoff is said to cause an “event,” which is delegated to the code for that type.
Programming a web page with JavaScript is one of the most common examples of this architecture. The browser showing the web page does most of the work, leaving the programmer with only short blocks of code to react to events like mouse clicks or inputs.
All of the input is orchestrated by the browser, which ensures that only the appropriate code sees the appropriate events. In the browser, there are many distinct types of events, but the modules only interact with the ones that concern them. This is in contrast to a layered design, in which all data is normally passed through all layers.
- Event-driven architectures, in general:
- Are adaptive to a variety of complicated and often turbulent circumstances
- It’s simple to scale
- When new event kinds occur, they’re simple to add.
- Are excellent for some of the new cloud models that deploy only when triggered functions.
Challenges to this approach
When modules interact with one another, testing becomes more difficult. Individual modules can be tested independently, but only a fully functional system can test the relationships between them.
It might be challenging to structure error handling, especially when multiple modules must handle the same events.
The central unit must include a backup plan in case one of the modules fails.
Processing speed can be slowed by messaging overhead, particularly if the central unit must buffer messages that arrive in bursts.
When the events have extremely varied needs, developing a system-wide data structure for them can be difficult.
Because the modules are so decoupled and independent, maintaining a transaction-based mechanism for consistency is difficult.
Event-driven is best for:
- Asynchronous data flow that occurs only once in a while in asynchronous systems
- Individual data blocks communicate with only a handful of the numerous modules in applications like this.
- User interfaces and other JavaScript-based web apps
- Applications that may or may not run frequently or at all. Because they only bill when an event initiates a function, the newer cloud functions-as-a-service models can save a lot of money. The rest of the time, they are free to use.
Microkernel, or plugin, architecture
Depending on the job, some apps have a core set of functions or features that are utilized repeatedly in different combinations. For example, Eclipse, an integrated development environment, will open files, annotate them, modify them, and initiate background tasks. All of these tasks are carried out by the tool using Java code, which is subsequently compiled and launched when a button is pressed.
The microkernel contains the basic procedures for viewing and modifying files in this scenario. The Java compiler is merely an add-on component that supports the microkernel’s core functionality. Eclipse has been modified by other programmers to allow them to write code in other languages using different compilers. Many don’t utilize the Java compiler, but they all use the same core techniques for editing and annotating files.
Plugins are the additional features that are added on top. Instead, many people refer to this expandable method as a plugin architecture.
Richards elucidates this with the following example from the insurance industry: “Claims processing is inherently complicated, but the stages themselves are not. All of the restrictions make it complicated.”
The answer is to delegate some basic functions to the microkernel, such as requesting a name or checking on payment status. These can be independently tested, and then the various business units can create plugins for the various types of claims by combining the rules with calls to the kernel’s fundamental functions.
Many modern operating systems, including Linux, have a kernel-style design, albeit the number of features in the kernel (the so-called size) is a point of contention. Some people like the smaller microkernels, while others prefer the larger microkernels, which are more sophisticated but have a comparable design.
Challenges to this approach
- It’s typically a work of art to figure out what belongs in the microkernel. It should be used to store frequently used code.
- The microkernel must be informed that the plugin is installed and ready to use, hence the plugins must include a significant amount of handshaking code.
- When a large number of plugins rely on the microkernel, changing it can be difficult, if not impossible. The only way to fix it is to change the plugins as well.
- It’s tough to choose the correct granularity for the kernel functions in advance, but it’s nearly hard to adjust later in the game.
The microkernel is best for:
- People employ a wide range of tools.
- Basic routines and higher-order rules are clearly separated in applications with a clear distinction.
- Applications with a set of fixed core procedures and a dynamic collection of rules that must be updated on a regular basis
Microservices architecture
Software is similar to a kitten in that it is cute and entertaining when it is young, but as it becomes older, it becomes difficult to control and resistant to modify. The microservices architecture was created to help developers avoid raising bulky, monolithic, and inflexible children.
Rather than creating a single large program, the concept is to divide the workload into many smaller ones and then design a little program that sits on top of them all and integrates the data from all of them.
“If you look at Netflix’s UI on your iPad, everything on that interface comes from a different source,” Richards added. Separate services track and serve up the sidebars and menus including ratings for the films you’ve viewed, recommendations, the what’s-up-next list, and accounting information.
It’s as if Netflix—or any other microservice—is a collection of dozens of smaller websites masquerading as one.
This strategy is comparable to event-driven and microkernel approaches; however, it’s mostly employed when the activities can be easily divided. Various jobs may require different amounts of processing and use in many circumstances.
On Friday and Saturday nights, the servers that provide Netflix’s content are pushed much harder, so they must be prepared to scale up. The servers that track DVD returns, on the other hand, work primarily during the week, shortly after the day’s mail is delivered.
The Netflix cloud can scale these up and down separately as demand changes by establishing them as different services.
Challenges to the microservices approach
- The services must be mostly self-contained, or the cloud will become unbalanced as a result of contact.
- Not all applications contain tasks that can be easily broken down into smaller pieces.
- Some AI and data processing tasks require a comprehensive approach that cannot be broken down into smaller components.
- When jobs are distributed over multiple microservices, performance can suffer. The costs of communication can be substantial.
- Users may become confused if there are too many microservices, as certain portions of the web page may arrive considerably later than others.
This approach is best for:
- Websites with minor elements
- Web applications for Node applications like React or Vue created with server-side JavaScript
- Data centers for businesses with clearly defined boundaries
- New enterprises and digital applications are being developed at a breakneck pace.
- Development teams that are dispersed over the world
Space-based architecture
The database is at the heart of many applications, and they work well as long as the database is up and functioning. However, as traffic increases and the database becomes behind because it is producing a transaction log, the entire website crashes.
Multiple servers that can operate as backups are added to a space-based design to avoid this. It divides the presentation and data storage tasks and distributes them over different servers. The data, like the responsibility for answering calls, is dispersed across the nodes.
For this design, some architects use the more amorphous term “cloud architecture.” The term “space-based” refers to the users’ “tuple space,” which is divided up to divide the work amongst the nodes.
Richards explained, “It’s all in-memory objects.” “By eliminating the database, the space-based design supports items that have unforeseen spikes.”
Many processes become significantly faster when data is stored in RAM, and spreading out storage with processing can simplify many simple chores.
Challenges with the space-based approach
- With RAM databases, transactional support is more challenging.
- It can be difficult to generate enough load to test the system, however individual nodes can be checked independently.
- It’s tough to gain the skill needed to cache data for speed without ruining numerous copies.
- Some sorts of analysis may become more difficult as a result of the distributed design. Computations that must be dispersed across the entire dataset, such as finding an average or doing statistical analysis, must be broken down into sub-jobs, distributed across all nodes, and then aggregated once completed.
This architecture is best for:
- Click streams and user logs are examples of high-volume data.
- Workloads have well-defined portions that require varying amounts of computing; one area of the tuple space may require powerful machines with enormous RAM allocations, while another may require much less.
- Low-value data can be lost without major implications on a regular basis—in other words, not bank transactions.
- Social media sites
Mix and match
Richards outlined his top five ideas, and there’s a strong chance they’ll meet your requirements. In other circumstances, a combination of two—or even three—solutions may be the greatest option.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html