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

Software Architecture Patterns

By Kevin Disneur

Software Architecture Patterns

An overview of some software architecture patterns, what they bring and how to decide between them

  • 55
Loading comments...

More from Kevin Disneur