Making of MaaS - AWS meetup Stockholm 2016-08

Making of MaaS - AWS meetup Stockholm 2016-08

• 1.
  Building the Future ofMobility
• 2.
  About Me TeliaSonera Longish Nokia Career -Software - Music Industry - Developer Relations across S40, Symbian, Maemo, MeeGo, Qt, HERE, Flash, WRT, HTML5, Windows Phone… - 2-time Webby Award Winner SSH Communications Security, Ixonos Non-profit initiatives & startups - Topicalio MaaS Global Sami Pippuri CTO, MaaS Global @pippuri #spaceselfie Topicalio Whim
• 3.
  Transportation is beinghit by a DIGITAL TSUNAMI. So what is changing?
• 4.
  The key challengesof fast evolving urbanmobility Urbanisation Travel problems Insufficient solutions More people More traffic jams Multiple and disconnected apps Route based public transportation Emerging transport sharing More vehicles Less parking space More urban travel More time spent on PT More complex travel More delays Car ownership not fitting with modern lifestyle
• 5.
  Cities can’t copewith urban mobilitydemand 2,8 43,2 67,1 2010 2030 2050 Urbanisation Current alternative Urban mobility demand 2010-2050 (trillions pkm.p.a.;%) Source: Appendix URBAN MOBILTYDEMAND EXPLODES 2,6 x 3 bn The number of vehicles on the road worldwide is projected to triple, to as many as 3billion by 2035. 37,2% From1995 to 2013public transportation ridership increased by 37,2%,exceeding the 22,7%growth rateof the U.Spopulation 42 h 42 hours a year are spent in a traffic jam (USA). 106h 106 h/year on average spent on urban travel. 149min on public transport each day. 2 x The world’s current total of 1,2 billion cars could double by 2030. 10,8 bn In 2014, people took a record -breaking 10.8 billion trips on public transport. 40% of inner-city traffic consists of vehicles looking for a parking space. 38min 38 minutes (26 %) of which is spent idly waiting for the bus or train to arrive. 40% with a 40 % dissatisfaction rate. Private traffic Public transport New York +68% +55% Travel problems
• 6.
  Current options Type oftransport Government role Challenges Increasing costs Traffic jams and curfews Privatecars Mismatch between supply and demand Publictransport Limited and expensive parking Heavyrestrictions NO SINGLE SOLUTIONEXISTS Heavysubsidies Urban pollution Huge amount of disparate service providers Inefficient due to single passenger jurneys Low usage vs cost Cost ofownership More time spent on public transport than ever Extensive planning required Cost ofoperation Urbanisation Current options Travel problems
• 7.
  The MaaS solution Freedomfrom ownership A singleapp Increased efficiency Access to all transport without the need to own a car Hassle free One intuitive app to manage your travel needs User friendly Increased utilisation rate AND route optimisation WITH on-demand routing Saves money
• 8.
  … AND TAILOREDTO YOUR NEED AS MONTHLY PACKAGES? Our product - transport sold by monthlysubscription WHAT IF ALL TRANSPORTATION WAS CONVERGED…
• 9.
  9 We want to: •Give you back 90 minutes to your day • Make sure you have full freedom of mobility • Take away the pain of ‘how do I get there’ • Make sure you’re not a polluter • Under a simple pricing scheme Introducing Whim: the first mobility operator service
• 10.
  Perhaps the more INTERESTINGBIT So how are we making this happen?
• 11.
  System Goals Goals • Scalable, cloud-based • Mobile-first customer experience • Utilizing readymade cloud APIs • Infrastructure-as-code • Establish industry standard APIs where they don’t exist yet • Open for ecosystem partners • Create enthusiasm in the wider ecosystem – enable e.g. Universities and smaller developer houses around the world Non-Goals • Closed architecture or lock-ins (except AWS) • Exclusive deals • Server infrastructure • Intermediate, all- encompassing frameworks • Something for everybody
• 12.
  Loosely coupled MicroserviceAPI integrations – flexible inclusion into MaaS framework Routing Traffic Operator Traffic Operator Traffic Operator Transport Operator Weather Subscription Payment Identity Generic Rule Engine Customer Support Whim backend APIGW Whim Apps
• 13.
  MaaS tech Mission:Build a “Transport AI” Anticipation, Service Optimization “Transport AI” BETTER SERVICE, HIGHER UTILIZATION
• 14.
  Backend composition –Transport AI and services Transport AI Service Bus DynamoDB TSP Adapter(s) Routers Registry IoT API GW Open Source Project (first focusing on bookings): http://www.maas-api.org RDS Booking Itinerary Geo Profile Store
• 15.
  Tech Stacks iOS MaaS Core Android Swift Java AWS SDK AWS IoTCognito … Lambda (Node.js 4.x, ES6) Serverless AWS Components* REST APIs Apps Backend Integrations BPMN-js MaaS-API SBUS * APIGW, S3, DynamoDB, RDS (psql), Route53, IoT, Cognito, CloudFront, CloudWatch, SNS, Kinesis, ML, SWF, IAM, ACM… SWF background processing SNS
• 16.
  Serverless Project DeploymentWorkflow Serverless w/ CloudFormation autoinstall meta mocha Webpack Base toolstack Travis CI PROD-GREEN Unit & integration testing Deploy to test stages PROD-BLUE DEV Manual Continuous Deployment (!) Test harness Depsripts Local test harness
• 17.
  Why cloud-native andserverless Virtual Hardware Cost Set-up time Personnel BEFORE 1 firewall/LB, 2 DB machines, 2 frontends, 3 backends… > $1500/month for 0 users > 1 week just to have an environment, accounts, OS installations, networking rules, databases.. DBA infra engineer Networking, Backups, Updates… Monitoring, Developers Whim 0 EUR to set up, < $100/month to support ~5000 users First routing demo on day 1, capable of scaling to thousands of concurrent users 1 Senior Full Stack Javascript developer Whim took 3 months from project start to launch
• 18.
  Lessons learned Bleeding edge is sharp - Serveless 0.5 migration, with 1.0 coming up -Testing & Deployment & versioning - Remote Teams - Learning curve & Hiring - Unknown failure situations & debugging - AWS limits and weirdness - More effort from Dev at the expense of Ops required
• 19.
  Conclusions Serverless computing was the right model to go for - Effortless scalability - Zero maintenance -Stateless patterns - Isolation - Native Cloud Components - Productivity vs technical debt when scaling … but still a bit rough around the edges.
• 20.
  @pippuri maas.global/jobs
• 21.
  Some Resources • MaaS Transport Service Provider API: https://github.com/maasglobal/maas-tsp-api •Serverless Mocha test plugin: https://github.com/SC5/serverless-mocha-plugin • Autoinstall plugin: https://github.com/kennu/serverless-plugin-autoinstall • Meta Sync plugin: https://github.com/serverless/serverless-meta-sync • Webpack plugin (fork) for faster cold starts: https://github.com/laurisvan/serverless-webpack-plugin • Request-promise-lite, smaller version of request-promise to keep Lambda size down: https://github.com/laurisvan/request- promise-lite • Watch this: Serverless v1.0 boilerplate https://github.com/SC5/sc5-serverless-v1-boilerplate • Knex / Objection.js for easy ORM on Nodejs: http://vincit.github.io/objection.js/ • Zenhub for Github issue management on steroids: https://www.zenhub.com/product