O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.


What is serverless?
What is different?
What is benefits?
What is drawbacks?
Dive into architecture design for serverless.

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo
  • Seja o primeiro a comentar


  1. 1. Serverless Young Yang
  2. 2. About Me • 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 and learn.
  3. 3. Agenda • What is serverless? • What’s different? • What is the benefits? • What is the drawback?
  4. 4. What is Serverless?
  5. 5. 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.
  6. 6. 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.
  7. 7. 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
  8. 8. What’s different?
  9. 9. Let us discuss it from 3 different angels: Application/services, Infrastructure, and Architecture Application/ Services Infrastructure Architecture
  10. 10. Application / Services Serverless is lightweight event-based microservices. - Google Functions
  11. 11. 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 environment.
  12. 12. Infrastructure
  13. 13. Infrastructure • Fully-managed by vendor • Without managing server system: OS, CPU, memory, network • Without managing server applications: apache, node.js, configurations • Functions • AWS Lambda: Javascript, Python, JVM language, C# • Deploy • BYOC: bring your own code. ZIP or code in console • Scaling • Request based automatically • Trigger by events • Defined by vendors: eg AWS S3, CloudWatch (schedule), Message Queue • Http/s requests: eg. API Gateway, Webtask
  14. 14. FaaS vs PaaS
  15. 15. Architecture • Stateless Function • API gateway • Event driven architecture
  16. 16. Stateless function
  17. 17. Shopping Cart Services
  18. 18. 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 maintain state.
  19. 19. Shopping Cart Services in FaaS
  20. 20. 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.
  21. 21. Stateless functions • 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” • https://12factor.net/processes
  22. 22. What is the benefits?
  23. 23. Benefits • 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
  24. 24. Cost Benefits If your traffic is uniform and would consistently make good utilization of a running server, you may not see this cost benefit and may actually spend more using FaaS.
  25. 25. What is the drawback?
  26. 26. Drawbacks • 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
  27. 27. Take Away
  28. 28. 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 cohesiveness. • Functionality is easily separated into simple, isolatable components. • Each single-function has one action.
  29. 29. Part II - Deep into Architectures
  30. 30. API Gateway
  31. 31. Benefits • Encapsulates the internal structure of the application. • Reduces the number of round trips between the client and application. • Simplifies the client code Drawbacks • Yet another highly available component. • Performance and Scalability • Wait inline to update the gateway
  32. 32. Inter Process Communication
  33. 33. Is it Microservice? How to decouple?
  34. 34. Synchronous, Request / Responses
  35. 35. Asynchronous, Message-Based Communication Benefits • Decouples the client from the service • Message buffering • Flexible client- service interactions • Explicit inter-process communication Drawbacks • Operational Cost • Complexity of implementing request/response-b ased interaction
  36. 36. Types of inter process commination One-to-One One-to-Many Synchronous Request / Response Asynchronous Notification Publish / Subscribe Request / async response Publish / async response
  37. 37. Define APIs • Interface definition language (IDL) • RAML (RESTful API Modeling Language) • Swagger • Two ways of defining APIs • Top down (API-first approach) • Bottom up (spec from your codes) • Versions of a services • Robustness principles
  38. 38. API Versioning
  39. 39. API Versioning • 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)
  40. 40. 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?
  41. 41. Robustness Principle Be conservative in what you do, be liberal in what you accept from others. Jon Postel, TCP father
  42. 42. API Maturity Model
  43. 43. Level 0 – HTTP POST requests to its sole URL endpoint.
  44. 44. Level 1 – HTTP POST requests to related resource
  45. 45. Level 2 – HTTP Verbs
  46. 46. Leve 3 - HATEOAS (Hypertext As The Engine Of Application State)
  47. 47. Leve 3 - HATEOAS (Hypertext As The Engine Of Application State)
  48. 48. API Error Handling
  49. 49. • Network timeout • Limiting the number of outstanding requests • Circuit break pattern • Provide fallbacks
  50. 50. Before dive into event driven architecture(EDA)
  51. 51. Something You Show Know • Principles of microservices • CAP Theorem • ACID Model • BASE Model • Challenges of data consistent in distribution systems
  52. 52. Principles of microservices
  53. 53. Not allow to change other microservices’ internal database directly
  54. 54. CAP Theorem
  55. 55. CAP Theorem (定理) - pickup 2 Consistency Every read receives the most recent write or an error Availability Every request receives a (non- error) response – without guarantee that it contains the most recent write Partition tolerance The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
  56. 56. CAP Theorem in distributed network
  57. 57. ACID Model (CA) • Atomic • All operations in a transaction succeed or every operation is rolled back. • Consistent • On the completion of a transaction, the database is structurally sound. • Isolated • Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially. • Durable • The results of applying a transaction are permanent, even in the presence of failures.
  58. 58. 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).
  59. 59. Challenges • CAP theorem requires to choose between availability and ACID-style consistency. • 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
  60. 60. Event Driven Architecture
  61. 61. Event Driven Architecture Example - Step 1
  62. 62. Event Driven Architecture Example - Step 2
  63. 63. Event Driven Architecture Example - Step 3
  64. 64. Event Driven Architecture Example use events to maintain materialized views that pre-join data owned by multiple microservices. Customer Order View could maintain by MongoDB.
  65. 65. Event Driven Architecture • Benefits • 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. • Drawbacks • 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
  66. 66. Achieving Atomicity
  67. 67. 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.
  68. 68. Publishing Events Using Local Transactions Benefit • guarantees an event is published for each update without relying on 2PC Drawbacks • Potential error-prone on query job. • Limited implementation if not sql-style database Atomically
  69. 69. Mining database transaction or commit logs Example: 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 Benefits • guarantees that an event is published for each update without using 2PC. • simplify the application by separating event publishing from the application’s business logic. Drawbacks • Transaction log format is different to each database Atomically
  70. 70. Event Sourcing Benefits • Complete Rebuild • Temporal Query • Event Replay Drawbacks • Complexity on implementation of event store: database plus message broker • Applications must handle eventually consistent data.
  71. 71. Deep into Event Sourcing
  72. 72. Command Query Responsibility Segregation (CQRS)
  73. 73. CRUD vs CQRS CRUD Create, Read, Update, and Delete CQRS Command Query Responsibility Segregation
  74. 74. Event sourcing design principle • Modeling events forces behavioral focus • Modeling events forces temporal focus • Event brainstorming. • Events are immutable • Optimization using snapshots • CQRS
  75. 75. Take away
  76. 76. Data Centric vs Event Centric The source of truth is the data store. First priority: Preserve data The source of truth is the log of events First priority: React to events
  77. 77. One More Thing…
  78. 78. AWS Step Functions https://aws.amazon.com/step-functions/details/
  79. 79. λλ λ DBMS λ λ λ λ λ λ λ λ λ Queue Modern Serverless app
  80. 80. Modern Serverless app
  81. 81. “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
  82. 82. Integration is the problem, not the solution
  83. 83. AWS Serverless WorkShop Material Download link: https://goo.gl/Ugdjsp
  84. 84. References • https://martinfowler.com/articles/serverless.html • https://www.youtube.com/watch?v=U8ODkSCJpJU • https://cloud.google.com/functions/ • https://intl.aliyun.com/forum/read-499 • https://webtask.io • https://blog.fugue.co/2016-01-31-aws-lambda-and-the-evolution-of-the-cloud.html • https://12factor.net/processes • https://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development • https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ • https://www.nginx.com/blog/building-microservices-inter-process-communication/ • https://www.nginx.com/blog/event-driven-data-management-microservices/ • http://raml.org/ • http://swagger.io/ • https://en.wikipedia.org/wiki/Robustness_principle • https://martinfowler.com/articles/richardsonMaturityModel.html • https://www.xmatters.com/integrations/blog-four-rest-api-versioning-strategies/ • http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/ • https://developer.github.com/v3/media/#request-specific-version • https://www.slideshare.net/danieljacobson/top-10-lessons-learned-from-the-netflix-api-oscon-2014
  85. 85. • http://open.taobao.com/docs/api.htm • https://martinfowler.com/bliki/CircuitBreaker.html • http://samnewman.io/talks/principles-of-microservices/ • https://en.wikipedia.org/wiki/CAP_theorem • http://robertgreiner.com/2014/08/cap-theorem-revisited/ • http://queue.acm.org/detail.cfm?id=1394128 • http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html • https://github.com/cer/event-sourcing-examples/wiki/WhyEventSourcing • https://www.slideshare.net/chris.e.richardson/building-and-deploying-microservices-with-event-sourcing-cqrs-and- docker-microxchg-munich-microservices-meetup-2015 • https://msdn.microsoft.com/en-us/library/dn568103.aspx • https://ordina-jworks.github.io/domain-driven%20design/2016/02/02/A-Decade-Of-DDD-CQRS-And-Event- Sourcing.html • https://www.youtube.com/watch?v=LDW0QWie21s • https://www.slideshare.net/AmazonWebServices/announcing-aws-step-functions-december-2016-monthly-webinar- series • https://aws.amazon.com/step-functions/details/ • http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html • www.datawire.io/microservices-vs-soa References
  86. 86. Appendix
  87. 87. Other message protocols / message format • Thrift • ProtoBuff - Protocol Buffers • Apache Avro