Technical Archaeology Devoxx

@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

Dist

ribut

ion


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.”

Used

• 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

TO

MICROSERVICES

@YourTwitterHandle@sasaunde#TechnicalArchaeology

Demo


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

Demo


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


SOAP

DIVERGENCE

TO

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

TO

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

Q & A

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

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

Technical Archaeology Devoxx

Software

Transcript of Technical Archaeology Devoxx