Software Architectures, Week 1 - Monolithic Architectures

65
System Architecture Week 1

Transcript of Software Architectures, Week 1 - Monolithic Architectures

Page 1: Software Architectures, Week 1 - Monolithic Architectures

System Architecture

Week 1

Page 2: Software Architectures, Week 1 - Monolithic Architectures

Technologies are the techies' favourite topic

Page 3: Software Architectures, Week 1 - Monolithic Architectures

Do technologies deliver by themselves?

Do all the hyped technologies solved the problems they promise they will solve?

Page 4: Software Architectures, Week 1 - Monolithic Architectures

Guess not...

Page 5: Software Architectures, Week 1 - Monolithic Architectures

seems even less likely...

Page 6: Software Architectures, Week 1 - Monolithic Architectures

nuff said...

Page 7: Software Architectures, Week 1 - Monolithic Architectures

Architecture when there is no architecture

Page 8: Software Architectures, Week 1 - Monolithic Architectures

Follows usually the Layer Architecture Pattern

Page 9: Software Architectures, Week 1 - Monolithic Architectures

Layer Architecture Pattern

Page 10: Software Architectures, Week 1 - Monolithic Architectures

MVC!

Page 11: Software Architectures, Week 1 - Monolithic Architectures

Hold on

Is MVC an Architectural Pattern?

Page 12: Software Architectures, Week 1 - Monolithic Architectures

Answer•It is not. From Wiki: "Model–view–controller (MVC) is a software design pattern for implementing user interfaces on computers."•You can have MVC in monoliths, micro-services, event-based systems, etc.

Page 13: Software Architectures, Week 1 - Monolithic Architectures

 Layers• Components are organized in horizontal layers, with each layer

performing a specific role in the application (e.g. presentation, business, persistence).

• Each layer has a unique responsibility within the system.

• Each layer only needs to know how to talk with the layers adjacent to it and perform the tasks it is meant for.

Page 14: Software Architectures, Week 1 - Monolithic Architectures

Components• Components within a layer materialize logic that provides

functionality within the layer (e.g. controllers in a MVC application).

• The layer specifies the component scope, making it easy to develop, test, govern and maintain the application.

• Do language or paradigm-specific constructs (OO-classes, class hierarchies, FP-higher order functions, function modules,…) play any role in our description?

Page 15: Software Architectures, Week 1 - Monolithic Architectures

What can go wrong, anti-patternsSinkhole: • Requests pass through multiple layers with little or no logic executed.• In MVC parlance, fat controllers-thin models, vice versa on any similar

combination.• 80-20 is a good rule of thumb to find whether you have a sink hole

(80% of the requests get some processing and 20% only pass through – which makes sense).• In the opposite case, you should may consider making some non-

adjacent layers open.

Page 16: Software Architectures, Week 1 - Monolithic Architectures

Can we have less layers?

Page 17: Software Architectures, Week 1 - Monolithic Architectures

Or more?

Page 18: Software Architectures, Week 1 - Monolithic Architectures

But when 

?

Page 19: Software Architectures, Week 1 - Monolithic Architectures

And how we figure it out?

Page 20: Software Architectures, Week 1 - Monolithic Architectures

Easy!

Page 21: Software Architectures, Week 1 - Monolithic Architectures

Separation of Concerns (Soc – not System-on-Chip)

• Hands down the most important principle in Software Engineering.

• “separation of concerns … even if not perfectly possible is yet the only available technique for effective ordering of one’s thoughts” -- Edsger Dijsktra, 1974

• Invented by him in his 1974 paper 'On the role of scientific thought'.

Page 22: Software Architectures, Week 1 - Monolithic Architectures

And who the heck is Dijkstra?• Pioneer in Software Engineering and Architecture, Parallel Computing, Graph

Processing, Programming Paradigms, Algorithms, Compilers,…..

• His minimum cost, graph traversing algorithm from 1959 is still widely used today. He came up with it in 20 minutes, while he was sipping his coffee on a coffee in Amsterdam with his fiance.

• His book 'A Discipline of Programming' is still the best 217 pages of CS material you will ever read.

• His paper 'On the Role of Scientific Thought' is a seminal work in software analysis.

• Early form of hipster.

Page 23: Software Architectures, Week 1 - Monolithic Architectures

What is Separation of Concerns?• Separating a computer program in different modules, so that each

module addresses a concern.• A concern is a particular set of information that has an effect on the

code of a computer program.• E.g. Read an entry from a database table and affect the program

workflow.• Process the user input from a form.• Identify an object in an image and decide the course of action.

Page 24: Software Architectures, Week 1 - Monolithic Architectures

Excerpts from 'On the Role of Scientific Thought' 

"Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter is isolation for the sake of ist own consistency, all the time knowing that one is occupying oneself only with one of the aspects.

We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another modd we may ask ourselves whether, and if so: why, the program is desirable..."

Page 25: Software Architectures, Week 1 - Monolithic Architectures

Excerpts from 'On the Role of Scientific Thought' 

"...But nothing is gained –on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of.

This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously."

Page 26: Software Architectures, Week 1 - Monolithic Architectures

Excerpts from 'On the Role of Scientific Thought' 

"...The proper technique is clearly to postpone the concerns for general acceptance until you have reached a result of such a quality that it deserves acceptance. It is the significance of your message that should justify the care that you give to ist presentation, it may be uts 'unusualness' that makes extra care necessary.

And secondly what is 'general'? Has Albert Einstein failed because the Theory of Relativity is too difficult for the average highscholl student? "

Page 27: Software Architectures, Week 1 - Monolithic Architectures

Excerpts from 'On the Role of Scientific Thought' 

"The task of 'making a thing satisfying our needs' as a single responsibility is split into two parts 'stating the properties of a thing, by virtue of which it would satisfy our needs' and 'making a thing guaranteed to have the stated properties' ".

Business data processing systems are sufficiently complicated to require such a separation of concerns and the suggestion tha in that part of the computing world 'scientific thought is non-applicable luxury' puts the cart before the horse: the mess they are in has been caused by too much unscientific thought."

Page 28: Software Architectures, Week 1 - Monolithic Architectures

Do concerns sound familiar?

Page 29: Software Architectures, Week 1 - Monolithic Architectures

ActiveSupport::Concernmodule Mailable extend ActiveModel::Conern

def send_password_reset_email UserMailer.password_reset(self).deliver_now end

def send_confirmation_email UserMailer.confirmation(self).deliver_now endend

Page 30: Software Architectures, Week 1 - Monolithic Architectures

ActiveSupport::Concern (cont.)• Not plain concerns but cross-cutting concerns.

• Concerns which are spread out and cannot be cleanly decomposed from other concerns.

• Typical examples are logging, indexing.

• Also behavior which does not really seem to be part of the main concern's 'essence' (e.g. password management in a User model).

Page 31: Software Architectures, Week 1 - Monolithic Architectures

https://richonrails.com/articles/rails-4-code-concerns-in-active-record-models

Page 32: Software Architectures, Week 1 - Monolithic Architectures

The Basic Premise

Page 33: Software Architectures, Week 1 - Monolithic Architectures
Page 34: Software Architectures, Week 1 - Monolithic Architectures

How can we refactor this code?

Page 35: Software Architectures, Week 1 - Monolithic Architectures

The module...

Page 36: Software Architectures, Week 1 - Monolithic Architectures

...and the model

Page 37: Software Architectures, Week 1 - Monolithic Architectures

SoC can help to build a monolithic application right

Page 38: Software Architectures, Week 1 - Monolithic Architectures

What is a monolithic application?

Page 39: Software Architectures, Week 1 - Monolithic Architectures

When to build a monolith• When you launch a startup.

• When you have a small development team.

• When you want to iterate fast.

• When scalability is not a (big) issue.

Page 40: Software Architectures, Week 1 - Monolithic Architectures

When not to build a monolith• When you grow a startup.

• When you have a big development team.

• When you want to iterate fast and break less things.

• When scalability is not a big issue.

Page 41: Software Architectures, Week 1 - Monolithic Architectures
Page 42: Software Architectures, Week 1 - Monolithic Architectures

The resuméeAs I hear stories about teams using a microservices architecture, I've noticed a common pattern.

1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up.

2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

Page 43: Software Architectures, Week 1 - Monolithic Architectures

How far can a Monolith go?

Page 44: Software Architectures, Week 1 - Monolithic Architectures

Pretty far actually

Page 45: Software Architectures, Week 1 - Monolithic Architectures

kdb+• 19 of the 20 world's top investment banks.

• 1.6 TB daily stream ingestion per server.

• 300 million records/second/core search rate.

• 500KB executable, can fit in the CPUs cache.

Page 46: Software Architectures, Week 1 - Monolithic Architectures

Some very successful monoliths

Page 47: Software Architectures, Week 1 - Monolithic Architectures

Etsy's Architecture

How many *liths do you see?

Page 48: Software Architectures, Week 1 - Monolithic Architectures

Etsy's Architecture (cont.)

Click to add text

Page 49: Software Architectures, Week 1 - Monolithic Architectures

Python Interpreter Architecture• The architectural patterns are not limited to one type of application

(web-apps, command line tools, mobile apps), but are mental frameworks which can be used for any software program.

• What is applicable for Etsy, is also applicable for PyPy.

Page 50: Software Architectures, Week 1 - Monolithic Architectures

Python Interpreter Architecture (cont.)

Page 51: Software Architectures, Week 1 - Monolithic Architectures

Separation of Concerns Revisited

• Did we see SoC being applied to the architectures we saw?

• What could be done better?

Page 52: Software Architectures, Week 1 - Monolithic Architectures

Our pet – Wishlist app (vosobe)

Page 53: Software Architectures, Week 1 - Monolithic Architectures

A wish list of products

• Organize products you want to buy in lists.

• Share the lists with other persons.

• Follow another user or a user's list.

Page 54: Software Architectures, Week 1 - Monolithic Architectures

Languages and Frameworks - #1 Ruby & Rails

Page 55: Software Architectures, Week 1 - Monolithic Architectures

Verdict: nayPros:• The current tool of trade.

Cons:• Too much magic (Activerecord, Activeresource).• Devs tend to depend on generators and the Rails magic, don't know what

is happening under the hood and many don't know how to write the code themselves.• Not the cleanest solution architecturally (where to you put your biz logic?)

Page 56: Software Architectures, Week 1 - Monolithic Architectures

Candidate Languages - #2 Racket & web-srvr

Page 57: Software Architectures, Week 1 - Monolithic Architectures

Verdict: nayPros:• Super interesting language, with cutting-edge features.• Can result in very clean design that follows the intented architecture.• Homoiconicity!

Cons:• It may be too alien for many people, not enough time during

the seminar to get acquained with it.

Page 58: Software Architectures, Week 1 - Monolithic Architectures

Candidate Languages - #3 Python & Flask

Page 59: Software Architectures, Week 1 - Monolithic Architectures

Verdict: nayPros:• Very simple language and framework.• Can be very flexible and be developed in any direction architecturally.

Cons:• Too simplistic for a real-life application that will need to evolve.• It does not provide enough structure (both good and bad).• Easy to get lost in details if somebody has not enough experiences in

building big projects from scratch.

Page 60: Software Architectures, Week 1 - Monolithic Architectures

Candidate Languages - #4 Ruby & Hanami

Page 61: Software Architectures, Week 1 - Monolithic Architectures

Verdict: yayPros:• It is in Ruby, simple and elegant language.• It enforces sound architectural choices (real separation of concerns, e.g. models are split in

business logic entities and object that mediates between the entities and the persistence layer). • It is designed to start monolithically and later evolve to microservices. • Performant• Way less magic than rails.• Can expand to multiple applications, while sharing the same entities (models).

Cons:• It may require to write more lines of code than Rails.• Like any other full blown framework, it requires time and effort in order to learn it.

Page 62: Software Architectures, Week 1 - Monolithic Architectures

A "Clean" Framework

Page 63: Software Architectures, Week 1 - Monolithic Architectures

Vosobe's architecture (looks familiar?)

MySQL

Container

Wishlist (Application)

RepositoriesUserRepository ListRepository ListItem

Repository

ModelsUser List ListItem

Controllers UserController

ListController

ListItemController

ViewsViewLists ViewListItems CreateList AddItemsInList

Page 64: Software Architectures, Week 1 - Monolithic Architectures

What about the code?

• Already pushed in Gitlab.

• URL in Google Group page.

Page 65: Software Architectures, Week 1 - Monolithic Architectures

Thank you for your time, see you in 2 Fridays :-)