How we got to where we are? What's Serverless Serverless Principles Pros and cons Serverless architectures Lambda Anatomy Demos AWS SAM Demo By : Ahmed Samir

1. Demystifying
Serverless on
AWS Riyadh User Group

2. Ahmed Samir
Solution Architect Associate
Technical Architect – Banking Sector
12 years experience in IT Field
Development Background in Microsoft stack
Organize Cloud Communities in Riyadh
/in/aseldesouky/ aseldesouky
AWSbelaraby
AWSbelaraby
#AWS_‫بالعربي‬
http://bit.ly/2vbnFH4

3. Agenda
• How we got to where we are?
• What's Serverless
• Serverless Principles
• Pros and cons
• Serverless architectures
• Lambda Anatomy
• Demos
• AWS SAM
• Demo

4. How we got to where we are?

5. Microservices SOA Monolithic
Design Services are built in small units
and expressed formally
with business-oriented APIs.
Services can range in size anywhere
from small application services to
very large enterprise services
including much more business
functionality.
Monolithic applications evolve into
huge size, a situation where
understanding the entirety of the
application is difficult.
Usability Services exposed with a standard
protocol, such as a RESTful
API, and consumed/reused by
other services and applications.
Services exposed with a standard
protocol, such as SOAP and
consumed/reused by other services
– leverage messaging middleware.
Limited re-use is realized across
monolithic applications.
Scalability Services exist as independent
deployment artifacts and can be
scaled independently of other
services.
Dependencies between services and
reusable sub-components can
introduce scaling challenges.
Scaling monolithic applications can
often be a challenge.
Agility Smaller independent deployable
units ease build/release
management, thereby high
operational agility.
Enhances components sharing that
increases dependencies and limits
management capabilities.
Difficult to achieve operational agility
in the repeated deployment of
monolithic application artifacts.
Development Developing services discretely
allows developers to use the
appropriate development
framework for the task at hand.
Reusable components and standard
practices helps developers with
implementation.
Monolithic applications are
implemented using a single
development stack (i.e., JEE or .NET),
which can limit the availability of
“the right tool for the job”.

6. XaaS
Infrastructure as a Service
(IaaS)
Software as a Service
(SaaS)
Platform as a Service
(PaaS)
Container as a Service
(CaaS)
Function as a Service
(FaaS)
base infrastructure (Virtual machine, Software Define Network, Storage attached)
AWS (EC2), Azure
VMmanaged by vendors: applications, runtime, data, middleware, OSes, virtualization,
servers, storage and networking, End users have to use it
Gmail, SAP,
SalesforceIt provides a platform allowing end user to develop, run, and manage applications
without the complexity of building and maintaining the infrastructure
AWS (Beanstalk)
container-based virtualization in which container engines, orchestration and the
underlying compute resources are delivered to users as a service from a cloud
providerAWS (ECS), Azure (ACS)
It provides a platform allowing customers to develop, run, and manage application
functionalities without the complexity of building and maintaining the infrastructure
AWS Lambda

8. Serverless
• Focus entirely on the business logic of your
applications.
• You don't have to think about servers, provisioned
infrastructure, networking, virtual machine etc.
• All this stuff is handled for you by a cloud provider
(AWS in case o Lambda).
• Usually it means, that your application heavily
relies on managed services (like Lambda,
DynamoDB, API Gateway) that are maintained by
a cloud provider and allow you to abstract the
server away

9. Serverless Principles

10. • Use a compute service to execute code on demand (no servers)
• Write single-purpose stateless functions
• Design push-based, event-driven pipelines
• Create thicker, more powerful front ends.
• Embrace third-party services
Serverless Principles

12. • Greater Agility
• Less Operations
• Faster time to market
• Cost growth with your business
• Simplifies packaging and deployment and
requires no system administration.
• Reduces the complexity of software.
• Fits with microservices, which can be
implemented as functions.

13. • Serverless is not efficient for long-running applications
• Vendor lock-in
• Serverless (and microservice) architectures introduce
additional overhead for function/microservice calls.
• To utilize its resources more efficiently, a service
provider may run software for several different
customers on the same physical server (this is also
known as “multitenancy”)
• In practice, it takes some time for a scalable serverless
platform to handle a first request by your function –
Cold Start

14. When to use
Serverless?

15. •No More Servers
•Startups that want to innovate and move quickly
•Low and expected cost
•Less Code
•Scalable And Flexible

16. Serverless Architectures

17. Compute as backend
an approach where a serverless compute service
such as Lambda and third-party services are used to
build a back end for web, mobile, and desktop
applications
The front-end can links directly to the database and an authentication
service. This is because there’s no need to put every service behind
an API Gateway if the front end can communicate with them in a
secure manner for example, using delegation tokens;

18. Compute as backend

19. Use Case

21. A Cloud Guru Architecture details
• The front end is built using AngularJS and is hosted by Netlify.
You could use S3 and CloudFront (CloudFront is a global content
delivery network provided by AWS) instead of Netlify if you
wanted to
• Auth0 is used to provide registration and authentication facilities.
It creates delegation tokens that allow the front end to directly
and securely communicate with other services such as Firebase.
• Firebase is the real-time database used by A Cloud Guru. Every
client creates a connection to Firebase using web sockets and
receives updates from it in near real time. This means that clients
receive updates as they happen without having to poll.

22. A Cloud Guru Architecture
details
• Lecturers who create content for the platform can upload files
(usually videos, but they could be other types) straight to S3
buckets via their browser. For this to work, the web application
invokes a Lambda function (via the API Gateway) to request the
necessary upload credentials first. As soon as credentials are
retrieved, the client web application begins a file upload to S3 via
HTTP. All of this happens behind the scenes and is opaque to the
user

23. A Cloud Guru Architecture
details
• Once a file is uploaded to S3, it automatically kicks off a chain of
events (event-driven pipeline) that transcodes the video, saves new
files in another bucket, updates the database, and immediately
makes transcoded videos available to other users. Throughout this
book you’ll write a similar system and see how it works in detail.
• To view videos, users are given permission by another Lambda
function. Permissions are valid for 24 hours, after which they must
be renewed. Files are accessed via CloudFront.

24. A Cloud Guru Architecture
details
• Users can submit questions and answers to the forums.
Questions, answers, and comments are recorded in the
database. This data is then sent for indexing to AWS CloudSearch,
which is a managed searching and indexing service from AWS.
This allows users to search and view questions, answers, and
comments that other people have written

25. Legacy API proxy
• Systems with outdated services and APIs can be difficult to
use in modern environments.
• They might not conform to modern protocols or standards,
which might make interoperability with current systems
harder.
• One way to alleviate this problem is to use the API Gateway
and Lambda in front of those legacy services.
• The API Gateway and Lambda functions can transform
requests made by clients and invoke legacy services directly

26. Legacy API proxy

27. Hybrid
• The hybrid approach may work especially well if a part of
the existing infrastructure is already in AWS.
• We’ve also seen adoption of serverless technologies and
architectures in organizations with developers initially
creating standalone components (often to do additional
data processing, database backups, and basic alerting) and
over time integrating these components into their main
systems

28. Hybrid

29. GraphQL
• Popular data query language developed by Facebook in
2012 and released publicly in 2015.
• It was designed as an alternative to REST (Representational
State Transfer) because of REST’s perceived weaknesses
(multiple round-trips, over-fetching, and problems with
versioning).
• GraphQL attempts to solve these problems by providing a
hierarchical, declarative way of performing queries from a
single end point

30. Legacy API proxy

31. Compute as glue
we can use Lambda functions to create powerful
execution pipelines and workflows.
This often involves using Lambda as glue between
different services, coordinating and invoking them.
With this style of architecture, the focus of the
developer is on the design of their pipeline,
coordination, and flow of data.

32. Compute as glue

33. Real-time processing
Amazon Kinesis Streams is a technology that can
help process and analyze large amounts of
streaming data. This data can include logs, events,
transactions, social media feeds—virtually anything
you can think of
It’s a good way to continuously collect data that may
change over time. Lambda is a perfect tool for
Kinesis Streams because it scales automatically in
response to how much data there is to process

34. Real-time processing

35. Serverless Architectures
1. Compute as back end
2. Compute as glue
3. Legacy API wrapper
4. Hybrid
5. GraphQL
6. Real-time processing

37. Lambda can be described as Function as a Service (FaaS), where the
functions is the main building block and execution unit. No servers to
manage, no virtual machines, clusters, containers, just a function created in
one of the supported languages
As with any other managed service, provisioning, scaling and reliability is
handled automatically by AWS. This allows us to work on a very high
abstraction level, focus entirely on the business logic and (almost) forget
about underlying resources.

38. Lambda Runtimes
Node.js 10
Node.js 12
Python 3.8
Python 3.7
Python 3.6
Python 2.7
Ruby 2.5
Java 8
Java 11
Go 1.x.NET Core 2.1

39. Lambda Event Sources

40. Synchronous vs Asynchronous

41. Event provides function with the detailed information about the event that has triggered the
execution (for example, Event from API Gateway can be used to retrieve request details such
as query parameters, header or even request body)
Context on the other hand, contains methods and properties that provide information about
the invocation, function, and execution environment (such as assigned memory limit or
upcoming execution timeout).

42. Quick Demo

43. Cold Start
1. Download your code
2. Set up a runtime environment, together with the resources
specified in the Lambda configuration
The exact length of the Cold Start
varies, depending on your code
package size and settings
For that reason it's wise to keep you
code package size as small as
possible
Take care of node_modules size
First Time o idle for a longer period of time

44. Warm Start
after handler execution. For some time, the
runtime remains active and can receive new
events
Warm execution is of course much faster than the cold one
we cannot assume that the function will, or will not be called with a cold or warm start
The time for which the function stays warm is not precisely defined in the documentation
and is actually based on your configuration and actual Lambda usage
If such event occurs, the warm runtime does
not have to be initialized again, it can execute
the handler immediately
If you allow concurrency of your Lambdas, newly created Lambda instances will also start
with a cold start.

45. Initialization vs handler
it's recommended, to store all the initialization code outside of the handler function. All the
initialization (like creating database connection), should be done outside of handler and
just used inside it.

46. ScalingAuto scaling of Lambda functions is handled automatically by Lambda service.
By default, Lambda is trying to handle
incoming invocation requests by
reusing the existing warm runtimes.
This works if the function execution
time is shorter then the time between
upcoming requests
if the time between the events is < the
function execution time, the single
function instance is not able to handle
those invocation requests.

47. ScalingAuto scaling of Lambda functions is handled automatically by Lambda service.
If Lambda receives a new invocation request while all the current runtimes are busy, it will create another
runtime. This new runtime will handle the upcoming invocation request and execute the function code.
Then runtime remains in the warm state for some time and can receive new requests. If the runtime stays
idle for a longer period of time, Lambda terminates it to free the resources.

48. AWS Lambda Limits
1000
Concurrent executions

49. Lambda invocation flow
The invocation request is passed by Load Balancer to a selected Frontend
Invoker, Frontend Invoker checks the request, and asks the Worker Manager for a
sandboxed function that will handle the invocation. Worker Manager either finds a
proper Worker and a sandbox, or creates one. Once it's ready, the code is executed
by a Worker

50. Isolation
The technology that powers this
flow is Firecracker. It's an open
source (link) project that allows
AWS to span hundreds and
thousands lightweight
sandboxes on a single Worker.
https://firecracker-microvm.github.io/
Workers can be reused across
multiple Lambdas and even
Accounts, which allows
the Placement Service to
organize the work to create and
apply the most performant usage
patterns as possible.

51. Pricing – By Region

52. Pricing – Example
If you allocated 512MB of memory
to your function, executed it 3
million times in one month, and it
ran for 1 second each time, your
charges would be calculated as
follows:
https://aws.amazon.com/lambda/pricing/
http://serverlesscalc.com/

53. Orchestrations
AWS Step Functions

54. AWS Step Functions

55. Demo

56. AWS Serverless Application Model
SAM

75. Demo

76. https://cicd.serverlessworkshops.io/
https://github.com/aws-samples/aws-serverless-airline-booking