Introduction to Serverless through Architectural Patterns
- 1. 31 May 2017 - at EPITA Introduction to Serverless through Architectural Patterns 1/18
- 2. Who am I? DevOps @CloudScreener EPITA 2015 Specialised in Systems, Networks and Security Cloud Systems Engineer @Axiad IDS, 2015-2016 Passion for creating products, while learning new technologies @MathieuMailhos Cloud & Ops Enthousiast 2/18
- 3. Context & Introduction I/ Introducing Serverless II/ Architectural Patterns III/ Serverless Framework Demo IV/ Overall Benefits and Drawbacks Conclusion Agenda 3/18
- 4. Adopt the lean startup methodology: Business Hypothesis needs to be validated Only invest time and money on non-risky projects If you fail, fail fast. Then learn and retry. We need less overhead in our development Focus on building the product: Remove the boring and hard part around managing your infrastructure Timing is a major key of success 4/18
- 5. Internet based systems where application process rely on: 1. A combination of 3rd party services: Backend As A Service 2. Remote procedure calls: Function As A Service 3. Rich client-side logic Basically, write scalable code without having to think about details of the container, operating system or infrastructure that run the program Only pay for what you use Connecting APIs to avoid hosting and managing servers Introducing Serverless 5/18
- 6. Provide Hardware by abstracting physical environment Deploy in Months Live for Years Provide OS through Virtual Machines Deploy in minutes Live for weeks Provide Application Environment through Containers Deploy in seconds Live for hours Provide completely abstracted environment through Functions Deploy in milliseconds Live for seconds Infrastructure Abstraction Evolution Datacenter IaaS PaaS FaaS 6/18
- 7. Function As A Service Multiple Providers: AWS Lambda, Google Cloud Functions, MS Azure Functions, IBM OpenWhisk, Twilio Functions, iron.io (on-premise), Galactic Fog (on-premise) Or build your own: http://blog.alexellis.io/functions-as-a-service/ Unit of deployment: A Function Stateless: Running in an ephemeral containers Pricing Model: Pay per execution count and length Scaling & High Availability: Automatic Execute code, without managing servers, based on direct invocations or events Use your own language Zip and upload. Choose the amount of memory you need. RAM, Disk and Processes are not persistent. Do not count on them! Usually, pay per 100ms. Direct consequences of running optimised code Each vendor has its own limits. However, there is no SLA guaranteed (yet). 7/18
- 8. We can find all we need to build our product out there APIs are the new libraries Database, Storage Authentication, Analytics, Messaging, Tooling (Logging, Monitoring…), Artificial Intelligence, As A Service Backend As A Service 8/18
- 9. Standard Web App, All the logic is on the servers Serverless: More logic in the client. Use of multiple services. Implies the need to manage monitoring and security on each component. Web Application Pattern AWS API Gateway / Google Cloud Endpoints: Gateway/Proxy for HTTP Calls. Manage authentication, caching, monitoring, throttling. Update requests on the fly 9/18
- 10. Recurring Jobs: Log analysis, SSL Checks, Backups… Use of a scheduler / source of trigger Multiple notifications channels, log file Automations Event Driven: Processing files upload, Reacting to database key change, New created user… 10/18
- 11. Presenting the Fan Out Pattern Batch Processing Process huge volume of data on a regular basis Non-interactive background job Apply the MapReduce programming model to serverless Speed depends on the number of invoked concurrent functions Save state in any storage / database depending on your data structure 11/18
- 12. Stream Processing Process non-interrupted stream of data in near real-time Handle spiky traffic and message ordering Use of Kinesis or a Message Queueing Service to store data Beware of poisoning messages & be prepared for Lambda failures (DLQ) Then process those data subsets by calling functions concurrently Tune your functions capacities and concurrent calls to keep up with ingest rate 12/18
- 13. Demo Write and deploy your entire serverless infrastructure using only configuration files and functions Handle multiple vendors Serverless Framework https://github.com/serverless/serverless 13/18
- 15. Custom OAuth Authentication Typical use case where 2 functions make you avoid provisioning a server, setting up the system and the development environment, its security, installing a reverse proxy, monitoring it and managing it over time… 15/18
- 16. Overall Benefits and Drawbacks Benefits Costs: Don’t pay for idle, overall less Ops work Scale: Managed by the vendor, no over-provisioning anymore High-Availability: automatic availability zones redundancy Ops: Easy to maintain and deploy Time: focus on code only Greener: shared environment Drawbacks Beware of Vendor lock-in: migrations won’t be easy Multi tenancy problems: security, robustness, performances More front-end development required Stateless changes the way to code, might require additional component Startup latency and network dependencies Debugging, Versioning, Testing and Monitoring can be tricky: need more tools 16/18
- 17. Conclusion Serverless is not a correct approach for every problem since it still has major drawbacks: latency, vendor lock-in… But it is awesome when applied to lean methodology: deliver fast, get feedbacks quickly. Easy to get started: take advantage of the “free tier” plan provided by vendors. Bring huge opportunities for engineers with both infrastructure and development skills. 17/18
- 18. Thank You Question Time! @MathieuMailhos linkedin.com/in/mathieumailhos github.com/MathieuMailhos 18/18