A Vision about Software Architecture Styles

Software Architucture or Software System Design is the only way to solve the big challanges that you are sure that an application gonna face before jumping into the coding phase .

Let’s Start with Definitions :

The design of an information environment should start with its conceptual model. Doing so gives the team a high-level understanding of the tasks people will do there, the elements and actions required for them to complete those tasks, the sequence they need to happen in, and — ultimately — the purpose of the environment. You can’t gain this understanding from sketching user interfaces; you must begin at a higher level .

Humanity learns from Mistakes

Example :

if you are thinking about building your first project and you already start working . the major part of developers they gonna just start coding . it is the default mode in our brains . after a while you gonna find your self correcting things multiple times per day . you are in :

while(“Software Developement is a process not just coding” NOT IN yourMind){ keepWorkingHardNotSmart() } .

Once You Understand that you gonna start searching about the process then you gonna find “the microservices” and how they gonna make your application great and scalable and bla bla bal . you gonna find your self unable to work because you find your self between two probalities too many microservices or one big microservice . at this moment we become the same we think in the same way . let’s correct this together .

the prefect system is just a dream . just in your mind .

The Dream Characteristic of any System :

from the beging of the software development . architcts always try to get the balance of those characterstic in thier softwares from tools like Message Brokers or DataBases into End-User Product like Social Media Platforms or Search Engines or Even in the B2B Products .

Those concerns are the basic . there’s no system that can have all of them . the perfect system is the one that have a specific percent of every concern based on the Domaine Driven . I love the DDD . let’s explore those concerns :

1-Reliability :

is the probability that a system performs correctly during a specific time duration. During this correct operation: No repair is required or performed. The system adequately follows the defined performance specifications .also means .is the ability of a program to tolerate faults.

There are three different kind of faults:

1. Hardware faults : if your Servers Goes Down . the Data Center where your system deployed get Destroyed .
2. Software faults : are code-related errors.example if your system depend on a third party API . and the API is not available any more .
3. Human faults : when you make it easier for developers and clients to do the wrong thing and harder to do the right thing . example developers accidentally setting up the wrong environment variable values or users interacting with your software in a way that’s not intended .

design a fault-tolerant system is a typically quite expensive to maintain: it will involve running active-active copies of data all the time with the necessary automation to fail over when encountered with any components of a storage system failing and causing downtime. And this failover will be non-disruptive in such a way that applications and data access are not impacted at all the business continues to function as expected

No system can have the 100% Reliability .

2-Scalability :

when it comes to Scalability it comes to the load . the load is the operations that parts of your system or you system do in a specific amount of time without affecting performance a.k.a the processing time . example the number of writes in a database per minute , the number of user that your system can handle at the same time , or the number of the request that you are reciving per second . When your startup is growing it means that you have more users .

The two main ways to scale are:

• Vertical scale : increasing your machines capacity by upgrading the hardware , restarting a machine take time less Reliability
• Horizontal scale : is the also a buzzWord those days . it means adding more machines instead of giving more power to one machine . Horizontal scale is harder to execute, but overall is cheaper than vertical scaling .

Rule : we always try to reduce the cost scaling what ever the way .

3-Maintainability :

it is the abilty of next and the current developers to maintain “solve the bugs and add new features ” . The majority cost of a software is in ongoing maintenance, not in its initial development. It is very, very important to write a maintainable software.

A maintainable software must adhere to these 3 principles:

1. Operable : continuous security patches .
2. Simple : As your software size increases, its complexity also increases. A highly complex software slows down the development time, thus lowering maintainability and increasing maintenance cost.
3. Evolvable : in world where everything change your system should be able to extend and should have less dependencies . all developers remebre what happend with Fake.js .

4- High Secure :

in world where data travel from a place to place . havig a secure system that control the access to the system resources is the top proirity for all systems .

5-Durability :

Durability refers to the continued persistence of data. Businesses will have long-term data retention goals. This is achieved by improving durability of the data and the storage infrastructure preserving it. Especially in the context of object storage where data is archived and preserved for longer terms, it is important to achieve higher durability. A high level of durability ensures that the data does not suffer from bit rot, degradation, or any form of corruption or data loss.

The Software Design Styles :

Basically there’s tree main Styles and they Are :

1-Monolith :

Is the traditional unified model for the design of a software program it is the first thing that comes to people who start development without a knowldge in system design while building a software . one component where we can process everything .

Adavantges :

• Simplicity of development : The monolithic approach is a standard way of building applications. No additional knowledge is required. All source code is located in one place which can be quickly understood.
• Simplicity of debugging : The debugging process is simple because all code is located in one place. You can easily follow the flow of a request and find an issue.
• Simplicity of testing. You test only one service without any dependencies. Everything is usually clear.
• Simplicity of deployment. Only one deployment unit (e.g. jar file) should be deployed. There are no dependencies. In cases when UI is packaged with backend code you do not have any breaking changes. Everything exists and changes in one place.
• Simplicity of application evolution. Basically, the application does not have any limitations from business logic perspective. If you need some data for new feature, it is already there.
• Cross-cutting concerns and customizations are used only once. You should take care about cross-cutting oncerns only once. For instance, security, logging, exception handling, monitoring, choosing and setting up tomcat parameters, setup of data source connection pool, etc.
• Simplicity in onboarding new team members. The source code is located in one place. New team members can easily debug some functional flow and to get familiar with the application.
• Low cost on early stages of the application. All source code is located in one place, packaged in a sinlge deployment unit and deployed. What can be easier? There is no overhead neither in infrastructure cost nor development cost.

Because of these advantages, monolithic architecture is usually used in the early stages of application development. The reasons for that are the next ones:

• The main function of the application is to be profitable. As a result, it is important to quickly implement some POC (Proof of Concept) solution to verify the application in a real world. Also, it is important to bring customers to the system. Improvemets can be implemented in the future.
• The requirements are usually unclear at early stages of development. It is hard to create meaningful architecture when the requirements are unclear. Real customers can define the business needs after some of the functionality already works.

DisAdvantges :

• Slow speed of development. The simplest disadvantage relates to CI/CD pipeline. Imagine the monolith that contains a lot of services. Each service in this monolith is covered with tests that are executed for each Pull Request. Even for a small change in a source code you should wait a lot of time (e.g. 1 hour) for your pipeline to succeed. And what happens when the pipeline fails for some reason? You wait again. All services are located in a single place. The size of the team is big. What happens when your colleague merges their changes? You rebase/merge and wait again.
• High code coupling. Of course you can keep a clear service structure inside your repository. However, as practice shows, eventually you will end up with a spagetti code in at least a few places. As a result, the system becomes harder to understand especially for new team members.
• Code ownership cannot be used. The system is growing. The logical step is to split responsibilities between several teams. E.g. one team can work on Flight Service, another — for Billing Service. However, there are no boundaries between those services. One team can affect another.
• Testing becomes harder. Even a small change can negatively affect the system. As a result, the regression for full monolithic service is required.
• Performance issues. Potentially, you can scale the whole monolithic service in cases of performance issues. But what to do with the database? The single database is used for all services. You can start to optimize your database queries or use read replicas. However, there is a limit to this type of optimizations.
• The cost of infrastructure. In cases of performance issues, you should scale the whole monolithic service. It brings additional cost for application operability.
• Legacy technologies. Imagine that you have the application written on Java 8. How much time is it required to migrate the whole monolith with multiple services underneath to Java 11? What to do with the tasks that are required to bring new functionality? It can be the case that the application will never be migrated.
• Lack of flexibility. Using Monolithic Architecture you are tight to the technologies that are used inside your monolith. You cannot use other tools even if they are better for the problem at hand.
• Problems with deployment. Even a small change requires redeployment of the whole monolith.

Use Cases :

1. Your team is small and at a founding stage. A starting team of about two to five members will find a monolith architecture ideal to focus on.
2. You’re building a proof of concept or MVP . New products will pivot and evolve as you figure out what will be useful to your users. For this, a monolith is perfect as it allows for rapid product iteration . this the main case for me . As martin folwer use to say : “ Almost all the successful microservice stories have started with a monolith that got too big and was broken up ” the link : to his article .
3. Foreseeable scale and complexity. When your application doesn’t require advanced scalability and the complexity is manageable, then a monolith architecture is the best road to go down.

2-SOA :

an important stage in the evolution of application development and integration.

Service-oriented architecture (SOA) is an architectural pattern as well as a collection of design principles that support loose coupling and reusability of different components in a distributed system.

Each service in an SOA embodies the code and data required to execute a complete, discrete business function (e.g. checking a customer’s credit, calculating a monthly loan payment, or processing a mortgage application). The service interfaces provide loose coupling, meaning they can be called with little or no knowledge of how the service is implemented underneath, reducing the dependencies between applications

Adavantges :

Maintenance is easy: Editing and updating any service is easy. You don’t need to update your system. Service is maintained by a 3rd party and any change in that service will not affect your system. In most cases old API work as it is working before.

Same directory structure: Services have the same directory structure so that consumers can access the service data from the same directory every time. If any service has changed its location then also directory remains same. This is very helpful for consumers.

Prevent reinventing the wheel: The company can use pre-build service and don’t have to rebuild the same functionality from scratch. This will also increase the productivity of the company. Now the company can only focus on its own website or software without worrying about external component integration.

Scalable: If any service getting many users then it can be easily scalable by attaching more servers. This will make service available all time to the users.

Reliable: Services are usually small size as compared to the full-fledged application. So it is easier to debug and test the independent services.

Quality of code improved: As services run independent of our system and they have their own style of code so our code is prevented from redundancy. Also, our code becomes error free.

Independent of other services: Services are independent of each other. So services can be used by multiple applications at the same time.

Platform independence: Services communicate with other applications through common language which means it is independent of the platform on which application is running. Services can provide API in different languages e.g. PHP, JavaScript etc.

DisAdvantges :

Extra overload: In SOA, all inputs are validated before it is sent to the service. If you are using multiple services then it will overload your system with extra computation.

High cost: SOA is costly in terms of human resource, development, and technology.

High bandwidth server: As some web service sends and receives messages and information frequently so it easily reaches a million requests per day. So it involves a high-speed server with a lot of data bandwidth to run a web service.

Use Cases :

SOA majorly used for B2B applications a.k.a enterprise scope .

link to learn more .

3-MicroServices :

it is one of the most trendly words in since 2005 the first day when Fred George began working on prototype architectures based on what he called the “Baysean Principles” named after Jeff Bay. Peter Rodgers introduced the term “Micro-Web-Services” during a presentation at the Web Services Edge conference . from this day it becomes a trend in software development word . It is really one of the most effiecient inventions , it is a game changer in our vision into the software .

MicroServices : is an architectural style that structures an application as a collection of services that are

• Highly maintainable and testable : making changes in the system or adding features is not complicated .
• Loosely coupled : if one goes down other can works , the whole system can work .
• Independently deployable : they can be deployed in diffrent envirements .
• Organized around business capabilities :
• Owned by a small team : every microservice can be developed independly by a small team with total freedome of the language or the framework .

Adavantges :

1-Lower Costs & Increased Efficiency :

2-Increased Agility and Scalability :

3-Easier Maintenance and Updating

4-Faster Time to Market

5-Improved Fault Tolerance

6-Increased Modularity

7-Deployed Independently .

DisAdvantges :

1-Higher Complexity .

2-Increased Network Traffic “cost more money”.

3-Increased Development Time .

4-Limited Reuse of Code .

5-Dependency on DevOps .

6-Difficult in Global Testing .

7-Insecure communication .

8-Routing adds complexity, and fail points .

9- Hard to trace or debugging .

Use Cases :

the microservices are the best choice to solve the problem of your monlith application when it is getting bigger . and also to help you add more features “microServices” easily .

link to read more .

End:

now we have a basic view and we understand that there’s no style better than others . every architecture style have his own power and weakness at the same time and every style is for specific use cases .

Thanks for reading . flow me on LinkedIn .