Software Architecture Patterns

Software Architecture != Software Design

CAUTION

Objectives

1.  Define what we call a monolith and a distributed system

 

2.  Quick overview of some architectural patterns

 

3.  Fewlines case study

Definition

monolith

One unit for all business flows and database access 

distributed system

Business flows and/or database access separated in multiple units but communicate and coordinate to appear as one coherent system for the end user

Monoliths

- Layered

Presentation

Business

Persistence

Application

Database

Producer

Filters

...

Application

Pipe

Pipe

Consumer

Pipe

- Pipeline

Monoliths

 

 

Core

 

System

 

 

Application

Plugin

Plugin

Plugin

Plugin

Plugin

Database

Database

Database

- Micro-Kernel

Monoliths

Distributed System

- Service Based

 

Gateway

Database

Service A

Service B

Service C

Service D

UI

API

 

Orchestrator

Component A

Distributed System

- Orchestrator

Component C

Component D

Component E

Component B

Orchestraor

Component A

Component B

Component C

Component D

Distributed System

- Choregraphy

Component A

Component B

Distributed System

- Micro-Services

Component C

Component D

Component ...

Component E

Fewlines Connect

Requirements we thought we had:

• Need to have low latency worldwide
• Need to scale the team in a few years
• Different kind of computing CPU vs Memory intensive
• Different kind of services requiring different technologies

Decision:

• "macro-service" architecture
• Communicate as much as possible through events

Fewlines Connect

Reality:

• Project didn't scaled worldwide (yet)
• Team didn't scale
• "Macro-service" has a high development cost
• Only one language in the stack
• Networking adds complexity

Requirements we actually need:

• Be able to add/test new features quickly
• Be ready to scale if need be

Fewlines Catalog

 

Gateway

Database

Service A

Service B

Service C

Service D

UI

API

 

Database

Database

Database

Architecture rules

Rule 1

Everything in software architecture is a trade-off

 

Corollary rule

If you think you have discovered something that isn’t a trade-off, more likely you just haven’t identified the trade-off yet

 

Rule 2

Why is more important than how