Why serverless will revolutionize your software process.

Editor's Notes

• #5: 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?
• #6: 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
• #7: 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
• #8: 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…
• #9: 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
• #10: This is the key to why serverless is different. You focus on your business logic and not the machinery under it.
• #11: 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
• #12: 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…
• #13: 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…
• #14: 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.
• #16: 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
• #17: 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!
• #18: 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…
• #19: 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.
• #21: 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.
• #22: 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
• #23: 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.
• #24: 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…
• #25: 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!
• #26: 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.
• #27: 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
• #28: 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
• #29: 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.
• #30: 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
• #32: 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
• #33: 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
• #34: 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
• #35: 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.
• #36: 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
• #37: 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.
• #38: 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
• #39: 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