A Tale ofA Tale ofContemporary SoftwareContemporary Software

UNSW Guest LectureUNSW Guest LectureMarch 2015

About MeAbout MeComp Science Bachelor UNSWApplied Finance PostGrad at Macquarie UniIBM, Sun, Accenture, BGI/BlackRock, Macquarie GroupNow innovating and opinionating at Trunk Platform

yunspace yunzhilin yunspace.com

My opinions does not reflect the view of the companyShout out if you have questions or need a break

ChallengesChallenges

Case StudiesCase Studies

SolutionSolution

Implement*Implement*

ChallengesChallenges

Market EfficiencyMarket EfficiencyWe live in a market

Stock prices reflect and adjust to all public informationLittle room for arbitrage or outrageous profit

Information Efficiency also applies to business & competition:What you try to do, others are already doing/copyingYour customers are very likely to know more than youYou need to process information fast, but also relevant

Semi-Strong Efficiency

TechnologyTechnologybecomes Key Differentiator becomes Key Differentiator

Superior technology gives competitive advantage:

Exploiting Market Anomalies such as Momentum tradingArbitraging tiny inefficiencies: Quantitive, Frequency trading.Destroying information asymmetry and "experts": RPdata Disrupting established markets: Uber, TeslaProviding better UX for boring things: CBA, Simple.comAll we need is good software ...

Every Company Every Company MUST beMUST beSoftware CompanySoftware Company

The era of separating traditional industries and technologyindustries is over—and those who fail to adapt right now will

soon find themselves obsolete.

- Forbes 2011Now Every Company is A Software Company

Offshoring and underinvestment in core technology isdetrimentalsolution is not cost cutting, but more effective technology"tech refresh" is primitive idea, should always refreshCIO are supposed to be visionary leaders, not accountants

Conway's LawConway's Law

organizations which design systems ... are constrained toproduce designs which are copies of the

communication structures of these organizations Melvin Conway - 1968

- Sarah Novotny (NGinx)Don't Forget Conway's Law

MelvinConway.com

Good Software Design starts off with Orgnisational Design

Siloed SystemSiloed SystemInformation and Capabilities lost in translation between silos

Prefered SystemPrefered SystemLead to architecture based around business capabilities

Software Systems must ConnectSoftware Systems must ConnectInformation are rarely stored in a single place,

but integration of systems is hard:

Any two applications are differentApplication changes are inevitableNetworks are unreliable and slow

, Gregor HohpeEnterprise Integration Patterns

ConclusionConclusionTechnology can differentiate in a competitive world.Challenge is to process information more efficiently But building good software is hard:

Traditional siloed teams hinder collaborationIntegrating applications is painful

CaseCaseStudiesStudies

Aladdin PlatformAladdin Platform25Million lines of codeOne stop shop for risk & portfolios Central DB, no integration needed20,000 users, 30,000 portfolios1000+ developers, built over 20 yrs

single point of failuredeath by stored proceduresslow change cycle (legacy)siloed development teamthick client

Built around 1994. Iconic Monolithic, OS for traders

Tightly Coupled SystemsTightly Coupled Systems

= Useless but Deadly Change Review Meetings= Useless but Deadly Change Review MeetingsLegacy monoliths tend to be defensive, "keep the lights on"Lack of tests -> unknown risks -> afraid to make changesMaking changes is equivalent to "chucking a Prince Oberyn"

BGI Global MesssagingBGI Global Messsaging

Publish / SubscribeReal time, high speedAcross 3 time zonesCanonical Data + EnrichmentDecoupled end servicescustom 3rd party messaging

ESB potential point of failureData is Publisher drivenCross functional stops at ESBBottleneck shift to ESB$$$ internal & external workTragedy of the commons

Enterprise Service Bus

ETFCash FixedEquities

Custodians SWIFTCounter

Party

early 2000s, Traditional SOA, quite ahead of its time:

ESB promises:ESB promises:

That's a lot! Concerned about Separation of Concerns?

Scaling the ESBScaling the ESB

One size fits all: Every on the Bus gets same treatment.Looser coupling and independent scaling would be nice

ESB in RealityESB in Reality

ConclusionConclusionMonoliths and tight coupling are badESBs isn't perfect, but stepping in right direction

SolutionSolution

40 years of Service Evolution40 years of Service Evolution

- PWC Technology Forecast 2014

Microservices: The resurgence of SOA principles and an alternative to the monolith

Change ManagementChange Management

- PWC Technology Forecast 2014

Microservices: The resurgence of SOA principles and an alternative to the monolith

What are MicroServicesWhat are MicroServices

NetFlix, Amazon, realestate.com.au, Tyro, Atlassianhttp://martinfowler.com/articles/microservices.html

Similar to traditional SOA, except no more ESBConsumer driven contracts instead of Canonical DataFault tolerant and independently scalable

Activity Based Working

SelfSelfOrgnisingOrgnising

TeamTeam

Cross Functional DeliveryCross Functional Delivery

Business

UI/UX Design

Front EndDev

Back EndDev

Infrastructure/DevOps

ConclusionConclusionSplit into Self Organised Teams around CapabilitiesCross functional collaboration deliver CapabilitiesDecoupled and scalable Capabilities collectivelyform Microservices Architecture (MSA)

ImplementImplement(optional homework)(optional homework)

Test Driven DevelopmentTest Driven DevelopmentHow do you know when you broke something?you don't, so write tests!There is no such thing as untestable code @CodaHale

Highly recommend Uncle Bob's book:

Clean CodeThe Clean Coder

Find out more at:

cleancoder.comcleancoders.com

Write Clean CodeWrite Clean Code

Twelve Factor AppTwelve Factor AppBy Heroku:

Some opinionated points that apply to University work:

One Code base - use git: github/bitbucketConfig - use environment variablesDependencies - use gradle to avoid death by xml:

12factor.net

repositories { jcenter() maven { url "http://dl.bintray.com/trunkplatform/osworkflow" }}

dependencies { compile group: 'com.trunkplatform', name: 'service'}

<repositories> <repository> <snapshots> <enabled>false</enabled> </snapshots> <id>bintray-trunkplatform</id> <name>bintray</name> <url>http://dl.bintray.com/trunkplatform/osworkflow</url> </repository></repositories>

<dependencies> <dependency> <groupId>com.trunkplatform.opensymphony</groupId> <artifactId>service</artifactId> <version>3.1.4</version> <scope>compile</scope> </dependency></dependencies>

Use REST, no WSDL/SOAPUse REST, no WSDL/SOAP

{ "streetNumber": "80", "streetName": "Clarence", "suburb": "Sydney"}

<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:p="http://www.platmasphere.com/createProperty.xsd"> <p:CreateProperty> <m:Property> <m:streetNumber>80</m:streetNumber> <m:streetName>Clarence</m:streetName>

PUT /hostname/properties/<definitions name="PropertyService" targetNamespace="http://namespaces.snowboard-info.com" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

<!-- not including model schemas -->

<message name="CreatePropertyRequest"> <part name="body" element="CreatePropertyRquestModel"/> </message> <message name="GetPropertyResponse"> <part name="body" element="CreatePropertyResponseModel"/> </message>

<portType name="Properties_Port"> <operation name="CraeteProperty"> <input message="CreatePropertyRequest"/> <output message="CreatePropertyResponse"/> <fault message="CreatePropertyFault"/> </operation> </portType>

<binding name="CreateProeprtySoapBinding" type="GreatePropertytType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="CreateProperty"> <soap:operation soapAction="http://www.platmasphere.com/CreateProperty"/> <input>

Managed to avoid death by XML again!

Good RESTGood RESTis notis notRemote Proc Calls over HTTP:

POST /api/getUserById/{id}POST /api/createUser/POST /api/updateUser/{id}POST /api/delUserById/{id}

is is Resource oriented, http verbs:

GET /api/user/{id}POST /api/userDELETE /api/user/{id}PUT /api/user/{id}

REST Verbs Reference:http://www.restapitutorial.com/lessons/httpmethods.html

REST in JavaREST in Java1. Java API for Restful Services: 2. Implemented by Jersey: 3. Made even more awesome by:

https://jax-rs-spec.java.net/https://jersey.java.net/

http://dropwizard.io/

++ == PROFITPROFIT

Dropwizard.ioDropwizard.ioDropwizard makes it easy to do the right thing,

allowing you to concentrate on the essentialcomplexity of a problem rather than the plumbing

ThoughtWorks Technology Radar

Getting Started:

Sample Project with Heroku support:

Our Dropwizard-Turbo LazyBones Template:

http://www.dropwizard.io/getting-started.html

https://github.com/Trunkplatform/dropwizard-petstore

https://github.com/Trunkplatform/lazy-bones-dropwizard-turbo

PostManPostManFor manual testing: https://www.getpostman.com/

Swagger.ioSwagger.ioWho needs WSDL when you have Interactive Docs

Questions?Questions?I'll be talking some more at:

- Microservices Meetup 1st AprilDropwizard and Friends

www.trunkplatform.comStartup focusing on Real EstateOld industry, new ideasWe are very ContemporarySelf OrganisedAnd we use Microservices

We are Hiring!We are Hiring!