L02 What is Software Architecture?

HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015L02 WHAT IS SOFTWARE ARCHITECTURE?

Agenda

Conway’s LawArchitecture in the Post-PC worldTechnical DeptArchitectureScaling ApplicationsService Oriented ArchitectureLayering

Reading

Brown 1-7Pattern: Monolithic Architecture Conway´s LawDecomposing applications for scalability and deployabilityThe Scale Cube

Conway’s Law

Conwey’s Law

Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations

From a 1967 paper “How do Committees Invent?” by Mel Conway

Conwey’s Law

In an organisation with three departments you end up with three parts of the software applications

Due to communication and power structure - people want to control their schedule and not depend on others

Directly leads to technical dept

This leads to the saying: “There are not technical problems, only management problems”

Architecture in the Post-PC world

Monolithic ArchitectureTraditional Web Application Architecture

All code is built into a single application that is deployed

Simple to develop, test, deploy, scale

Clear layering: Presentation, Domain,Data Source

Tomcat

ApacheBrowser

WAR

Web Components

Customer

Wallet

Data SourceDB

WAR file = Web ARchiveTomcat = web server for Java Servlets (web components)

9

Trends in ArchitectureTraditional Web Application Architecture using “monolith” is not a bad way to build software

However, some things become hard in this architecture with scale and frequencies of changes

Demand today is very much agile

The monolithic architecture becomes a problem in particular in scaling and organising teams

Chris RichardsonDecomposing Applications for Scalability and Deployability

Monolith Architecture

Bookstore UI

Accounting

Payment

Shipping SQL

Web Browser

Web Server Apache

▪ Benefits– Simple to understand– Straightforward to develop and test– One release and deployment– All linking is a compile type– Scaling is simple - just duplicate the system and use a load balancer

Monolithic Architecture

Monolithic Architecture

▪ Drawbacks– User interface challenge – old style UI architecture– Real-time applications (like node.js) don’t fit in easy– Obstacle to frequent deployment – fear of change– Overloads your IDE and container – slow build, development– Obstacle to scaling development teams– Locks down the technology stack – long term commitment

Demand for Rich Interactive User Experience

Web based request response model is fine for normal content

However for dynamic and interactive experience, for example streaming events to the browser this becomes difficult

From Richardson’s video

Big Deployments

Need to redeploy the whole application for small changes

Any change requires knowledge of the whole system

Deployment becomes risky

Need lots of planning

Become infrequent due to fear

Code waits a long time before its deployed


Container OverloadOverloads your IDE

Takes long time to start the containers

Slows down development


Communication Overload

Changes in component might affect other components

Unwanted dependencies happen - technical dept

Teams need to plan and coordinate


Scaling the development becomes difficult

Stuck with the Technology Stack

Monoliths require long term commitments to the stack

New technology is difficult to adopt

Different problem domains require different stack


Any changes in the technology stack become difficult

Can Result in Technical Debt

Maintenance becomes difficult

People don’t want to work on the code

Company is not competitive

System becomes obsolete

Cost of Change (CoC) becomes too high

Technical Dept

Big Ball of Mud

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of

unregulated growth, and repeated, expedient repair.” — Brian Foote and Joseph Yoder, Big Ball of Mud

Technical DebtConcept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution

Small decisions that accumulate over time - “I’ll fix this later”

Hard to see until any small change is extremely expensive (CoC = Cost of Change), and then Conway’s Second Law applies

If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on

Why does it Happen?

Lazy programmers?Sloppy programmers?Inexperienced programmers?No power to say no?

Source: Baruco 2012: Micro-Service Architecture, by Fred George https://www.youtube.com/watch?v=2rKEveL55TY

Fred George Micro-Service Architecture

https://www.youtube.com/watch?v=2rKEveL55TY

Good design and architecture turn out to be not so goodUsing the wrong toolsShortcuts - “I’ll just inherit this class and change a method”Calling methods you should not callIt was a good idea at the time, for example God ObjectsBad organisational structure (ignorance of Conway’s Law)No ownership of codeNo restrictions - “we’re agile, anybody can change any code”Lack of understanding of the design of the codeCode guidelines and principles forgotten or do not existPutting code in wrong place due to lack of understanding

Why does it Happen?

Other reasons:

Why does it Happen?

Or maybe… University Teachers that teach about concrete inheritance

Object Oriented progamming is good but can be misused

Conwey’s Second Law

There’s never enough time to do something right, but there’s always enough time to do it over

Architecture

Problem with Software Engineering

People see the same thing differently or have the same opinion on different things

The results are that people that really agree, don’t agree

and people that agree, do not really

Problem with Software Engineering

This leads to bad design and implementations

Result is technical debt

Clear Up a Few Things

Terminology needs to be defined

People must have the same understanding of terms used

Define and document

We work in a complex industry - sometimes its good to ask “what do you mean when you say X”

Architecture

Means different things to different peopleBig picture, things difficult to change, a plan, a blueprint…

Architecture - noun

The decomposition of a product into a collection of components/modules and interactions

Structure

Architecture - verb

Understanding what you need to build, create a vision and making the right decisions

vision

A component is a software building block that is

independently replaceable

independently upgradable

Component

Types of Architecture

There are many different architectures★ Network, security, data, hardware, enterprise…All have structure and vision★ All have multiple constraints such as cost, time,

legal, regulatory

Application Architecture

Application is the focus★ Contains classes, components, design patterns, frameworks,

librariesLower-level aspects of software design★ Concerned with sign technology stack and layering

Technology

stackLayering

ClientREST service

EJBHibernate

Oracle

PresentationREST serviceService LayerDomain Layer

Data Layer

System Architecture

▪ Focus on multiple applications across a number of tiers and technologies

▪ Interactions between applications▪ Overall structure of the end-to-end software system at high-level▪ Mix of software and hardware

Software Architecture

▪ The combination of application and system architecture▪ Includes the technical practices to build the software– Design Principles, Programming language

Design patterns, Unit testingand much more…

▪ Must also include aspects like– Cross-cutting concerns such as logging and exception handling

Security, Performance, Audit Requirements, constraints,and much more…

Enterprise Architecture

▪ How the enterprise is broken up in groups/departments▪ Business processes used▪ Workflows used▪ May not look at technology in detail rather how to us technology

across the organization to get work done

Agile Architecture

▪ Agile refers to a methodology of building software– moving fast, embracing change, release often, feedback cycles etc.

▪ Does agile development team then build agile architectures?

▪ Agile architecture means it can react to change, is easy to change, is extendable

Agility

▪ Agility means you can use the OODA loop

How Spotify builds products

ObserveOrientDecideAct

Which of the following architecture descriptions would be concerned withinteractions between applications

A) Application Architecture B) System Architecture C) Software Architecture D) Enterprise Architecture

QUIZ

Scaling Applications

Monolithic ArchitectureTraditional Web Application Architecture

All code is built into a single application that is deployed

In today’s environment might not be thebest approach Tomcat

ApacheBrowser

WAR

Web Components

Customer

Wallet

Data SourceDB

Scaling ApplicationsIn the Internet world you want to build web sites that gets lots of users and massive hit per second

But how can you cope with such load?

Browser HTTPServer Application Database

Scale Cube

X scaling: duplicate the system

Z scali

ng: Part

ition th

e data

Y sc

alin

g: P

artit

ion

the

App

licat

ion

Service Oriented Architecture

Trends in Architecture

Service Oriented Architecture (SOA) dates back to mid 1990s

Web Services meaning XML and SOAP using an Enterprise Services Bus

Confusions on terminology

SOA is overload term - useless Means different things to different peopleImplies Web Services using SOAP

Trends in Architecture

SOA as in Web Services using SOAP

Bezos’ Mandate (from Yegge’s Rant)1. All teams will henceforth expose their data and functionality

through service interfaces2. Teams must communicate with each other through these

interfaces3. There will be no other form of interprocess communication allowed4. It doesn't matter what technology they use5. All service interfaces, without exception, must be designed from

the ground up to be externalizable. No exceptions.6. Anyone who doesn't do this will be fired.


SOA actually means that components of an application act as interoperable services, and can be used independently and recombined into other applications.

Engineering Software as a Service by David Patterson and Armando Fox

Microservices

In recent years a new term has emerged, Microservices:

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

From the Lewis & Fowler article

Martin Fowler - Microservices https://www.youtube.com/watch?v=2yko4TbC8cI

Martin Fowler Microservices

https://www.youtube.com/watch?v=2yko4TbC8cI

Definition of SOA is useless because it is so overloadedMicroservice architecture is better but needs to be clarified

Service Architecture


Software Architecture where all components are designed to be servicesApplications composed of interoperable servicesEasy to build new services, easy to changeParts of the systems need to change more than others

Single Responsibility Principle (SPR) states that a class should have one and only one reason to change, that “reason to change” is its responsibility.

Monolith Architecture

Bookstore UI

Accounting

Payment

Shipping SQL

Web Browser

Web Server Apache

Service Architecture

Bookstore Service

Account service

Payment service

Shipping service

Bookstore UI

Web Browser

Partitioning the Monolith into Services

From http://www.manning.com/rotem/SOAp_SampleCh01.pdf Arnon Rotem-‐Gal-‐Oz’ SOA Patterns figure 1.

One way is to go from Object soup to Services along domain seams to microservices

Microservices or microapps

▪ Each service can be around 100-200 LOC (lines of code)– Size not the deterministic factor– Don’t fix it – rewrite it▪ Microservice can have embedded web server– Totally independent

Drawbacks

Which statement is not true about SOA?

A) SOA does not affect performance B) No service can access other service data except using APIs C) SOA improves productivity though reuse D) Monoliths system must deploy all components

QUIZ

Layering

Layering

• Software systems can get complicated• Abstractions are needed• Layering provides abstraction by separating computer systems in layers• Higher layers use services from

lower layers• Each layer has dedicated tasks

and hides complexity from upper layers

Benefits of Layering

• You can understand a single layer as a coherent whole without knowing much about other layers

• You can substitute layers with alternative implementation of the same basic service

• You minimize dependencies between layers• Layers make good places for standardization• Once you have a layer built, you can use it for many higher-

level services

Downsides

▪ Layers encapsulate some, but not all, things well– Cascading changes– For example adding a field in the UI requires changes on each layer

▪ Extra layers can harm performance– At every layer things typically need to be transformed from one

presentation to another

The Three Layers

▪ Presentation– User’s interface to the system– User can be another system– Accepts input, displays views

▪ Domain– The Application of the system– The “Business logic”– Tends to creep into presentation and data source

▪ Data Source– Connection to the database– Also Persistence

Summary

Conway’s Law explains a lotArchitecture in the Post-PC world means scalingBig complex system can accumulate Technical DeptArchitecture definedHow to Scale ApplicationsWhat is Service Oriented ArchitectureLayering is the oldest trick in the book