LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
• Director, EHS
• Principle Engineer, Yahoo
• Sr. Engineering Manager, Yahoo
• Solution Architecture, Yahoo
• Yahoo Frontpage
• Yahoo EC Shopping – VIP Box
• Yahoo iOS movies
• Yahoo Finance
• Yahoo News
• IT Head, Puma/Starlike
• SAP IS-Retail
I don’t know
what I don’t
know until I
know it. Ask
• What is serverless?
• What’s different?
• What is the benefits?
• What is the drawback?
Backend as a services (BaaS)
Serverless was first used to describe
applications that significantly or fully depend
on 3rd party applications / services (‘in the
cloud’) to manage server-side logic and state.
Functions as a services (Faas)
Serverless can also mean applications where
some amount of server-side logic is still written by
the application developer but unlike traditional
architectures is run in stateless compute
containers that are event-triggered, ephemeral
(may only last for one invocation), and fully
managed by a 3rd party.
History of Serverless
• 2012 - used to describe BaaS and Continuous Integration services run
by third parties
• 2014 - AWS launched Lambda
• 2015 - AWS launched API Gateway
• 2015 - AWS re:Invent The Serverless Company Using AWS Lambda
• 2016 - Serverless Conference
Let us discuss it from 3 different angels:
Application/services, Infrastructure, and Architecture
Application / Services
Serverless is lightweight event-based
- Google Functions
Application / Services
Google Cloud Functions is a lightweight, event-
based, asynchronous compute solution that
allows you to create small, single-purpose
functions that respond to cloud events without
the need to manage a server or a runtime
• Fully-managed by vendor
• Without managing server system: OS, CPU, memory, network
• Without managing server applications: apache, node.js, configurations
• BYOC: bring your own code. ZIP or code in console
• Request based automatically
• Trigger by events
• Defined by vendors: eg AWS S3, CloudWatch (schedule), Message Queue
• Http/s requests: eg. API Gateway, Webtask
In first version, all three operations are scaled based on
the overall load across them, and state is transferred
in-memory, creating complication around caching
and/or routing sessions to instances in order to
In the second version, each function scales individually
and as-needed. All state is in DynamoDB so there is no
cluster coordination of any sort, at the cost of a small
increase in latency.
• Processes are stateless and share-nothing
• Any data that needs to persist must be stored in a stateful backing
service, typically a database.
• Don’t use “sticky sessions”
• Reduce operational costs
• Infrastructure cost: without pay as it is idle*
• People cost: focus on function development
• Reduce development cost
• BaaS: eg. Firebase, Auth0
• Spend development time on business-specific code
• Maximize iterations
• Minimize dependences: IT Ops, DBAs
• Easier Operational management
• Scaling benefits of FaaS
• Reduced packaging complexity
traffic is uniform and
make good utilization
of a running server,
you may not see this
cost benefit and may
actually spend more
• Vendor Lock-in
• Vendor control
• Startup latency: worst case 3 second for JVM
• Execution duration: 300 second for AWS
• DoS yourself: AWS 1,000 concurrent / second
• Versioning and deployment
• If you have 20 functions for your application, how you handle deployment?
• Any easy way to roll back all 20 functions atomically?
• Testing/Monitoring / Debugging
• Repetition library or codes
Where serverless make sense
• Fast is more important than elegant.
• Change in the application's functionality and usage is frequent.
• Change occurs at different rates within the application, so functional
isolation and simple integration are more important than module
• Functionality is easily separated into simple, isolatable components.
• Each single-function has one action.
• Encapsulates the internal
structure of the application.
• Reduces the number of round
trips between the client and
• Simplifies the client code
• Yet another highly available
• Performance and Scalability
• Wait inline to update the
Asynchronous, Message-Based Communication Benefits
• Decouples the
client from the
• Message buffering
• Flexible client-
• Operational Cost
• Complexity of
Types of inter process commination
Synchronous Request / Response
Asynchronous Notification Publish / Subscribe
Request / async response Publish / async response
• Interface definition language (IDL)
• RAML (RESTful API Modeling Language)
• Two ways of defining APIs
• Top down (API-first approach)
• Bottom up (spec from your codes)
• Versions of a services
• Robustness principles
• General versioning rule. Suggest put this info in the return data.
• Major.Minor.Patch (example: 1.2.331)
• Four common ways to version a REST API
• URI Path
• Facebook: https://abc.com/api/v1/products
• URI parameters:
• NetFlix: https://abc.com/api/products?version=1
• Header Custom Field:
• Azure: x-ms-version: 2011-08-18
• Header Accept Field:
• GitHub: application/vnd.github.v3+json (vnd means vendor)
API Versioning Design Principle
• Should I handle API Versions in Routing Level?
• API Users focus first, URI or Domain name?
• Each API versioning in the same speed?
• How to handle default versioning?
• How to handle specific versioning?
Be conservative in what you do, be liberal in
what you accept from others.
Jon Postel, TCP father
CAP Theorem (定理) - pickup 2 Consistency
Every read receives the most
recent write or an error
Every request receives a (non-
error) response – without
guarantee that it contains the
most recent write
The system continues to operate
despite an arbitrary number of
messages being dropped (or
delayed) by the network between
ACID Model (CA)
• All operations in a transaction succeed or every operation is rolled
• On the completion of a transaction, the database is structurally sound.
• Transactions do not contend with one another. Contentious access to
data is moderated by the database so that transactions appear to run
• The results of applying a transaction are permanent, even in the
presence of failures.
BASE Model (AP)
• Basically Available:
• The database appears to work most of the time.
• Soft state
• Stores don’t have to be write-consistent, nor do different
replicas have to be mutually consistent all the time.
• Eventually consistent
• Stores exhibit consistency at some later point (e.g., lazily
at read time).
• CAP theorem requires to choose between availability and ACID-style
• 2 phases commit should be avoided
• Need a distributed transaction manager to support 2PC
• All distributed systems such Database and queue must support 2PC
• Most modern technologies, such as NoSQL database, does not have 2PC
Event Driven Architecture Example
use events to maintain
materialized views that
pre-join data owned by
Customer Order View
could maintain by
Event Driven Architecture
• Scale: it enables the implementation of transactions that span
multiple services and provide eventual consistency.
• Materialized view: It enables an application to maintain a data
store that contains the result of a query. It may be a join result or a
summary using an aggregate function.
• Handle atomically updating and publishing
• Deal with inconsistent data: change in-flight, materialized view is
not updated yet.
• Handle reverse state
• Handle time-ordered sequence of changes if needed
Atomically updating the database and
publishing an event
• Order Service must insert a row into the ORDER table and publish an
Order Created event.
• It is essential that these two operations are done atomically.
• If the service crashes after updating the database but before
publishing the event, the system becomes inconsistent.
Publishing Events Using Local Transactions
• guarantees an event is
published for each
relying on 2PC
• Potential error-prone
on query job.
implementation if not
Mining database transaction or commit logs
AWS DynamoDB contains
time-ordered sequence of
changes (create, update, and
delete operations) made to
the items in a DynamoDB table
in the last 24 hours
• guarantees that an
event is published
for each update
without using 2PC.
• simplify the
publishing from the
• Transaction log
format is different
to each database
• Complete Rebuild
• Temporal Query
• Event Replay
• Complexity on
• Applications must
“I want to sequence functions”
“I want to select functions based on data”
“I want to retry functions”
“I want try/catch/finally”
“I have code that runs for hours”
“I want to run functions in parallel”
Functions into apps