Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

A Tale of Contemporary Software

•
•

This document summarizes a guest lecture at UNSW about contemporary software challenges and solutions. It discusses how technology can provide a competitive advantage if developed properly. It presents case studies of legacy systems that were difficult to change and scale, as well as examples of systems that used newer architectures like microservices. The lecture promotes approaches like test-driven development, REST, and self-organizing teams to build independent, scalable services.

1 of 39
Download to read offline
A Tale ofA Tale of Contemporary SoftwareContemporary Software UNSW Guest LectureUNSW Guest Lecture March 2015
About MeAbout Me Comp Science Bachelor UNSW Applied Finance PostGrad at Macquarie Uni IBM, Sun, Accenture, BGI/BlackRock, Macquarie Group Now innovating and opinionating at Trunk Platform yunspace yunzhilin yunspace.com My opinions does not reflect the view of the company Shout out if you have questions or need a break
ChallengesChallenges Case StudiesCase Studies SolutionSolution Implement*Implement*
ChallengesChallenges
Market EfficiencyMarket Efficiency We live in a market Stock prices reflect and adjust to all public information Little room for arbitrage or outrageous profit Information Efficiency also applies to business & competition: What you try to do, others are already doing/copying Your customers are very likely to know more than you​​ You need to process information fast, but also relevant Semi-Strong Efficiency
TechnologyTechnology becomes Key Differentiatorbecomes Key Differentiator Superior technology gives competitive advantage: Exploiting Market Anomalies such as Momentum trading Arbitraging tiny inefficiencies: Quantitive, Frequency trading. Destroying information asymmetry and "experts": RPdata Disrupting established markets: Uber, Tesla Providing better UX for boring things: CBA, Simple.com All we need is good software ...
Every CompanyEvery Company MUST beMUST be Software CompanySoftware Company The era of separating traditional industries and technology industries 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 is detrimental solution is not cost cutting, but more effective technology "tech refresh" is primitive idea, should always refresh CIO are supposed to be visionary leaders, not accountants
Conway's LawConway's Law organizations which design systems ... are constrained to produce 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 System Information and Capabilities lost in translation between silos
Prefered SystemPrefered System Lead to architecture based around business capabilities
Software Systems must ConnectSoftware Systems must Connect Information are rarely stored in a single place, but integration of systems is hard: Any two applications are different Application changes are inevitable Networks are unreliable and slow , Gregor HohpeEnterprise Integration Patterns
ConclusionConclusion Technology can differentiate in a competitive world. Challenge is to process information more efficiently But building good software is hard: Traditional siloed teams hinder collaboration Integrating applications is painful
CaseCase StudiesStudies
Aladdin PlatformAladdin Platform 25Million lines of code One stop shop for risk & portfolios Central DB, no integration needed 20,000 users, 30,000 portfolios 1000+ developers, built over 20 yrs single point of failure death by stored procedures slow change cycle (legacy) siloed development team thick 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 Meetings Legacy monoliths tend to be defensive, "keep the lights on" Lack of tests -> unknown risks -> afraid to make changes Making changes is equivalent to "chucking a Prince Oberyn"
BGI Global MesssagingBGI Global Messsaging Publish / Subscribe Real time, high speed Across 3 time zones Canonical Data + Enrichment Decoupled end services custom 3rd party messaging ESB potential point of failure Data is Publisher driven Cross functional stops at ESB Bottleneck shift to ESB $$$ internal & external work Tragedy of the commons Enterprise Service Bus ETFCash FixedEquities Custodians SWIFT Counter 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
ConclusionConclusion Monoliths and tight coupling are bad ESBs 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, Atlassian http://martinfowler.com/articles/microservices.html Similar to traditional SOA, except no more ESB Consumer driven contracts instead of Canonical Data Fault tolerant and independently scalable
Activity Based Working
SelfSelf OrgnisingOrgnising TeamTeam
Cross Functional DeliveryCross Functional Delivery Business UI/UX Design Front End Dev Back End Dev Infrastructure/ DevOps
ConclusionConclusion Split into Self Organised Teams around Capabilities Cross functional collaboration deliver Capabilities Decoupled and scalable Capabilities collectively form Microservices Architecture (MSA)
ImplementImplement (optional homework)(optional homework)
Test Driven DevelopmentTest Driven Development How 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 Code The Clean Coder Find out more at: cleancoder.com cleancoders.com Write Clean CodeWrite Clean Code
Twelve Factor AppTwelve Factor App By Heroku: Some opinionated points that apply to University work: One Code base - use git: github/bitbucket Config - use environment variables Dependencies - use gradle to avoid death by xml: 12factor.net repositories { jcenter() maven { url "http://dl.bintray.com/trunkplatfo } } dependencies { compile group: 'com.trunkplatform', name: 'servi } <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:Envelope xmlns: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 REST is notis not Remote Proc Calls over HTTP: POST /api/getUserById/{id} POST /api/createUser/ POST /api/updateUser/{id} POST /api/delUserById/{id} isis Resource oriented, http verbs: GET /api/user/{id} POST /api/user DELETE /api/user/{id} PUT /api/user/{id} REST Verbs Reference: http://www.restapitutorial.com/lessons/httpmethods.html
REST in JavaREST in Java 1. 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.io Dropwizard makes it easy to do the right thing, allowing you to concentrate on the essential complexity 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
PostManPostMan For manual testing: https://www.getpostman.com/
Swagger.ioSwagger.io Who needs WSDL when you have Interactive Docs
Questions?Questions? I'll be talking some more at: - Microservices Meetup 1st AprilDropwizard and Friends www.trunkplatform.com Startup focusing on Real Estate Old industry, new ideas We are very Contemporary Self Organised And we use Microservices We are Hiring!We are Hiring!

More Related Content

A Tale of Contemporary Software

  • 1. A Tale ofA Tale of Contemporary SoftwareContemporary Software UNSW Guest LectureUNSW Guest Lecture March 2015
  • 2. About MeAbout Me Comp Science Bachelor UNSW Applied Finance PostGrad at Macquarie Uni IBM, Sun, Accenture, BGI/BlackRock, Macquarie Group Now innovating and opinionating at Trunk Platform yunspace yunzhilin yunspace.com My opinions does not reflect the view of the company Shout out if you have questions or need a break
  • 5. Market EfficiencyMarket Efficiency We live in a market Stock prices reflect and adjust to all public information Little room for arbitrage or outrageous profit Information Efficiency also applies to business & competition: What you try to do, others are already doing/copying Your customers are very likely to know more than you​​ You need to process information fast, but also relevant Semi-Strong Efficiency
  • 6. TechnologyTechnology becomes Key Differentiatorbecomes Key Differentiator Superior technology gives competitive advantage: Exploiting Market Anomalies such as Momentum trading Arbitraging tiny inefficiencies: Quantitive, Frequency trading. Destroying information asymmetry and "experts": RPdata Disrupting established markets: Uber, Tesla Providing better UX for boring things: CBA, Simple.com All we need is good software ...
  • 7. Every CompanyEvery Company MUST beMUST be Software CompanySoftware Company The era of separating traditional industries and technology industries 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 is detrimental solution is not cost cutting, but more effective technology "tech refresh" is primitive idea, should always refresh CIO are supposed to be visionary leaders, not accountants
  • 8. Conway's LawConway's Law organizations which design systems ... are constrained to produce 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
  • 9. Siloed SystemSiloed System Information and Capabilities lost in translation between silos
  • 10. Prefered SystemPrefered System Lead to architecture based around business capabilities
  • 11. Software Systems must ConnectSoftware Systems must Connect Information are rarely stored in a single place, but integration of systems is hard: Any two applications are different Application changes are inevitable Networks are unreliable and slow , Gregor HohpeEnterprise Integration Patterns
  • 12. ConclusionConclusion Technology can differentiate in a competitive world. Challenge is to process information more efficiently But building good software is hard: Traditional siloed teams hinder collaboration Integrating applications is painful
  • 14. Aladdin PlatformAladdin Platform 25Million lines of code One stop shop for risk & portfolios Central DB, no integration needed 20,000 users, 30,000 portfolios 1000+ developers, built over 20 yrs single point of failure death by stored procedures slow change cycle (legacy) siloed development team thick client Built around 1994. Iconic Monolithic, OS for traders
  • 15. Tightly Coupled SystemsTightly Coupled Systems = Useless but Deadly Change Review Meetings= Useless but Deadly Change Review Meetings Legacy monoliths tend to be defensive, "keep the lights on" Lack of tests -> unknown risks -> afraid to make changes Making changes is equivalent to "chucking a Prince Oberyn"
  • 16. BGI Global MesssagingBGI Global Messsaging Publish / Subscribe Real time, high speed Across 3 time zones Canonical Data + Enrichment Decoupled end services custom 3rd party messaging ESB potential point of failure Data is Publisher driven Cross functional stops at ESB Bottleneck shift to ESB $$$ internal & external work Tragedy of the commons Enterprise Service Bus ETFCash FixedEquities Custodians SWIFT Counter Party early 2000s, Traditional SOA, quite ahead of its time:
  • 17. ESB promises:ESB promises: That's a lot! Concerned about Separation of Concerns?
  • 18. Scaling the ESBScaling the ESB One size fits all: Every on the Bus gets same treatment. Looser coupling and independent scaling would be nice
  • 19. ESB in RealityESB in Reality
  • 20. ConclusionConclusion Monoliths and tight coupling are bad ESBs isn't perfect, but stepping in right direction
  • 22. 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
  • 23. Change ManagementChange Management - PWC Technology Forecast 2014 Microservices: The resurgence of SOA principles and an alternative to the monolith
  • 24. What are MicroServicesWhat are MicroServices NetFlix, Amazon, realestate.com.au, Tyro, Atlassian http://martinfowler.com/articles/microservices.html Similar to traditional SOA, except no more ESB Consumer driven contracts instead of Canonical Data Fault tolerant and independently scalable
  • 27. Cross Functional DeliveryCross Functional Delivery Business UI/UX Design Front End Dev Back End Dev Infrastructure/ DevOps
  • 28. ConclusionConclusion Split into Self Organised Teams around Capabilities Cross functional collaboration deliver Capabilities Decoupled and scalable Capabilities collectively form Microservices Architecture (MSA)
  • 30. Test Driven DevelopmentTest Driven Development How do you know when you broke something? you don't, so write tests! There is no such thing as untestable code @CodaHale
  • 31. Highly recommend Uncle Bob's book: Clean Code The Clean Coder Find out more at: cleancoder.com cleancoders.com Write Clean CodeWrite Clean Code
  • 32. Twelve Factor AppTwelve Factor App By Heroku: Some opinionated points that apply to University work: One Code base - use git: github/bitbucket Config - use environment variables Dependencies - use gradle to avoid death by xml: 12factor.net repositories { jcenter() maven { url "http://dl.bintray.com/trunkplatfo } } dependencies { compile group: 'com.trunkplatform', name: 'servi } <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>
  • 33. Use REST, no WSDL/SOAPUse REST, no WSDL/SOAP { "streetNumber": "80", "streetName": "Clarence", "suburb": "Sydney" } <?xml version="1.0"?> <soap:Envelope xmlns: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!
  • 34. Good RESTGood REST is notis not Remote Proc Calls over HTTP: POST /api/getUserById/{id} POST /api/createUser/ POST /api/updateUser/{id} POST /api/delUserById/{id} isis Resource oriented, http verbs: GET /api/user/{id} POST /api/user DELETE /api/user/{id} PUT /api/user/{id} REST Verbs Reference: http://www.restapitutorial.com/lessons/httpmethods.html
  • 35. REST in JavaREST in Java 1. 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
  • 36. Dropwizard.ioDropwizard.io Dropwizard makes it easy to do the right thing, allowing you to concentrate on the essential complexity 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
  • 37. PostManPostMan For manual testing: https://www.getpostman.com/
  • 38. Swagger.ioSwagger.io Who needs WSDL when you have Interactive Docs
  • 39. Questions?Questions? I'll be talking some more at: - Microservices Meetup 1st AprilDropwizard and Friends www.trunkplatform.com Startup focusing on Real Estate Old industry, new ideas We are very Contemporary Self Organised And we use Microservices We are Hiring!We are Hiring!