Functions, monitoring, messaging, many managed services
Audience check
I’m not here to tell you that monolithic apps are bad. In fact, nice and simple.
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.
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?
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
There are many definitions, but these are the basic requirements
(anyone know what this image is? …. A serverless data center. Haha.)
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
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
Event source of all kinds fires functions, which then call into other services as needed
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
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
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
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
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
Use cases: User sentiment analysis, Credit card fraud detection, Product recommendations, Crime detection, etc.
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
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
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
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?