AWS recently held a virtual event focused on serverless with two themes: serverless for your organization and serverless for your application. The event addressed some common questions we field from our clients about serverless. Let's recap the insights we gained from the sessions by answering a few of those questions here.
Question: What is serverless?
Serverless architectures allow a development team to implement functionality that delivers business value instead of spending time on the underlying infrastructure. Serverless architectures scale up and down with business demand, in contrast to the past approach — always-on, and maximally provisioned servers. With serverless, development teams focus on business value, while a cloud service provider like AWS focuses on scaling the infrastructure, and your business only pays for the resources used.
Question: Is my business ready to adopt serverless?
The ability to deploy solutions faster builds trust among technologists and product owners, as evidenced by some of the case studies discussed in Adrian Cockcroft's segment posted here on Twitch. Cockcroft, VP of Cloud Architecture Strategy at AWS, calls serverless a "complete reset" and argues that businesses and their tech developers should always start with serverless on app development projects.
Why? He explains one successful case, with project schedule comparisons, showing how a current development project progressed compared to a serverless approach:
|Project Type/Approach||Conventional Project||Serverless "Rescue"|
|Number of people involved||20 people on the development team||Two people building a serverless solution|
|Anticipated Duration and Actual Time Needed||Nine months, and at the 7-month mark it looked like it would extend beyond schedule||A weekend* to get it built and deploy-ready|
(*with some advantages of building upon the requirements-gathering activities already completed through conventional project efforts)
Question: What are the benefits if I adopt serverless early?
Imagine you are the director of IT at a national chain of movie theaters. At one time, your business may have sold tickets, listed movies, and ran concession inventory from a single server on-premise or in the cloud. That server hosting your business-critical applications needs to have enough resources to accommodate those days when an epic, box office hit film is released. To handle those peaks in demand, which might amount to a few hours over a year, the movie theater would have to pay to operate those resources 24 hours a day, 365 days a year.
Here are five benefits to serverless, seen through the lens of a company that owns movie theaters:
1. Autoscaling (up / down) of individual services and jobs
The theaters sell tickets 24 hours a day but experience changes in demand during peak times (night vs. afternoon) or seasons (winter holiday season vs. random March midweek night). Serverless apps can scale up quickly to handle demand during peak hours and scale down during off-peak hours.
2. Speed up deployments of individual services significantly
Roll out updates, fixes, or entirely new features without risking taking down the whole system. Serverless applications favor architectural patterns like microservices. By decoupling app behavior and data into individual functional units that are built and deployed independently, you can reduce the risk of breaking your production environment and disrupting your business.
3. Provide better insight into what services are under load and when
Previously, if the movie theater ran their business on servers running monolithic apps, scaling to handle demand in one area of the business (e.g., ticket sales) meant scaling everything. With a serverless approach, a system can be decoupled and scaled independently. Only the resources devoted to selling tickets would need to be mounted to meet increased sales demand.
4. Run experiments in hours and prototype in days
Suppose the movie theater wants to support a new payment method for ticket sales or to offer promotions like "Two-for-One Tuesdays." The ability to quickly develop and deploy these features or offerings can go from months to hours when the developer's only concerns are implementing business logic.
5. Billing at average compute execution vs. max compute provisioned
Before serverless, developers designed and built workloads to handle peak loads that might happen a few times a year. The theater would pay the yearly costs for the resources necessary to manage the peak demand incurred over a few hours. With serverless, the movie theaters could consume cloud resources in a pay-as-you-go manner. Serverless changes the equation paying for resources provisioned to value delivered by the cloud provider.