Serverless patterns

Editor's Notes

• #5: Functions, monitoring, messaging, many managed services
• #6: Audience check
• #7: I’m not here to tell you that monolithic apps are bad. In fact, nice and simple.
• #8: The problem is, they typically contain a lot of complexity and moving parts, all tightly coupled into a blob of stuff Any one change effectively touches the entire body, and everything needs to be tested. This can be expensive. Typically, features get tacked on, along with bug fixes, and that’s where we end up with these long tails on releases. That’s not the best way to get features and fixes out the door fast.
• #9: Let’s reconsider our microservices example With the containers and the kubernetes and al… there’s a lot here that is really infrastructure In solving our business problems, we care about agility, flexibility, robustness… so the separation of concerns and smaller units of code to deploy are good What if that’s all we cared about?
• #10: Serverless is a further abstraction in the cloud With containers and kubernetes, we are decoupled from the host environment, and can abstract many host environments in a distributed mesh with ease With serverless, we abstract even that away, and focus only on our business logic
• #12: There are many definitions, but these are the basic requirements (anyone know what this image is? …. A serverless data center. Haha.)
• #13: How does it work? Upload your code and configuration Set up a trigger – HTTP or Event or Stream or Timer The platform runs your code in response to the trigger You only pay for compute resources used when your code is running, saving the otherwise idle time of containers or VM’s
• #14: Serverless initially defined “client-rich apps” - heavily relied on third-party, cloud-hosted applications and services, to manage server-side logic and state Database, auth services, even frontend – all effectively vendored in This is sometimes known as BaaS – but “serverless” works too And this is still very much an active definition of serverless Another is FaaS, functions… where the backend is implemented in units of deployable functions… and this is what we are typically talking about with AWS Lambda, Azure Functions, Google Cloud Functions, and Oracle Functions
• #15: Event source of all kinds fires functions, which then call into other services as needed
• #16: Managed serverless platform integrated in OCI Based on open source engine, provides a fully managed means of managing and invoking functions at scale Pay per use, granular billing, fully autonomous
• #17: Key features: Open Source FaaS Engine – based on Fn Project Container Native – Docker is a first class citizen. Packages and runs your functions in lightweight docker containers Function Development Kits – Additional set of libraries in Go, Node, Java, Ruby, Python to simplify function development Triggers – HTTP, Events (from Oracle Cloud services like storage, database, apps like RightNow, NetSuite, etc.), Streams (Kakfa, Event Hub Cloud Service), Timer (Cron) Pay per use – fine grained billing, pay for execution time, not for idle time Advanced diagnostics – Platform provides details metrics and execution logs Secure workload isolation Auto scale Highly available
• #18: Sync – fronted by API gateway, typical backend / web app sort of thing Async – events drive these, this is an eventual invocation… image is uploaded, we need to run a handful of functions and maybe store some resulting data… nothing is blocking on it Streaming – messages coming in froma queue, each of which invoke a function o do something needed
• #19: Async functions start for a reason – in a serverless architecture, that reason is codified and delievered to the platofmr, which in turn invokes your code This informs our patterns from the start… something working with imnages which are uploaded will be triggered on data store events, something monitioring infra restources will fire off of change in infra
• #20: Serverless initially defined “client-rich apps” - heavily relied on third-party, cloud-hosted applications and services, to manage server-side logic and state Database, auth services, even frontend – all effectively vendored in This is sometimes known as BaaS – but “serverless” works too And this is still very much an active definition of serverless Another is FaaS, functions… where the backend is implemented in units of deployable functions… and this is what we are typically talking about with AWS Lambda, Azure Functions, Google Cloud Functions, and Oracle Functions
• #24: Use cases: User sentiment analysis, Credit card fraud detection, Product recommendations, Crime detection, etc.
• #28: Sometimes the choice is obvious – it’s an image archiving application, you’re working with storage events Less obvious is something like data processing – batch jobs, streaming? Execution context will inform the configuration – POC is important… sometimes less memory doesn’t mean less money spent…. More memory means you get more cmpute and network contriuved example, but something that takes 5s with 128MB might run in a half second with 1GB and cost nearly the same
• #29: Try to avoid 3000 line “functions” Better to have 30 loosely coupled, functions than 3 fat ones handling it all Better performance in nearly all models with smaller, more discrete functions Boundaries are easy to trace, the less stuff happening between them the better
• #30: Sometimes the choice is obvious – it’s an image archiving application, you’re working with storage events Less obvious is something like data processing – batch jobs, streaming? Execution context will inform the configuration – POC is important… sometimes less memory doesn’t mean less money spent Don’t conflate applications if you can help it – if overall you need to process events from a database and an object store, separate and simplify
• #31: Cold starts are kind of an overwrought thing… typically, if you are getting run frequently enough, it’s not a problem, and if you are very infrequently getting hit, latency sensitivity is the only thing to worry about. There are tricks around that, but for the most part, do you really care about a few seconds startup if you’re only getting hit a few times a day? Lock-in however is real – the only people we hear claiming that this is a myth start with A and end with S and… that’s where the issue is. Data egress alone should be a consideration when selecting a platform. ** Also keep an eye on services you use and how you interact with them is it a standard, de facto or otherwise? is there an open API?