Let Your Cloud Functions Bloom with Cloud Blossom
The ultimate serverless pattern.
I had cloud functions all wrong.
While I was able to identify emerging anti-patterns, I couldn't quite grasp what the right serverless patterns were.
Cloud Functions are an extreme of micro-services; broken down all the way to the level of stateless snippets. But they come with the added caveat that how long they run for, how they interact, and how they are accessed all affect your billing.
I understood how this could go wrong but it wasn’t until taking in 10 hours of talks on Cloud Functions at Google Cloud Next '18 that I saw how it could go right.
Pub Sub as the 💓 Heart
If you are on GCP, Cloud Pub/Sub is the heart of your cloud functions. Maybe even the heart of your entire architecture.
Cloud functions, while accessible via http once enabled, should primarily be accessed via events. It’s cheaper and faster, helps ensure single responsibility AND discourages dependencies.
By running cloud functions only off events:
- You ensure they only run when absolutely needed
- Dont encur RTT (round trip time) costs
- Avoid high billing for http access
- Ensure that no cloud function relies on calling another cloud function
- Encourage each function to only be responsible for a single event and hence responsibility
With this philosophy in place, a new architecture emerges with several pieces of logic all acting independently, I call this The Cloud Blossom Pattern
The Cloud Blossom Pattern
In the cloud blossom pattern, cloud functions only respond to events fired by a centralized publisher, though any service (or cloud function) can publish events.
The diagram above then begins to look similar to a plug-in based Architecture, but the visual similarities is where that comparison ends.
The central component is merely a system of broadcast and, when using a SaaS solution such as Cloud Pub/Sub on GCP, is abstracted almost entirely away from your architecture. It neither processes data nor contains any business logic: All of that resides in your cloud functions.
Much like a flower, the petals on your Cloud Blossom can be shed without the whole flower dying.
This means that events can be added and removed as needed. More valuably, it means that legacy, unneeded and deprecated code will simply fall off the architecture.
If you are then maintaining each function as it’s own repository, this means that as soon as a cloud function ceases to have any meaningful subscriptions, it removes itself from your scope of concern (and what you need to maintain).
Fortunately it’s just as easy to let new elements grow as there is no integration work to be done.
More Patterns
Cloud Functions are still new and there are new architectural patterns and anti-patterns emerging near daily. Feel free to comment below with thoughts or opinions to alternative patterns as well.
