Tuesday, October 24, 2017

Everything important for solution architect

Software Architect Pattern Book by and 


Mark Richard


1- there is no rule around the number of layers, some applications might have business and persistence in the same layer.
2- layers marked as closed means that you cannot bypass them, e.g. presentation layer cannot access the database directly 
3- you might add new layer like this

the Service layer was added as open which means the business layer can bypass it.

4- a good example of the layered architecture can be found below 

customer screen will receive getCustomerInformation request which will return the customer and its orders,
the customer screen will pass the request to customer delegate which has the logic the determine which component in the business layer should be called, in this case the customer delegate will pass the request to Customer Object
the business layer knows that it has to use the customer dao and order dao and then aggregate the result and send them back
the customer dao and order dao will fire sql statement to fetch the information from the db

5- be careful of the SINKHOLE ANTI-PATTERN: in the layered pattern you might find that a request is passing from presentation layer to databases layer without anything happening in these layers, the business layer is not doing anything just passing, this is wrong, you should follow the 80-20 rule in this case, if you have more than 20% of your operations that doesn't need any processing from layers you should start thinking of opening some layers

6- in your documentation you should state clearly which layers are open and why

Architecture Agility (LOW): the architecture is more monolothic in nature, even when you split to layers and component, it is not easy to react to constant environment changing

Ease of Deployment (LOW): sure, it depends how you build your application, but in general a change to one component might need redeployment for the full stack (or large part of it), usually you need to schedual that, not good for CD

Testability (HIGH): very good, as component belongs to a specific layer and you can mock other layers.

Performance (LOW): because of the multi layer nature, performance is very low

Scalability (LOW): scalability is difficult in this architecture because of the monlothic nature, usually you scale by copying the entire stack

Ease of development (HIGH): usually it is high, as it is well known, you can seperate your team based on the skills and layers, and here you should know Conway’s law which says that organizations are constrained to produce designs which are copies of the communication structures of these organizations.



It has 2 styles, mediator topology and broker topoloogy

1- mediator topology looks like this

the event comes to a queue, the mediator (or orchestrator) will pick the event from the queue, the mediator knows the steps that should be executed to serve the event.

the mediator will put event in another channels to get picked up by event processors.

mediator could be implemented using Apache Camel, Spring Integration, Apache ODE or any BPEL ...

sure, the mediator might publish to queue or topic depends on the event.


mediator receives Relocation Request,
it will get processed by adding request to get picked up by processors.

in the broker topology, there is no mediator, the routing logic is in the event processor, which means, after the processor process the event, it will inform the next step

the same Relocation example will look like this

3- BE CAREFUL OF TRANSACTIONAL UNITS: you cannot perform transactions easily in this architecture because of its asynchronous distributed nature,

Architecture Agility (HIGH): the event processor are single purpose component, changing them is easy

Ease of Deployment (HIGH): event processors are decoupled, very easy to deploy

Testability (LOW): testing is little difficult, the architecture is highly asynchronous, you need special code to track where the event is

Performance (HIGH): even though it is asynchronous, however the performance is high in this architecture as you are performing parallel asynchronous tasks

Scalability (HIGH): each event processor can be scaled independently

Ease of development (low): asynchronous development is difficult.



1- you have a core system and you add plugin to this system, example eclipse or your web browser.

in case of business applications, product based applications are very good example. Insurance companies, for example, could fit under this category, you have a core claim system, but because you have different insurance products, you can build these products as plugins and put them in the system.

you can see down a Claims Processing core system and Different US states plugins as each state has different logic.

Architecture Agility (HIGH): plugins are standalone, you can change them easily

Ease of Deployment (HIGH): plugins are standalone, you can deploy them independently

Testability (HIGH): you can test plugins independently

Performance (HIGH): usually because you can remove the plugins that dont perform.

Scalability (LOW): in general it is low, you can scale on plugin level

Ease of development (LOW): not easy to build such a system


CHAPTER 4- Microservices Architecture Pattern

the micro service architecture might look like this

the client send a request to an api, the api will communicate with the services

the second style might look like this

here you would have a traditional web based application (or any kind of application) with an interface, (e.g. angular application) and this application communicate with the services

the third style might look like this

this one has additional layer which is a message borker, NO ORCHESTRATION IN THIS LAYER, this is simply for queuing, monitoring ..

2- you should avoid ORCHESTRATION and Inter-service communication, if you have a lot STOP and move to SOA
3- you can solve inter - service communication by using shared db
4- you can solve inter - service communication by copying one service functionality to another
5- if you find that you need to orchestrate or alot of inter -service communication, then micro service might not be a good choice

Architecture Agility (HIGH): independent services
Ease of Deployment (LOW): independent services

Testability (HIGH): independent services

Performance (LOW): i dont know why but the author consider it as low because of the distributed nature

Scalability (HIGH): independent services

Ease of development (HIGH): independent services


Space based architecture is about scalability, (check below, the request comes to the virtualised middle ware)

scalability is achieved by removing the central database constraint and using replicated in-memory data grids instead. Application data is kept in-memory and replicated among all the active processing units, as you can see there is no centralize db, each processing unit has its own db

the processing unit looks like this

as you can see there is in-memory data grid, and the replication engine to replicate with other processing unit

The Virtual middleware is the key in this architecture and has the following elements:
Messaging Grid: When a request comes into the virtualized-middleware component, the messaging-grid component determines which active processing components are available to receive the request and forwards the request to one of those processing units

Data Grid:The data grid interacts with the data-replication engine in each processing unit to manage the data replication between processing units when data updates occur

Processing Grid: it is the orchestrator, If a request comes in that requires coordination between processing unit types (e.g., an order processing unit and a customer processing unit), it is the processing grid that mediates and orchestrates the request between those two processing units.

Deployment Manager: manages the dynamic startup and shutdown of processing units based on load conditions


 Service Oriented Architecture

Business services: this is high level services, like process claim, execute trade, these services are owned by business users
Enterprise Service: high level owned by the architect, like create customer, calculate quote
Application Services: this is owned by developers, they are fine grained, like add driver, add vhichle.
Infrastructure Services: here we have non business functianlity, like writeToLOG, SSO, checkCredintials
Message Bus: here you do the orchestration and choreography

Finally the comparison


Microservices vs. Service-Oriented Architecture by Mark Richards

SOA and micro-services shares the same characteristics and difficulties, some of these difficulties

1- Service Contract: the contract might change, how can you handle this. You have Service-based contract and Consumer-based contract.
you need to use contract versioning.
very important to find a way to inform your consumers about your changes.

2- Service Availability: how to set time out for a service, is it based on load testing, but maybe you come with wrong numbers, and lets say you set it to 8 seconds, it means the consumer will wait for 8 seconds before it knows that the service is down.
some solutions are using CIRCUIT BREAKER PATTERS.
dont use global timeout for a service, make it smarter and write some logic to update this timeout all the time

3- Security: where should you implement Authentication and Authorization, you can have another service that is responsible for Authentication and authorization. or make a service for Authentication and pot the authorization in the service.

4- Transaction: you should accept that ACID is difficult in distributed environment like the service environment; here we have BASE, basically available Soft state, Eventually Consistant.
If you want ACID, think of moving all the ACID parts to one service.

SOA VS Micro-services Characteristics

1- Service Taxonomy: How services are classified in architecture
in micro-services, very easy taxonomy, the types are Functional Services and non-functional services.
usually non-functional services are internal services and not exposed to the public.

in SOA we have a larage taxonomy,

Business Services: High level, coarse grained services, these are the Enterprise level services, you can define these services by using the question "ARE YOU IN BUSINESS OFF", for example consider the ProcessTrade and InsertCustomer services. Saying “Are we in the business of processing trades” makes it clear that ProcessTrade is a good business service candidate, whereas “Are we in the business of inserting customers” is a clear indication that the InsertCustomer service is not a good abstract business service candidate

business services are VERY ABSTRACT, they are devoid of any implementation or protocol, and they usually only include the name of the service, the expected input, and the expected output. You might add some orchestration in this level.

Business services are typically represented through either XML, Web Services Definition Language (WSDL), or Business Process Execution Language (BPEL).

Enterprise Services: coarse-grained services that implements the functionality of business services. Enterprise services can have a one-to-one or one-to-many relationship with a business service.
The middleware is usually the bridge between business services and enterprise services,
Enterprise Services are generally shared across the organization
examples:  CheckTradeCompliance, CreateCustomer, ValidateOrder, and GetInventory

Application Services: fine grained services, AND APPLICATION SPECIFIC, For example, an auto-quoting application as part of a large insurance company might expose services to calculate auto insurance rates—something that is specific to that application and not to the enterprise. Application services may be called directly through a dedicated user interface, or through an enterprise service. Some examples of an application service might be AddDriver, AddVehicle, and CalculateAutoQuote.

Infrastructure Services: non functional services.

VERY IMPORTANT: as an architect you can choose to use the standard service types or completely discard them and create your own classification scheme. Regardless of which you do, the important thing is to make sure you have a well-defined and well-documented service taxonomy for your architecture.

2- Service Ownership and Coordination
In microservices, the owner is the application dev team.

in SOA, you have different ouners

as you can see, in micro-services, you have minimal communication, in SOA, if you want to add one services you need to communicate with many teams.

3- Service Granularity
microservices are small, fine-grained services, even more, they are generally single-purpose services that do one thing really, really well.

IN SOA, we have many layers and each layer has different granularity.

VERY IMPORTANT: Service Granularity has an effect on performance and transactions, if you are too fine grained, this means your performance might get effected because of calling multiple services, and it wouldnt be easy to run transactions

SOA VS micro-services Comparing Architecture Characteristics

1- Component Sharing
we mean by components a set of roles and responsibilities with well defined interface.
in our case, the component is service.

in SOA we have the concept of SHARE-AS-MUCH-AS-POSSIBLE, in micro-services, SHARE-AS-LITTLE-AS-POSSIBLE

lets take the example below for SOA, we have 3 services, all of them needs ORDER SERVICE, however each one has a different way of making orders; 

in SOA, this is a candidate for Enterprise service, it will look like this

as you can see the service is smart enough to select which db should be used.

The problem is, you have now one service, testing this service is difficult. 

micro-services follows the domain driven BOUNDED CONTEXT design principle, which means all what you need in one place, in other words, dont share, it means violate DRY (Dont repeat yourself) principle.

well, in micro-services, you share, for example infrastructure services, the point is, make them as less as possible.

The benefit of this, every team is responsible for its work.

2- Service Orchestration and Choreography

In micro-services, we use Choreography, where each service call the next service in the process, so the service has some knowledge; the reason behind that is we dont have a middleware in microservices; HOWERVER YOU SHOULD MINIMIZE THIS INTERACTION AS WE MENTIONED BEFORE, THE INTERACTION SHOULD ONLY BE WITH INFRASTRUCTURE SERVICES.

in order to avoid choreography in micro-services, you can  build more coarse grained services.

in SOA, we use Service Orchestration and choreography, orchestration happens by the middleware, and sure services call each other as well 

3- Middleware vs API LAYER 

lets go back to micro-services architecture

as you can see, we have the API LAYER, THIS IS NOT MIDDLE WARE, it is just a facade, so rather than given the address of the service, you have the address of the API LAYER.
In addition this is good for service granularity, lets say you have service X which you find later that it is coarse-grained and you want to split it to 2 services, you can split it without telling the consumer, the consumer will keep use the API LAYER, and the API LAYER will call 2 services.

SOA uses a middleware, where you put mediation and routing, message enhancement, message transformation, and protocol transformation.

4- Accessing Remote Services
Micro-services uses REST-based or message-based (e.g JMS), the thing is, of course you can use others but micro-services wants to limit that and they dont want to mix, so you dont have to mix REST with JMS with something else.
SOA has no limitation on this, actually the middle ware has the capability of doing protocol transformation.

Comparing Architecture Capabilities

1- Application scope:
SOA is well-suited for large, complex, enterprise-wide systems that require integration with many heterogeneous applications and services. It is also well-suited for applications that have many shared components, particularly components that are shared across the enterprise.

Small web-based applications are also not a good fit for SOA because they don’t need an extensive service taxonomy, abstraction layers, and messaging middleware components.

The microservices pattern is better suited for smaller, well-partitioned web-based systems rather than large-scale enterprise-wide systems. The lack of a mediator (messaging middleware) is one of the factors that makes it ill-suited for large-scale complex business application environments. Other examples of applications that are well-suited for the microservices architecture pattern are ones that have few shared components and ones that can be broken down into very small discrete operations.

ofcourse sometimes you start with micro services and move to SOA or the other way around.

2- Heterogeneous Interoperability

in Microservices, the protocol is always the same, (e.g. REST or Message based) there is no middle ware to change protocol.

as you can see, here we have REST, it is always REST it cannot be REST OR MESSAGE-BASED.

however as you can see the implementation is up to you, jave, .net ....

SOA is perfect for Heterogeneous protocols because of the middle ware

3- Contract Decoupling
Contract decoupling means that consumer with send the request the way he likes and the service will accept different format.

in SOA, we can do this as we have the middle ware, in this case you can transform and enhance the request

we dont have contract decoupling as we dont have the middleware.


Microservices AntiPatterns and Pitfalls by Mark Richard

1- AntiPattern: something looks good at the begging but later it causes a lot of trouble
2- Pitfalls: something that it is bad since the beginning.

When we talk about services we talk about SERVICE COMPONENT, a component is a unit of software that is independently replaceable and upgradeable (Martin fowler).

one of the most important concepts in Micro services is Bounded Context: bounded context means that the service is bounded with its data (they are single unit), which means the service owns its data; also the bounded context is not only about the data, it is about other services, which means a micro service should not depend on other services (at least the dependency should be minimal), which makes the micro service a single unit that can be deployed and tested easily 

Data Driven Migration Anti Pattern

1- we need to migrate the monolithic database to micro service database (part of bounded context architecture)
3- normally what you want to do is this

so you want to split the functionality and the database,

4- dont do that at the beginning, firstly start with the functionality and let them use the same DB, then when you are fine withe granularity you can start with the db.
5- why do we do this? simply because you will not get the granularity correct from the first time

All the world's staging Anti Pattern

in this pattern, you should not focus on the devops task first and push all the functional work to the end, work on parallel

for example, usually people do this mistake, 

ass you can see, the devops tasks are taking 4 months, before you start the first functional iteration, and then the non functional will take one month before you reach iteration 5 which is the main business functionality. You can sell this to your product owner

do the work on parallel like this

as you can see we work on parallel, and you should always work with devops together because something might change during the work.

No comments:

Post a Comment