Building a serverless 'positive chat' and why products and teams are important

Transcript

1. © 2019, Amazon Web Services, Inc. or its Affiliates. Danilo

   Poccia Principal Evangelist, Serverless @danilop danilop Building a serverless “posi1ve chat” and why products and teams are important

2. © 2019, Amazon Web Services, Inc. or its Affiliates.

3. 2013

4. © 2019, Amazon Web Services, Inc. or its Affiliates. HTTP

   protocol Client Server Request Response

5. © 2019, Amazon Web Services, Inc. or its Affiliates. WebSockets

   protocol GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat Client Server Request Response WebSocket

6. © 2019, Amazon Web Services, Inc. or its Affiliates. Serverless

   Real-Time Apps – There are a few op5ons • AWS IoT Core without physical devices • MQTT pub/sub • AWS AppSync • GraphQL subscriptions • Amazon API Gateway • WebSocket connections New

7. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon

   API Gateway – WebSocket APIs Amazon API Gateway Connect function Web browser AWS Cloud Region WebSocket connection (stateful) Disconnect Connect By Route Key(s) Default Disconnect function Route Key function(s) Default function API Gateway integration (stateless) SigV4 POST @ConnectionId ConnectionId ConnectionId

8. © 2019, Amazon Web Services, Inc. or its Affiliates. Serverless

   Real-Time Apps – What to build? • Building a chat is the mandatory example for WebSockets • Can I build something that can help in being a “better” person? • Not in person communication is hard • Can machine learning help? Some services are super easy to use!

9. © 2019, Amazon Web Services, Inc. or its Affiliates. FRAMEWORKS

   AND INTERFACES ML for data scientists KERAS Frameworks Interfaces APPLICATION SERVICES ML for everyone PLATFORM SERVICES ML for engineers NVIDIA Tesla V100 GPUs (14x faster than P2) Machine Learning AMIs INFRASTRUCTURE Powering the ML Intel Xeon Skylake (Optimized for ML) AW S G R E E N G R A SS M L L E X P O L L Y R E K O G N I T I O N I M A G E & V I D E O T R A N S C R I B E T R A N S L A T E C O M P R E H E N D F O R E C A S T P E R S O N A L I Z E A M A Z O N S A G E M A K E R A W S D E E P L E N S S A G E M A K E R G R O U N D T R U T H & M E C H A N IC A L T U R K S PA R K & E M R

10. © 2019, Amazon Web Services, Inc. or its Affiliates. Let’s

    build a “Positive Chat” J • Avoid negative sentiment • Reject negative sentences • Positive sentiment gamification • Automatically translate between different languages • Extract message topics to improve searchability and discoverability • Create and update a chat room “tag cloud” • Search or filter messages by “tag”

11. © 2019, Amazon Web Services, Inc. or its Affiliates. Let’s

    build a “Posi0ve Chat” J • Attach images to messages • Moderate content • Describe image content (object, people, emotions) • Find text in images • Anonymize people faces • For all people or based on estimated age • Cover faces with emoticon based on actual emotions !"#$

12. © 2019, Amazon Web Services, Inc. or its Affiliates. Positive

    Chat – Serverless architecture Amazon DynamoDB Amazon Cognito Amazon API Gateway WebSocket connection PositiveChat Lambda function Connections table Conversations table Topics table Web browser AWS Cloud S3 bucket for static assets (HTML, CSS, JS) Authentication Authorization To be implemented Amazon Comprehend Amazon Translate Amazon Rekognition To be implemented

13. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Serverless Applica.on Model (SAM) AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetFunction: Type: AWS::Serverless::Function Properties: Handler: index.get Runtime: nodejs8.10 CodeUri: src/ Policies: - DynamoDBReadPolicy: TableName: !Ref MyTable Events: GetResource: Type: Api Properties: Path: /resource/{resourceId} Method: get MyTable: Type: AWS::Serverless::SimpleTable Just 20 lines to create: • Lambda function • IAM role • API Gateway • DynamoDB table O pen Source

14. © 2019, Amazon Web Services, Inc. or its Affiliates. SAM

    CLI sam init --name my-function --runtime python cd my-function/ sam build sam package --s3-bucket my-packages-bucket \ --output-template-file packaged.yaml sam deploy --template-file packaged.yaml \ --stack-name my-function-prod O pen Source

15. © 2019, Amazon Web Services, Inc. or its Affiliates. Demo

16. © 2019, Amazon Web Services, Inc. or its Affiliates. Positive

    Chat Demo • https://pchat.demo.danilop.net/ • https://pchat.demo.danilop.net/?room=CloudConf • https://github.com/danilop/serverless-positive-chat

17. © 2019, Amazon Web Services, Inc. or its Affiliates. $

    wc -l positive-chat/app.js 320 positive-chat/app.js $ wc -l www/index.js 204 www/index.js backend + frontend ≃ 450 lines of code removing empty lines and comments

18. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. “Launch is the starting line, not the finish line… It always takes a lot of listening and iterating and figuring out what customers want before you have something that's truly successful.” – Andy Jassy CEO, AWS

19. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. Projects to products

20. © 2019, Amazon Web Services, Inc. or its Affiliates. v1

    v2 v3 Customer needs Project Product

21. © 2019, Amazon Web Services, Inc. or its Affiliates. Project

    Product Reach milestone Customer value Lifecycle costs Cost to reach milestone Backward looking Forward looking

22. © 2019, Amazon Web Services, Inc. or its Affiliates. Product

    Features Defects Risks Debts Business Customers Security & Compliance Builders Avoid Overutilization

23. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. “One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins.” To our shareowners: This year, Amazon became the fastest company ever to reach $100 billion in annual sales. Also this year, Amazon Web Services is reaching $10 billion in annual sales … doing so at a pace even faster than Amazon achieved that milestone. What’s going on here? Both were planted as tiny seeds and both have grown organically without significant acquisitions into meaningful and large businesses, quickly. Superficially, the two could hardly be more different. One serves consumers and the other serves enterprises. One is famous for brown boxes and the other for APIs. Is it only a coincidence that two such dissimilar offerings grew so quickly under one roof? Luck plays an outsized role in every endeavor, and I can assure you we’ve had a bountiful supply. But beyond that, there is a connection between these two businesses. Under the surface, the two are not so different after all. They share a distinctive organizational culture that cares deeply about and acts with conviction on a small number of principles. I’m talking about customer obsession rather than competitor obsession, eagerness to invent and pioneer, willingness to fail, the patience to think long-term, and the taking of professional pride in operational excellence. Through that lens, AWS and Amazon retail are very similar indeed. A word about corporate cultures: for better or for worse, they are enduring, stable, hard to change. They can be a source of advantage or disadvantage. You can write down your corporate culture, but when you do so, you’re discovering it, uncovering it – not creating it. It is created slowly over time by the people and by events – by the stories of past success and failure that become a deep part of the company lore. If it’s a distinctive culture, it will fit certain people like a custom-made glove. The reason cultures are so stable in time is because people self-select. Someone energized by competitive zeal may select and be happy in one culture, while someone who loves to pioneer and invent may choose another. The world, thankfully, is full of many high-performing, highly distinctive corporate cultures. We never claim that our approach is the right one – just that it’s ours – and over the last two decades, we’ve collected a large group of like-minded people. Folks who find our approach energizing and meaningful. One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there. Outsized returns often come from betting against conventional wisdom, and conventional wisdom is usually right. Given a ten percent chance of a 100 times payoff, you should take that bet every time. But you’re still going to be wrong nine times out of ten. We all know that if you swing for the fences, you’re going to strike out a lot, but you’re also going to hit some home runs. The difference between baseball and business, however, is that baseball has a truncated outcome distribution. When you swing, no matter how well you connect with the ball, the most runs you can get is four. In business, every once in a while, when you step up to the plate, you can score 1,000 runs. This long-tailed distribution of returns is why it’s important to be bold. Big winners pay for so many experiments. AWS, Marketplace and Prime are all examples of bold bets at Amazon that worked, and we’re fortunate to have those three big pillars. They have helped us grow into a large company, and there are certain things that only large companies can do. With a tip of the hat to our Seattle neighbors, no matter how good an entrepreneur you are, you’re not going to build an all-composite 787 in your garage startup – not one you’d want to fly in anyway. Used well, our scale enables us to build services for customers that we could otherwise never even contemplate. But also, if we’re not vigilant and thoughtful, size could slow us down and diminish our inventiveness. 2015 Letter to Shareholders

24. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. What about teams? Photo by Perry Grone on Unsplash

25. © 2019, Amazon Web Services, Inc. or its Affiliates. You

    Build It, You Run It “This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to- day contact with the customer.” – Werner Vogels CTO, Amazon.com

26. © 2019, Amazon Web Services, Inc. or its Affiliates. Team

    size & communication paths = "(" − 1) 2 Communication paths in a team of N people

27. © 2019, Amazon Web Services, Inc. or its Affiliates. Two

    pizza teams Photo by Kristina Bratko on Unsplash

28. © 2019, Amazon Web Services, Inc. or its Affiliates. Separable

    vs complex tasks Separable task Complex task

29. © 2019, Amazon Web Services, Inc. or its Affiliates. Ability

    as a collection of cognitive tools Adam Abilities = 5 { A, B, C, D, E } For example: A – mobile development on iOS B – back end development in Java C – data analytics in Python D – complex SQL queries E – …

30. © 2019, Amazon Web Services, Inc. or its Affiliates. Ability

    as a collec-on of cogni-ve tools Adam Carl Betsy { C, D, G } Abilities = 5 Abilities = 4 Abilities = 3 { A, B, E, F } { A, B, C, D, E }

31. © 2019, Amazon Web Services, Inc. or its Affiliates. Diversity

    bonus model – Team with best abilities Adam Carl Betsy { C, D, G } Abilities = 5 Abilities = 4 Abilities = 3 Team Abilities = 6 { A, B, E, F } { A, B, C, D, E }

32. © 2019, Amazon Web Services, Inc. or its Affiliates. Diversity

    bonus model – Team with more cogni8ve tools Adam Carl Betsy { A, B, E, F } { A, B, C, D, E } { C, D, G } Abilities = 5 Abilities = 4 Abilities = 3 Team Abilities = 7

33. © 2019, Amazon Web Services, Inc. or its Affiliates. No

    diversity, no bonus – Beware hiring managers Adam Carl Betsy { A, B, C, D } { A, B, C, D, E } { B, C, D } Abilities = 5 Abilities = 4 Abilities = 3

34. © 2019, Amazon Web Services, Inc. or its Affiliates. Some

    cognitive tools must be learned in order Adam Carl Betsy { A, B, C, D } { A, B, C, D, E } { A, B, C } Abilities = 5 Abilities = 4 Abilities = 3

35. © 2019, Amazon Web Services, Inc. or its Affiliates. 2,092

    people who worked on 474 musicals from 1945 to 1989 Small world networks & creativity AJS Volume 111 Number 2 (September 2005): 000–000 PROOF 1 ᭧ 2005 by The University of Chicago. All rights reserved. 0002-9602/2005/11102-0003$10.00 Thursday Oct 13 2005 11:31 AM AJS v111n2 090090 VSJ Collaboration and Creativity: The Small World Problem1 Brian Uzzi Northwestern University Jarrett Spiro Stanford University Small world networks have received disproportionate notice in di- verse fields because of their suspected effect on system dynamics. The authors analyzed the small world network of the creative artists who made Broadway musicals from 1945 to 1989. Based on original arguments, new statistical methods, and tests of construct validity, they found that the varying “small world” properties of the systemic- level network of these artists affected their creativity in terms of the financial and artistic performance of the musicals they produced. The small world network effect was parabolic; performance in- creased up to a threshold after which point the positive effects reversed. Creativity aids problem solving, innovation, and aesthetics, yet our un- derstanding of it is still forming. We know that creativity is spurred when diverse ideas are united or when creative material in one domain inspires or forces fresh thinking in another. These structural preconditions suggest 1 Our thanks go out to Duncan Watts; Huggy Rao; Peter Murmann; Ron Burt; Matt Bothner; Frank Dobbin; Bruce Kogut; Lee Fleming; David Stark; John Padgett; Dan Diermeier; Stuart Oken; Jerry Davis; Woody Powell; workshop participants at the University of Chicago, University of California at Los Angeles, Harvard, Cornell, New York University, the Northwestern University Institute for Complex Organizations (NICO); and the excellent AJS reviewers, especially the reviewer who provided a remarkable 15, single-spaced pages of superb commentary. We particularly wish to thank Mark Newman for his advice and help in developing and interpreting the bipartite-affiliation network statistics. We also wish to give very special thanks to the Santa Fe Institute for creating a rich collaborative environment wherein these ideas first emerged, and to John Padgett, the organizer of the States and Markets group at the Santa Fe Institute. Direct correspondence to Brian Uzzi, Kellog School of Man- agement, Northwestern University, Evanston, Illinois 60208. E-mail: Uzzi@northwestern.edu

36. © 2019, Amazon Web Services, Inc. or its Affiliates. 1.

    Write less code, be serverless 2. Build products not projects 3. Experiment, measure, learn 4. Give teams ownership and autonomy 5. Minimize communication paths 6. Maximize different abilities 7. Mix new and existing relationships

37. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. Thank you! @danilop danilop