Successfully reported this slideshow.
Your SlideShare is downloading. ×

Why serverless will revolutionize your software process.

Ad

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
James Beswick, AWS Serverless
October 30, 2019
W...

Ad

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
About me
• James Beswick
• Email: jbeswick@amazo...

Ad

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Hello World

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 38 Ad
1 of 38 Ad

Why serverless will revolutionize your software process.

Download to read offline

Serverless fundamentally changes software development for both enterprises and startups - here's how it impact your process and how you can benefit. Presented at ITNext Summit, Amsterdam in 2019.

Serverless fundamentally changes software development for both enterprises and startups - here's how it impact your process and how you can benefit. Presented at ITNext Summit, Amsterdam in 2019.

More Related Content

Slideshows for you (19)

Similar to Why serverless will revolutionize your software process. (20)

Why serverless will revolutionize your software process.

  1. 1. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. James Beswick, AWS Serverless October 30, 2019 Why serverless will revolutionize your software process
  2. 2. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. About me • James Beswick • Email: jbeswick@amazon.com • Twitter: @jbesw • Developer Advocate – AWS Serverless • Self-confessed serverless geek • Previously: • Software Developer and Product Manager • Multiple start-up tech guy • Rackspace, USAA, Morgan Stanley, J P Morgan • Enjoys comedy, travel, coffee and theme parks…
  3. 3. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Hello World
  4. 4. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. A “HelloWorld!” application Server Operating system Runtime Webserver Code const express = require('express') const app = express() const port = 3000 app.get('/', function (req, res) { res.send('Hello World!') }) app.listen(port, () => console.log(`Listening`))
  5. 5. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. A “HelloWorld!” application - at scale… Server Operating system Runtime Webserver Code Security group Server Operating system Runtime Webserver Code Server Operating system Runtime Webserver Code Availability Zone Availability Zone Availability Zone VPC
  6. 6. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. But I just want to run… res.send('Hello World!')
  7. 7. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. “HelloWorld!” –The serverless way Code exports.handler = async (event) => { return "Hello World!“ }API endpoint Lambda function https://hallo.jbes.dev HalloWereld
  8. 8. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Focus on your business logic, not the infrastructure.
  9. 9. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. It’s about simplicity.
  10. 10. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. A classic web app stack Things to consider: • Vertical scaling • Horizontal scaling • Load balancing • Availability • Security • Maintenance • Monitoring • And… actual features Server Operating system Runtime (PHP, Node…) Web server (Apache, Nginx…) Database (MySQL, PostgreSQL…)
  11. 11. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. https://d1.awsstatic.com/whitepapers/wordpress-best-practices-on-aws.pdf
  12. 12. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Serverless web app architecture AWS Cloud S3 bucket Application table API endpoint Edge location
  13. 13. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Remember that time I built a voting website?
  14. 14. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
  15. 15. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.https://vote.jbes.dev
  16. 16. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.https://vote.jbes.dev
  17. 17. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.https://vote.jbes.dev
  18. 18. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Things I didn’t have to do… Managing load balancers. Managing SSH keys. Monitoring hardware errors. Migrating instances. Migrating data centers. Dynamic volume provisioning. Orchestrating containers. Rotating root admin keys. Configuring subnets andVPCs. Handling datacenter republication. Renewing certificates. Monitoring disk usage. Resizing clusters. Auto-scaling instances. Restarting servers. sudo yum update. Defining network policies. Scheduling operating system updates.Troubleshooting networking. Configuring IP tables.Volume snapshots. Running server healthchecks.
  19. 19. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Agility
  20. 20. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. The time when you know what to build… Beginning of project? End of project? Along the way? Non-stop changes?
  21. 21. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Why does serverless help with agility? Less code, focused on business logic Microservices are more agile Services for common tasks CI/CD, versioning and automation
  22. 22. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. What a serverless application looks like
  23. 23. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. What a serverless application looks like https://iot.jbes.dev
  24. 24. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. What a serverless application looks like
  25. 25. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Serverless applications
  26. 26. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Serverless applications
  27. 27. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Serverless applications
  28. 28. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Application services Machine Learning Internet ofThings Analytics Web/Mobile/DigitalMedia
  29. 29. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How to use serverless
  30. 30. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Common serverless application types Web applications Backends Data processing Chatbots Amazon Alexa IT Automation
  31. 31. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Best practices Avoid lift and shift Focus on events Keep functions small
  32. 32. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Best practices Avoid lift and shift Focus on events Keep functions small Choose the right runtime for the job Treat code like plumbing Find the right place to start
  33. 33. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. rev·o·lu·tion·ize [/ˌrevəˈlo͞ oSHəˌnīz/] verb change (something) radically or fundamentally
  34. 34. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Fundamental changes to development Agility
  35. 35. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Fundamental changes to development Agility Scaling
  36. 36. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Fundamental changes to development Agility Scaling Cost
  37. 37. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Fundamental changes to development Agility Scaling Cost Environment
  38. 38. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you! James Beswick, AWS Serverless @jbesw

Editor's Notes

  • Remember “Hello World”? – One line of code.
    You could write it in any language.
    So simple, it’s often the first line of code any new programmer writes.

    But what does this look like as a web application?
  • If I wanted to run a webserver version of Hello World, this is what it looks like…

    Here I’m running a Node/Express server
    Look at the stack:
    An actual server/instance…
    Operating system
    Runtime
    Webserver
    All of these need patching, maintaining feeding and watering.
    Look at the code:
    Business logic is only 1 line – the rest is overhead
  • Zoom out to run in prod – “Hello World” at scale:
    Need multiple servers for availability, in different geographical areas.
    Security group configuration and VPC
    Probably need an image of the stack so I can deploy more servers, so I have to manage an image now
    What if demand > 3 servers?
    Or much less? Still need >1 server for HA
  • The serverless approach helps developers focus back on the actual code they care about.
    If you look at how this would work as a serverless app…
  • This how we do it serverlessly…

    One Lambda function – containing my one line of code
    Put an API GW endpoint in front
    See this live at https://hallo.jbes.dev

    This simple example is…
    Massively scalable out of the box
    Highly available out of the box
    Secure – can only be called by endpoint, granular perms with IAM




  • This is the key to why serverless is different.
    You focus on your business logic and not the machinery under it.
  • Serverless can make things very simple.
    As an example, I want to focus on web applications, since I know many of us here today write this kind of app
  • This could be a LAMP stack app or any typical web app stack.
    There are actual features you should be writing in your app too!

    Very quickly, in production, you end up with architecture like this…
  • This is a best practices reference architecture for WordPress on AWS but could easily apply to any traditional web app on a server.

    Most of what’s here handles scaling, availability and the machinery of running of the app.
    Hard to manage this without DevOps staff and continuous management/monitoring.

    At scale, and in production, server-bound technology explodes in complexity.
    Compare that to a serverless approach…
  • Single-Page Application - everything in this diagram is related to the actual architecture of the app, not the mechanics.

    Benefits:
    Global scale via CSN
    Automatically load balanced – app resources all downloaded via global CDN
    Interaction via auto-scaled API GW endpoint

    It’s all much, much simpler with serverless.
  • This was published on IT Next.

    The story behind this is that:
    A petition website famously crashed when 5 million people voted over a 3-day period.
    I set out building a replacement – using serverless - but with certain restrictions:
    I only had one hour to build a voting website that could handle 5 million votes.

    5 million  3 days  86,400 seconds in day  about 20 reqs / second

  • And I put an egg timer on my desk and started building my Lambda functions.
    No time to plan – just a Yes function and a No function.
    The front-end was basic, nothing but Bootstrap and I forgot to remove Lorem Ipsum…

    And here it was, after 59 minutes of work!


  • In the article, I describe how I load-tested carefully using Artillery.js
    And how a sustained 1200 votes/min returned all 200s
    A few days after the article was published, the Internet decided to *really* load test the system…

    As I discovered in CloudWatch metrics…
  • Over 1 day, the app received millions of votes per hour.
    I checked the logs and the votes and… it still worked just fine.
    API Gateway scaled up, Lambda scaled up, DynamoDB absorbed the load.
    And so my few dozens lines of code were truly able to withstand massive scale.

    Serverless can scale really well
    - in spiky load situations
    - Or don’t know what traffic to expect.
  • But there are lots of ways to scale, and not every app needs to scale.
    But how else is it useful?

    A common challenge I’ve found as both a software developer and a product manager is around gathering requirements.
  • When do you know what to build?
    Are you in an enterprise using waterfall? You know all your requirements up front?
    Or at the end ?
    Or you discover requirements along the way?
    Or you might find requirements changing frequently and there’s no clear end to the project?

    ---
    Increasingly common to find changing requirements…

    Why?
    Customer needs change more quickly.
    Move towards iterative development.
    Shorter delivery cycles.

    But in traditional app dev:
    Often decisions made early can create inflexibility
    Very hard to architecture at beginning when reqs least understood
  • Less code – typical to find serverless projects can be 50-70% lighter. Why?
    Less code for auth, DB connections/management, boilerplate

    Microservices:
    Monolithic apps are more fragile.
    Microservices – easy to split up work into teams

    Services:
    Many repetitive tasks – Auth, DB handling, session management – can be handled here
    Also baked into platform: monitoring, logging, tracing, etc.

    CI/CD – multiple versions and stages of APIs and services.
    Automation - IaC with CloudFormation and SAM.

  • To see agility, it helps to understand what a serverless app look like in practice.

    You’ve probably heard of Lambda…
    The AWS Functions-as-a-Service offering
    You provide the code and the Lambda service will run it for on demand as needed.
    And Lambda can do cool things like – run this code…
  • Here is a Node snippet that takes the input from an IoT button and publishes to a downstream system.
    Every time the IoT button is pressed, the Lambda function is invoked.
    It will work whether the button is pressed once a year or thousands of times per second.
    We just built an IOT APP!
  • In fact, a Lambda function can be triggered by practically any type of event.
    A file upload
    Http request
    A schedule (cron job)
    Another service within AWS
    A SaaS partner

    And it can interact with almost anything within AWS or externally.
    In this context, a Lambda function is more like glue.
    It’s a mechanism for processing data between different services.
  • Lambda can interact between services like API Gateway and DynamoDB:

    Just by itself, this is a now an API for a CRUD application that’s…
    Creates a massively scalable, high-throughout public API
    Very little code


  • And you can just as easily…
    have it store durable objects in a service like S3
    serve globally over a fast CDN like CloudFront.
    And maybe have the images in the S3 bucket analyzed by Rekognition and store the results back in database




  • The database can trigger another Lambda function…
    Which sends an email
    Or sends messages to a queue

    As you start to build with the different services…
    You write less code
    Create a resilient distributed infrastructure
    Create clearer architectural maps
    Provide more capabilities to your applications.
  • I mentioned Lambda can connect with almost anything with AWS, which means
    full access to the power of machine learning
    IoT
    Analytics
    Media processing
    Web, mobile and digital services
  • Web apps – static sites, complex web apps, SPAs
    Backends – apps and services, mobile, IoT
    Data processing – MapReduce, Batch
    Chatbots
    Alexa – powering voice-enabled apps, Alexa Skills Kit
    IT automation – policy engines, extending cloud services, infrastructure management
  • Lift and shift:
    Transferring a server app to a Lambda function doesn’t give you all the benefits of serverless.
    Focus on the application flow, integrating with serverless services.

    Focus on events:
    Events trigger serverless workflows.
    Functions are ephemeral and stateless, and only come to life in response to an event.

    Keep functions small:
    A function might only be 20-100 lines of codes
    Very large functions usually can be broken down further.
    Try to avoid monolithic functions.
    Code is a liability
  • Runtimes
    Not limited to a single runtime, as with most traditional apps
    Example – mixing runtimes

    Code as plumbing:
    Many new serverless devs produce single monolithic Lambda functions.
    Code should be connecting services
    Be stateless

    The right place to start:
    I started with cron jobs, progressed to data, then web apps.
    Start in the right place for your org, see the value, develop more skills
    While not all applications should be serverless, some part of all apps can be serverless


  • I promised a revolution in my session title…
    I use the word carefully and deliberately.
    Serverless is not an incremental change in the way we develop things – it’s a revolution.
    It radically and fundamentally changes the way developers work.

  • It comes down to 4 fundamental factors.

    Agility:
    How fast a piece of software can change to meet new needs.
    Explosion of mobile apps and consumer interest in technology has accelerated this.

    With serverless…
    Less code
    Apps are a federation of Lambda functions and services
    Lightweight, easily changeable
    No infrastructure to manage
  • Scaling:
    Some applications in the world now have tens of millions of users.
    This scale creates uniquely hard problems to solve that emerge from vast engineering complexity.

    Hard and expensive problem
    Companies face unpredictable workloads and “spiky traffic”:
    e.g. run a TV ad, get slammed with traffic, cannot scale in time because instance scaling is not immediate.
    Even seasoned DevOps engineers can get caught out when traffic higher than ever predicted.
    For startups, it’s an even harder problem.
    How do you build an MVP that can scale to hundreds of thousands of users? In fact, how can that even be an MVP by definition?

    With Serverless:
    provides automatic scaling.
  • Cost:
    Building systems traditionally is expensive
    Hardware, datacenters, operations, many hidden costs of running applications
    Headcount
    Cloud helps enormously but you might still be paying more than you need to.
    Even virtual instances require patching, maintenance, backups, security, etc.

    With Serverless:
    Cost is much more in proportion to usage.
    Easy to apportion cost to projects or individual customers

    EXAMPLE - A Cloud Guru
    Scaled to 40,000 students in 6 months with no servers. Now over 1m students completed.
    Today – 43 microservices, 287 functions, 7.7 invocations/day,
    Cost: <$10k month

  • The environment:
    Huge pressure for engineering talent - doing incredible things with often very few people.
    Small teams often expected to know everything – DevOps, SecOps, FinTechOps, 10x developer, etc.

    Serverless allows small teams to do more by:
    Handling the heavy lifting
    Offering services to offload common functionality
    Letting you focus on features of your software





×