6 good reasons to use FaaS in your next enterprise app

In the last years, the process of delivering an enterprise-level application (web or mobile) has changed. Nowadays, building a reliable API, back-end and architecture, might not be enough, especially for enterprises which have a healthy competition and demand faster go-to-market resolution metrics. To put it in a specific perspective, development teams need to deploy production-ready code to the web without having to plan, provision, or maintain any infrastructure or computing resources whatsoever. The Function as a Service Model (further as FaaS) might be the answer. Further, we’ll draw a perspective of what is this model about and how you could benefit from its potential.

A bit about the FaaS purpose

FaaS is your “Ace-in-the-Sleeve” when you need a web, mobile or IoT app that is required to adapt and change dynamically, according to the market changes. When done right, FaaS decreases development times by taking the load off your team’s shoulders, therefore, your dev team can rapidly build, deploy and extend your app.

All they have to do is build the code as individual functions and the platform does the rest. You will never have to worry again about forgetting SSH keys or troubleshooting the infrastructure: FaaS will take care of that.

Again, what is all the FaaS about?

Remember all those “Plug-n-Play” devices you’ve been addicted to back in the 2000s? FaaS works similarly to those — however this “Plug-n-Play” concept is related to web-based application production. FaaS might as well become the industry’s standard quite soon as those devices did and there are a few good reasons for that:

Less infrastructure hassle — more time to develop your code

You’d be amazed by how much FaaS can do for you. Even if most of the times it’s behind the scenes, here’s the workload you’re taking off your dev shoulders:

• Storage, network infrastructure or any physical hardware management;
• Resource allocation and managing efforts related to VT and /or containerization;
• Managing Runtime Environments and/or operating systems that support your code;
• Function life-cycle and management efforts;
• Regulatory and Compliance requirements efforts assigned for data privacy and security;
• Efforts related to maintaining your serverless framework or backend engine (designed to execute your functions and optimize the application’s response time).

All of the above are handled by a well-designed FaaS model, supplied by an outsourced provider either a knowledgeable in-house DevOps team. As soon as your SaaS model is applied you get your very own, serverless compute cloud, on-premises or deployed to a provider of your choice, that enables you to upload and execute handcrafted code, instantly.

Still, that’s not all FaaS is about. In contrast with its sibling model, Platform as a Service (PaaS), which provides a similar “there is no server Karl!” approach, FaaS also delivers automatic, flexible and reliable scaling (fully managed by your DevOps Team or your FaaS provider).

In addition to that, you get a precise, per-execution pricing structure, based strictly on how long your functions take to execute — no more money out the window for additional droplets and/or server resources. It’s basically a “What-You-Need-Is-What-You-Get” perspective.

So how does this magic happen?

We’re not going to go full “Steve Jobs” on you and say: “it just works”. Instead, let’s break it down into elements.

The core aspect of FaaS is the Function. It’s obvious really — we all understand this core piece as a single-purpose, reusable piece of code that performs processing of arbitrary data (input), and then returns a result (output). It’s code independent and does what you need it to do and it’s there for a good reason. You could of course use functions within any model, but there is a catch: FaaS took functions to the next level.

Usually, when you build a function for an app, you need to take your scalpel, pry the source wide-open, place your precious code within and deploy it on the server as a permanent resident.

Compared to the traditional, server-based model, FaaS is more similar to an UBER — you call it when you need it and you pay exactly for that ride. Here’s a simple example from Azure Functions — it shows how easy it is to process an HTTP request as a “Function”:

That’s where FaaS aligns with the micro-services architecture since each and every one of your functions acts as a microservice that is at an HTTP request away. This means, your functions, no matter of their origin code, can have their own party within the cloud since they speak the same language (usually JSON) as independent micro-services.

This way, your functions go from zombies that feast on server resources to the “it’s alive” stage, where they can be called from within the app or another function triggered by an event-driven gateway API. Besides the above, here’s what makes FaaS special:

• Integration is a bliss — a well-designed FaaS will remove the integration hassle since you can use any of your functions and/or microservices by simply making an HTTP request.Runs
• Independent and Stateless functions — within a FaaS model any function you build is independent. It does not care of any other currently running processes anywhere in an application and it does not need to hold a persistent state. It’s basically a free agent that can run, even if a part of your app is down;
• Functions are Event Driven — even if they can act as “free agents” they obey your rule and run only when you need them. Again, it’s similar to an UBER ride — you need it, you call it, you get it — the amazing thing here is that you can call them physically or just define a trigger for when a given function is needed;
• Delivers a “Scale to you need” approach — you can scale horizontally like a pro, without the hassle. If you need a function instance replicated, you can do it as many times as you need to ensure that load requirements are met;
• Functions are Short-Lived — this is golden for your memory resources. When a function is done with its assignment, it gets killed and no traces are left in the memory or elsewhere, leveraging resources for other functions that are waiting for an event’s call.

Still, what are the benefits of using a FaaS model?

1. It’s a breeze for enterprises that need to adhere to regulations
   let’s say you want to build a peer-to-peer, currency transaction platform, or a card processing solution. By law, your system must be PCI DSS (Payment Card Industry Data Security Standard) compliant. This means you’ll have to spend from 50 to 80 000 EUR on certification only and if it’s to consider the engineering costs, you might as well set fire to about 200 000 EUR. With FaaS you can opt for a third-party provider that can build and maintain this model for you with far fewer expenses — leaving your development team focused on the app instead of that certification hassle.
2. Just write the code, upload and deploy
   As stated in the previous statement — all you have to do is code. This is the core of FaaS since it’s indeed, quite easy to get started. You will always be ahead of your competition since driving a new feature to market is a bliss. Just write it, publish it to your pre-made platform and voila: you have it before any of your competitors.
3. Top performance with minimum latency
   I know, it sounds as “too good to be true” but it is. When you let a provider (with a good reputation) sweat for your 9.999% of uptime, that’s pretty much what you get — and since your functions are short-lived — you get it at a pretty good bargain.
4. Save a penny and the environment
   As mentioned above, since your app is powered by short-lived functions, resource usage is extremely cost-effective. When there is no need for an “Always on” server consumed by over-provisioned resources, you get an energy-wise and Earth-friendly architecture powering your app.
5. Extend your app faster and more reliable than ever
   When a brilliant idea hits you (let’s say during your morning jog), you’re all set to build, test and deploy it, alongside your application. There’s nothing to get in your way (or your CI/CD pipeline’s way) since FaaS enables progressive feature development, without any lengthy redeployment processes.
6. Scale to the moon and back
   Your app took fire overnight? If you’re not using FaaS — you’re fried! An abundant user influx will simply DDoS your dedicated server and what’s left of your app is a 404-sad page, with no product or service offering. Simply put, FaaS is powered by the fantastic trinity of a hi-load app: elasticity, automation and horizontal scaling.

Besides the above-six, there are plenty of other benefits delivered by a FaaS architecture. We’ll make sure to cover those in other instances of our posts that will describe some use-cases of FaaS and microservice architectures. If you want to be the first to see them, follow us on Twitter, Linkedin or Facebook to be amongst the first to see them, or simply reach us back if you’re in need of a consultation.