Distributed Architecture

The Distributed software architecture is growing rapidly by facing the new complexities in its nature , in early 1994 the distributed software by MIT was totally basic in comparison with today’s distributed architecture.

A Distributed Architecture consists of many challenges that was talked in my previous articles on Microservice , But there are always some Architectural challenges when we talk about distributed systems, they are aware of microservice challenges.

A Distributed Architecture Challenges focus on

1. Reliability : The system shall be reliable and does not have any impact in the whole system
2. Consistency and Robustness : Has a consistent behavior and be capable to treat a large number of demands
3. Scalability : be able to be scaled by increase of charge

1- Reliability : the reliability of communication describes the trust on the system in which the transactions and messaging act, with a one at least concept, if part of the system goes down the whole system shall continue working till the damaged component get back working, in this category the solutions are exposed by various Cloud providers as Microsoft Azure and Amazon Web Services, you trust fully the system and focus on business boundaries, The Azure Queue service , Service Bus and Amazon Kinesis, SQS are some solutions involved and fully tested by the biggest companies as Airbnb , Accord Hotel , Coca cola and etc..

Ajouter une description

2- Consistency and robustness : it describes the consistent and robustness nature of a distributed system in which the whole system becomes consistent by publishing the Events , Messages and Component’s Communication via these channels, the whole system keeps working and the failed components get recovered automatically also the System must be capable to support high charge of demands as the peak of system takes place in some hourly fashion per day or daily per week, the system shall has an architecture powerful enough or elastic enough, by the terms the power means your system has an architecture based on the peak times so in the other situations this configuration is wasted and unused , the elasticity term consider adding the power and increment the capacity of the system as needed and it keep the costs useful , the cloud provider introduced some sort of solutions and services for these kind of architectures but the architectural design varies based on the needs , you can optimize your capacity usage , or make the capacity elastic. there are different solutions to achieve this level of consistency and all based on the component nature, there are Some categories as Storage , Data Storage , Infrastructure and communication.

• Storage : The storage shall be distributed over multiple Locations and geography Locations and by using Replication, the system get consistent over any storage device failures
• Data Storage : The Data are in databases and these databases are replicated over multiple Locations , the Read and write replications are included in the design so any failure in one replicate or Master cause a replacement of a healthy node, so the system keeps working, there are solutions as Microsoft Azure SQL which give the availability of elastic pools to extends the DTUs in a horizontal scaling principal and Amazon RDS which provides the Aurora service to have 15 multi regional read replication and one write replication side of Master Write. in any solution the synchronization between replicas are managed in an smooth manner.

Ajouter une description

• Infrastructure and Communication : it involves in any solutions to achieve more infrastructure resources and balance the consistence of architecture , the AutoScaling , LoadBalancing are some sort of Solutions to achieve consistent infrastructure.An Alternative solution for load balancing is Deferral Message based Communication which can be obtained by a Queue based architecture and the consumers treat the messages based on their capacity of treatment against Loadbalancing in which the LoadBalancer distribute the messages. There are solution as Azure AutoScale , Azure Load Balancer , Amazon Elastic Load Balancer and Amazon AutoScaling.

Ajouter une description

3- Scalability : it describes the ability to scale the system in a fast and cost efficient manner to get the required performance and capacity, as we had a look in the Consistency and Robustness part the auto scaling can helps the architecture and in the reliability the deferral pub/sub design. the goal of scalability can be described as a fully Consistent and reliable solution , the architectural design can obtain this level of trust and consistence by designing a mixed architectural design side by side of these two types of solutions.

Ajouter une description

A Distributed Architecture has some characteristics as

1. Componentized
2. Business Capable
3. Automated
4. Evolutionary.

(Componentized) In a distributed system the software is composed in one or more components called as Services, This helps us to have a service with a rich capability of business management, there is no need to follow any traversal aspect, just do the business goal, by the years this concept get wider by introducing the Microservices , a Microservice is nothing different from a service ,it’s just minimized in the term of Responsibility, it consists of a service , a team , a workflow , a system and finally a product , what are these concepts ? the term Microservice is driving the teams to be centralized on the business goal in an autonomous manner. A component has an evolutionary life cycle and a rapid production process. (Business Capable)The Boundaries are defined and have evolution by the team agreement, this definition of boundaries help the team to focus on business capabilities, the team becomes enough experienced above the boundaries so any evolution will be done enough rapid. (Automated) as the team can be fast and is responsible for it’s quality the tests are fully covered in the solution, as the tasks keeps small changes so the review will be rapid, by automating the tests the team can go one step forward by doing delivering the product in an automated manner, the failures are recovered and handled automatically without impacting the whole system and finally the infrastructure will be automated, (Evolutionary) the teams are concentrated on the product and any evolution will make the one step through the product, the Code, Dependencies , Configuration and Release will be tracked.

* Software Design Patterns

In the preceding Articles about microservices i discovered some patterns used based on problematic’s category. Here i want to explore some of GoF that will help a microservice will be optimized.

In Componentization we can use some patterns which are based on components , we can achieve the resilience of our product to act nicely with a large scale of functionality but the minimum of code modifications , consider using these patterns:

Composite : It’s helpful to help product manage the components in an hierarchical manner, so any component can be added based on a defined process schema.

Fly-Weight : The components are organized in two different states Intrinsic and Extrinsic , which led the component to be optimized based on its scale of usage.

In Business Capable section we consider using some sort of patterns which led us easily to have business evolution:

Adapter : Helps us to overcome by adding new business entities based on the existing ones , using adapter you have less modifications in all parts of you application , the old entity’s impedance will be kept.

Command : Encapsulating a client request to an object and letting the operation be undoable, by using this pattern the parameterized requests will be lead to business entities easily.

Singleton : I call it as a degradation in software automation as it’s not testable in conjunction with other parts of a system. but it’s useful sometimes.

Object Pool : Keep the system with a pool of objects which can be reusable when the system can go under high request thresholds , consider automating this pattern to switch when the system goes under memory pressure.

Chain of Responsibility : Helps the system handle operations by limiting actors handling it or allowing multiple actors handle the operation.

Bridge : Use bridge vastly to extend the business process in the whole context, by separating abstraction from implementation. it’s widely used in the today’s software but by using carefully and well formed design the business get rich and extensible.(This patterns also covers the evolutionary)

Mediator : Helps entities act and communicate without have any knowledge about dependencies identities.

In Automated Keep track of the product and it’s reliability considering :

Observer : Keep your design extensible by operational aspects so any operation can raise one or more delegated operations so notify the whole service. it’s useful to implement the Sync/Async Queue messaging in a Publish/Subscribe manner .

In Evolutionary consider using :

Iterator : using it the elements of an iterative collection can be treated without exploring their underlying context.

Strategy : Helps have the independent interchangeable algorithms.

State : Same as strategy but based on object state.

Proxy : keeps nature of internal object and its accessibility hidden from the process.