Technical Archaeology Devoxx

transcript

@sasaunde#TechnicalArchaeology

Technical Archaeology

Sarah Saunders@sasaunde http://capgemini.github.io/

Technical ArchaeologyUnearthing Antipatterns in Modern

Distributed Technology Stacks

• Sarah Saunders• Capgemini• Senior Developer• 15 years of architecture exposure

AgendaEvolutionary Concepts

History of Distributed Architecture

Find some Architectural Dinosaurs

• Do some demos

Draw some Conclusions

Evolution (briefly)

Divergence

* "Tiktaalik BW“ and “Puijila BW” by Nobu Tamura (http://spinops.blogspot.com) - Own work. Licensed

under CC BY 2.5 via Wikimedia Commons

Technical Divergence

Mach (from 1985)Microkernel Architecture

Linux (from 1991)Monolithic kernel

MS-DOS(from 1981)

Monolithic kernel

UNIX (from 1970s)Monolithic kernel

QNX (from 1980s)Microkernel Architecture

History of Technical Architecture

Punch cards as a way to get data from one device to another

Cable connecting terminal to mainframe

Client-Server Architecture

Service Oriented Architecture

Microservice Architecture

Miniaturisation

Drivers for ChangePhysical

• Technical AdvancesHardwareDesign

Social• Large Companies exercising their consumer power• Policies, Laws, Standards and Protocols• Cultural Drives

DINOSAUR HUNT

Vestigial Functionality

Divergence

Change driven by the Environment

SingletonDefinition

“The singleton pattern ensures that only one object of a particular class is ever created. All further references to objects of the singleton class refer to the same underlying instance.”

• Thread and Connection Pools• Configuration Management• Resources• Legacy data source management

SingletonDesign

Maps to single CPU PC Hardware Concepts•Static object in memory in heap•Referred to from stack(s)

Object Oriented•Inherit interface

Problems

Multiple CPU architecture blockerMessage based architecture blocker (global state)Functional programming blocker (immutability)Cannot mock test

SingletonAlternatives

• Inversion of Control• Configuration rather than static code

• Implement as a Service

• Constructor parameters

Singleton

VESTIGIAL

Object Relational Mapping“A programming technique for converting data between incompatible

type systems in object-oriented programming languages” (wikipedia)

• Manages synchronization of database and in-memory object representation

• Makes a database look like an object-oriented store.

BUT• Hides Complexity

BETTER• Simplify Architecture• Database as a Service

Object Relational Mapping

DIVERGENCE

MICROSERVICES

@YourTwitterHandle@sasaunde#TechnicalArchaeology

Same Origin Policy

XMLHttpRequest cannot load http://localhost:9092/dinosaurs. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access. The response had HTTP status code 405.

Same Origin PolicyImplemented by browsers when opening an XmlHttpRequest

“A browser’s same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin”

Used as a means to prevent some Cross-site Request Forgery attacks.

CORSCovering up Browser Weaknesses

Scripts accessing multiple windows

Covering up Cookie WeaknessesRequest sends multiple cookies

Covering up weakness of IP based authentication

• Creates backward dependency between services

VESTIGIAL

SOAPFoundation for Web Services

•Processing Model•Extensibility Model•Protocol Framework•Message Construct

RPC or “Document Literal” Styles

JAX-WS specification; WCF specification

WSDL2<lang> and <lang>2WSDL

@YourTwitterHandle@sasaunde#TechnicalArchaeology

SOAP• Monolithic Solution (trying to be all things to all people)

• Defines message formats, transports • Committee-driven definition for web services

• Not actually cross-platform after all• One-way communication• Verbose; slow

• RESTful architectures are becoming much more popular• Lighter definition (RESTful not REST)• Choose your Protocol – avoid XML overhead if not needed

DIVERGENCE

MICROSERVICES

Enterprise Java BeansLet’s try to summarise....

• Persistence• Transactional Integrity• Security• Concurrency• Events• Asynchronous calls• Job scheduling• JNDI• Interprocess Communication• Deployment• Container Responsibilties• Tea making• World Peace

Enterprise Java Beans• Monolithic Solution (trying to be all things to all people)

• “Golden Hammer” – obfuscates complexity• Specification too broad; perception that EJBs introduce complexity

without delivering benefit• Solving three-tiered architecture problems (is this still relevant?)• We will always find something it DOESN’T cover..

Spring Framework triggered the much-better EJB 3.0 specification (Competition-driven evolution in action!)

DIVERGENCE

MICROSERVICES

@YourTwitterHandle#DVXFR14{session hashtag} @sasaunde#TechnicalArchaeology

Summar

y“Those that fail to learn from history are doomed to repeat it” – Winston Churchill

Two Themes1. Divergence

• Away from Monolithic Solutions• Away from “Future Proofing”• Towards simpler, more modular solutions• Reuse of successful patterns

Why?• Changes in Hardware and Software• Monoliths not living up to expectations

Two Themes

2. Vestigial Functionality• Two Types

1. Controllable2. Uncontrollable

Why?• Human Behaviour – “It worked last time”• International Standards – slow to change

TakeawaysTechnical Architecture Evolves and Evolution is Divergent

We carry Vestigial Functionality in our architectures

We are currently diverging from Large Specifications towards Microservice Architectures

Things Will Change!

Design for Disposability, not for the Future

@YourTwitterHandle#DVXFR14{session hashtag} @sasaunde#TechnicalArchaeology

https://wall-simple.sli.do/#/event/cmnxxfl0/section/18283/questions