Blog

Function as a Service (FaaS) is a growing trend in cloud computing. It's an opinionated approach to helping users write cloud applications that scale. A central tenant of cloud functions (and what really makes them effective) is their stateless nature. They handle requests then disappear. Nothing is ever permanently "on" which is why they're so cost effective for the cloud provider to host and manage.

Of course, there are times when it does make sense to handle state. But this does not mean you should clutter your stateless function code with state-related functionality. This is better left to an orchestration engine or similar event-driven strategy that is external to your cloud function. This gives you a proper separation of concerns between what is stateless and what is not (which is what you're really after with serverless architectures).

Function as a Service (FaaS) is a common approach to serverless architectures across cloud vendors. FaaS works because it’s opinionated. Each cloud vendor has their own offering with constraints (AWS Lambda, Azure Functions, Google Cloud Functions, to name a few). What the customer gets in return is true utility pricing and the promise of a scalable architecture built of stateless building blocks.

Successful deployments will require a different mindset than used for monolithic apps. In my situation, I’m tilted towards stitching it all back together, given that I work in integration. Once that monolithic app is broken up into stateless functions, how is it best joined together into something that behaves like the original app?

Disclaimer: Intwixt is a general integration platform, capable of connecting third party services through standard Web APIs. Logos, titles, and descriptions do not imply affiliation or partnership between Intwixt and the respective owner unless otherwise specified.