Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Put iOS and Android on the same Wavelength with Serverless Microservices


Published on

This was a talk presented at AnDevCon in Washington DC, July 2017.

For products that are delivered on the Web, iOS and Android, there have been myriad approaches to reducing development time and the duplication of work. Sharing code between major platforms has, in some ways, felt like the search for the holy grail - hope remains, but as of today, has yet to be found. As long as there have been multiple platforms, there has been a desire to write once, deploy everywhere.

In this class, we will look at accelerating cross-platform development by harnessing serverless microservices. At Hootsuite, our serverless experiment uses AWS Lambda functions. This class will cover the motivations of using AWS Lambda compared with other mobile cross-platform solutions. We will also examine the benefits and drawbacks of this approach to cross-platform development. Lastly, you will learn how Hootsuite worked to automate the deployment and versioning of its AWS Lambda function, including its integration it into our existing continuous integration pipeline.

We also share the lessons learned after having an AWS Lambda deployment on iOS and Android running for many months as well as the experimentation with Amazon API Gateway to create an endpoint which invokes the Lambda function, enabling the function to be used by our web-based products as well.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Put iOS and Android on the same Wavelength with Serverless Microservices

  1. 1. Put iOS and Android on the same Wavelength with Serverless Microservices AnDevCon - July 2017 Neil Power @neilpower (and Paul Cowles @paulrc)
  2. 2. @NeilPower INTRODUCTION
  3. 3. @NeilPower ● Mobile Software Developer at Hootsuite. ● Live and work in Vancouver, BC, Canada. ● Previously worked in DevOps at Hootsuite before moving to Mobile development. Who Am I
  4. 4. Hootsuite is the world’s most widely used social media management platform.
  5. 5. 15+ million users 800+ fortune 1000 companies
  6. 6. Nearly 1000 employees across 10+ offices
  7. 7. Hootsuite is a centralized hub for all things social.
  8. 8. @NeilPower
  9. 9. @NeilPower
  10. 10. @NeilPower ● Core Mobile team facilitates mobile development at Hootsuite. ● Dedicated iOS, Android, API and Services, Automation teams. ● Continuous integration and delivery pipeline. ● iOS and Android teams focus on native implementations (Swift/Obj-C and Java/Kotlin). Our Team
  11. 11. @NeilPower Library Driven Development Core team focussed on library driven development and being able to ‘slice’ our app into verticals.
  12. 12. @NeilPower Library Driven Development
  13. 13. @NeilPower ● Culture ○ To work out loud (#workoutloud) ○ Experimentation ○ Innersource / Open Source ○ Giving back to the community Why Am I Here
  14. 14. @NeilPower Culture of Experimentation ● A new mindset: We don’t do projects, we run experiments. ● We build, measure, learn, and repeat. ● For product, change from feature based roadmaps to problem based roadmaps.
  15. 15. @NeilPower Managing Change SERVERTOSERVERLESS
  16. 16. @NeilPower Progression of Servers ● Physical Servers ● Virtual Servers ● Containers ● Serverless
  17. 17. @NeilPower Physical Servers ● Servers in the Basement. ○ No Disaster Recovery 👎 ○ High Maintenance Cost 👎
  18. 18. @NeilPower Virtual Servers ● Servers managed by AWS. ○ Disaster recovery 👍 ○ Lower maintenance cost 👍 ○ Low utilization 👎
  19. 19. @NeilPower Containers ● Servers still managed by AWS. ○ Disaster recovery 👍 ○ Lower maintenance cost 👍 ○ High utilization 👍
  20. 20. @NeilPower Serverless ● Servers managed by AWS (fully hidden) ○ Disaster recovery 👍 ○ Lowest maintenance cost 👍 ○ Higher utilization 👍 (pay per use)
  21. 21. @NeilPower Managing Change APPEXPERIMENTS
  22. 22. @NeilPower Past Experiments at Hootsuite ● Web Views ● Cordova/Phonegap ● React Native
  23. 23. @NeilPower Web Views ● Many limitations. 👎 ● Javascript 👎
  24. 24. @NeilPower Cordova ● Great for quickly prototyping 👍 ● Challenging for complex apps, responsiveness on gestures and touch, and clean crisp animations and transitions 👎 ● Javascript 👎
  25. 25. @NeilPower React Native ● Ends up looking a lot like a fully native app 👍 ● Needs to be stable, avoid temporary workarounds 👎 ● Javascript 👎
  26. 26. @NeilPower
  27. 27. @NeilPower What Should We Try Next? ● Service oriented architecture (SOA), microservices inspired ● Focus lower down the stack, away from the interface ● Develop and debug local, run in the cloud ● Cross Platform - Android first, iOS second, Web third
  28. 28. @NeilPower THEEXPERIMENT
  29. 29. @NeilPower Improved Twitter Search ● Hootsuite enables users to search Instagram and Twitter and save those as streams for future use ○ One of our most popular stream types ● Twitter in particular provides an extensive search API ○ Unless you’re a developer, search syntax is arcane
  30. 30. @NeilPower Twitter Search Syntax ● cats AND dogs AND (fish OR lizards) filter:media -RT min_retweets:10 geocode:49.209389,-120.190909,15mi lang:en -cows
  31. 31. @NeilPower Add a Query Builder ● Query Builder allows Hootsuite users to create complex Twitter searches using a simple graphical interface. ● No longer have to learn and remember Twitter search syntax.
  32. 32. @NeilPower
  33. 33. /
  34. 34. @NeilPower Why Keep it Out of the Client? ● Twitter could change search syntax. ○ We don’t want to redeploy the apps after such a change. ● We want to avoid computation the app side. ● We want to avoid embedded ANTLR runtime in the app.
  35. 35. (((Social OR socialmedia OR #SocialMedia) AND (monitoring OR analytics OR “management tool" OR compliance OR listening OR monitoring OR publishing OR engagement OR infrastructure OR intelligence OR "Social Media Management")) AND (recommendation OR recommendations OR suggestion OR suggestions OR ideas OR thoughts OR suggest OR recommend OR promote OR advice OR "Should use" OR anyone OR Friends OR (What's AND Favorite))) AND -RT -http -from:FiftySocialMedia Real Customer Search
  36. 36. @NeilPower The Tools we Used ● AWS Lambda ● API Gateway ● Terraform ● AWS CLI ● boto ● Gradle ● Jenkins
  37. 37. @NeilPower AWS Lambda ● AWS Lambda is an event-driven, serverless computing platform provided by Amazon. ○ Allows you to run code in the cloud without creating servers or containers.
  38. 38. @NeilPower API Gateway ● API Gateway is a tool for creating and managing APIs. ○ Can be easily integrated with Lambda functions. ○ Manage an API like a RESTful Endpoint.
  39. 39. @NeilPower Terraform, AWS CLI, boto ● Terraform: a tool for Infrastructure as code. Build, change, version infrastructure. ○ Terraform allows the testing and reproduction of infrastructure changes. ● AWS CLI: tool for managing AWS resources through a terminal. ● boto: Python wrapper for AWS CLI.
  40. 40. @NeilPower Gradle ● Gradle is an open source build automation system. ○ Builds off the concepts of Ant and Maven. ○ Used frequently on Android, so natural fit for our experiment.
  41. 41. @NeilPower Jenkins ● Jenkins is a continuous integration application. ○ Used at Hootsuite to power our build pipelines.
  42. 42. @NeilPower HELLOLAMBDA
  43. 43. @NeilPower Experiment Distillation ● A “hello world” for our experiment just for you! ● Available publicly on github. ● We’ve extracted the essence of this talk from our live experiment so that you can play with it yourself after the conference.
  44. 44. @NeilPower / package com.hootsuite.example.lambda; public class SampleLambda { public static String invokeFunction(SampleRequest request) { switch (request.getInput()) { case 0: return "ZERO"; case 2: return "TWO"; case 3: return "THREE"; default: return "GREATER THAN ZERO"; } }
  45. 45. @NeilPower How It Fits Together
  46. 46. @NeilPower How It Fits Together Build Zip, Upload to S3
  47. 47. @NeilPower How It Fits Together Push artifact from S3 to Lambda
  48. 48. @NeilPower How It Fits Together Clients invoke Lambda
  49. 49. @NeilPower How It Fits Together
  50. 50. @NeilPower How It Fits Together
  51. 51. @NeilPower Test Locally JUnit tests hit the local code.
  52. 52. @NeilPower Creating AWS Infrastructure ● Now we have an artifact built by Gradle ● We need to create the AWS Infrastructure ○ AWS Lambda Function ○ IAM resources to invoke and manage the function
  53. 53. @NeilPower resource "aws_lambda_function" "sample_lambda" { filename = "../build/distributions/" function_name = "sampleLambda_${var.env}" description = "A demonstration of AWS Lambda" runtime = "java8" timeout = 10 role = "${aws_iam_role.sample_lambda_role.arn}" handler = "com.hootsuite.example.lambda.SampleLambda::invokeFunction" }
  54. 54. @NeilPower Terraform Plan ● After fully specifying the Infrastructure we need to build it. ● Terraform uses the concept of a “plan” (a dry run) ● Planning allows you to see what changes will be made before making them.
  55. 55. @NeilPower
  56. 56. @NeilPower Push Artifact to Lambda
  57. 57. @NeilPower End to End Testing JUnit tests hit the Lambda Function.
  59. 59. @NeilPower What About Performance? ● Evaluated before committing to the approach ● Measured “Hello World” as Lambda - iOS and Android. Consistent? ● Measured actual function as Local vs. Lambda. Difference? Sub second?
  60. 60. @NeilPower
  61. 61. @NeilPower
  62. 62. @NeilPower Platform Min. Time (ms) Mean Time (ms) Max. Time (ms) Std. Deviation (ms) Android 73 120 410 13 iOS 70 130 330 24
  63. 63. @NeilPower
  64. 64. @NeilPower Environment Min. Time (ms) Mean Time (ms) Max. Time (ms) Std. Deviation (ms) CoV Local 14 16 18 1.3 7.9% Lambda 610 740 840 70 9.5%
  65. 65. @NeilPower MANAGINGCHANGE
  66. 66. @NeilPower Client and Server Changes ● Older app builds in the wild, locked in time ● Changing server side APIs can break legacy app experiences ● “Broken app until you upgrade, sorry!”
  67. 67. @NeilPower No App Left Behind ● Lambda supports versions and aliases ● Leverage both to safely support legacy clients while still allowing ability to evolve ● Lock to alias, control mappings to versions
  68. 68. @NeilPower SDKs Versus API Gateway ● Started using API Gateway in iOS to reduce library dependencies ● On Android, helped to lower method count in the app. ● Minimal increase in execution time.
  69. 69. Rest Client
  70. 70. Request
  71. 71. Lambda Function
  72. 72. Response
  73. 73. Rest Client
  75. 75. @NeilPower Start With Automation ● Manual deployment is tedious, automate early ● Other than deployment, nothing else to manage
  76. 76. @NeilPower xkcd: Is It Worth The Time?
  77. 77. @NeilPower Continuous Deployment ● Manage deployment using Gradle and boto ● Jenkins for continuous integration and delivery ● Dashboards show Jenkins job results
  78. 78. @NeilPower LEARNINGS
  79. 79. @NeilPower Development Experience ● The Good ○ Android developers immediately productive in Java. ○ Android developers finally get to use Java 8. ○ Much easier to manage Lambda than virtual server. ● The Challenges ○ Many different technologies (polyglot development). ○ Rather than compilation, Lambda code must be deployed.
  80. 80. @NeilPower The Sweet Spot ● Works well for complex “business logic” ● Adds safety when aggregating or integrating third party services ● Requires network availability, not a fit for offline experiences ● User experience that allows hiding latency by prefetching ● Cross platform requirement
  81. 81. @NeilPower Downsides ● Latency to manage ● Offline use case not supported ● Investment up front to automate deployment hassles (devops) ● Fat AWS SDK on iOS makes REST interface highly desired ● Not a cross platform strategy for entire app, only layer(s)
  82. 82. @NeilPower Benefits ● Sharing across Web and mobile ● If you’re already aligned with microservices, natural mental model ● No servers sitting idle costing you money ● Lambda ideal for low, uncertain or sporadically used services due to pay per use however also endlessly scalable ● Sane way of versioning client server ● Low burden to support MANY versions at the same time ● Encourages encapsulation ● Easy to empower distributed teams
  83. 83. @NeilPower SUMMARY
  84. 84. @NeilPower Summary ● Download the sample repo yourself and run through front to back, we use it as a workshop. ● The cross platform opportunity will continue to be a dream goal and hotly contested in terms of how much it is worth chasing and how to best achieve it. ● Physical servers -> Virtual Servers -> Containers -> Serverless is an interesting journey. ● Cloud functions are a powerful enabler. ● Embrace experimentation as part of your culture. ● Share what you are doing #workoutloud!
  85. 85. Thanks! Questions?