Serverless Architecture

serverless-faas-1Serverless Services – What are benefits?

Serverless services sound silly at first glance, yet has their day finally come?
Or as the little boy said, “Look Ma… No hands!” Has our technology advanced so far – have we become so daring – that we are willing to risk our online presence and maybe even our business in a serverless existence?
Functions as a Service or FaaS is a fairly recent development that provides a cloud platform for customers to develop, run and manage their applications without the need for building and maintaining the usual infrastructure.
The history of cloud computing, at least as an idea, goes all the way back to the 1950s. In fact, many of the things that once were considered as science fiction by most people are now fact. Remember 2001, a Space Odyssey’s HAL? Today we’re using Artificial Intelligence for many of the things we take for granted in our daily lives, such as “Googling!”
FaaS is one of the newest developments in cloud computing, first brought it to us with Amazon’s AWS Lambda in 2014. Joining forces with containers and microservices, it is catalyzing even more explosive growth in the world of internet technology than anyone imagined.
It really is stunning just how fast things move in the high tech and information world. As recently as 2009, there was still a lot of concern about whether cloud computing could be secure enough for corporate data. Now we’re banking (literally) on the cloud!
How does FaaS work? Fasten your seatbelt! I have literally never seen anything quite like this. This is like AI, except that’s growing exponentially out of sight, while this is happening right before our eyes. How fast is it growing? There are blog posts being create by IT guys that tell me we’re all having a hard time keeping up!
Take this one, published January 4th of this year, 2017. It’s not even in full prose, just notes!
Let’s just catch our breath and try to define FaaS. What IS Function as a Service? (The IT guys can just read the last paragraph on that site and breathe easy… )
We’ve already noted that it is both recent and rapidly evolving. It allows customers to develop, run and manage their apps without having to build and maintain the necessary infrastructure. We have dared to use the heretofore ridiculous descriptive phrase, serverless services.
Let’s put one thing to rest before it becomes an urban legend or some kind of cyber myth. It’s technically not really serverless. Cloud providers do, of course, run on servers. However, for the end user, it is virtually serverless, because the customer doesn’t configure the server, nor deploy the code on the server nor manage it.
FaaS, aka Serverless computing, is based on event driven computing. In this model, programs perform their work in response to triggering events. A triggering event is any detectable occurrence previously defined as significant to the system hardware or software, in contrast to a time driven events. Event driven architecture can look very complex, but it offers significant advantages in speed, scaling and of course, cost.
In an oversimplified-but-accurate nutshell, event driven computing delivers information exactly when it is needed and it stuff doesn’t break when changes are made like it does in hardcoded systems.
Again, it’s not really serverless, but the FaaS architecture never “sees” a server or VM. It does this by using existing components that are already available on the cloud.
Business logic is implemented as functions, while the cloud provider executes the function following an event, as we have already mentioned. Another way of saying this is that the function is executed only when and exactly when an event occurs, which offers significant benefits to the customer.
Costs go way down, because the function which provides the context and execution is not carried out in a VM, but in a container. Containers are only used when they are needed and then stopped. If a container is not available, it is spun up in seconds when needed and the function is invoked. Billing is in microseconds, rather than a fixed period. Billing is for the time used by the function, meaning that there is even more savings in more efficient code. Furthermore, there is no VM to manage, so operating costs go down..
As author logiclogiclogic put it on CloudRamblings, “Lambda… bills you only for the time the function takes. As a result, the cost … can be 95% less than running a server for the entire month with the container on it. I’m not joking. I have seen some services that were renting servers in AWS costing thousands of dollars reduced to less than $10. The savings can be incredible.”
Scaling is automatic and as required. As mentioned above, containers are spun up as needed and stopped when the function is completed.
Fault tolerance is high, because functions are even triggered, rather than constant. Functions run when they are triggered by events, meaning they are launched in multiple instances, rather than running continuously in the background.
Security is based on only the permissions the cloud provider allows. There are not generic accounts or VMs to secure. A micro-services approach is used, meaning that each function performs one task only, and only when it is called by the event. FaaS is may be considered the next step after containers, in that while it may work in an architecture that used containers as a whole, it works at an even more granular level, without the entire runtime environment of a container required for execution, since the event driven function requires only the code to be executed.
While there are many advantages to FaaS, there are still some things to consider before assuming it will do anything for anybody, including making donuts for the IT guys in service.
It’s not necessarily a good choice when low latencies or long execution times are needed. Also, since FaaS is event driven or asynchonous, it is obviously not suitable for synchonous tasks. Finally, because the calls of the functions are independent of each other, a cache needs to be added in the case where any followup sessions are required by the application.
This is early 2017. AWS Lambda came out in mid 2014. Still basically in its infancy, we can already see huge advantages for the mobile market and the IoT, where little is much. Two killer points are the scalability of micro-services from nothing to infinity and the fact that it is well suited for event driven engineering and asynchronous applications. This technology is likely really just the beginning of something truly astonishing.
When the drawbacks of FaaS are removed, such as portability across different clouds, keeping track of functions, fitting into the DevOps frameworks and some of the points above, such as running an async operation from a synchronous function, etc., we’ll almost certainly have to come up with yet another term, but we will get there and beyond.

Please share your experiences in the comments!

5 thoughts on “Serverless Architecture

Add yours

  1. This kind of technology opens up the doors for smaller companies to do far more than ever before… I love it, yet I have this nagging concern – what if someone really does finally use an EMP or a massive solar flare knocks down the grid. Can we recover from such a catastrophic event with this kind of technology?


  2. It comes down to how you measure “cost”.

    There is certainly more cognitive overhead when you need to consider how multiple microservices interact even though each individual service is easier to reason about. A serverless architecture can’t do much to help here.

    In terms of dollar costs, there is always an inflection point on the dollar cost of a serverless solution such as AWS Lambda versus running similar tasks on your own dedicated cluster.


  3. Hi,
    When you write code, you need some place to run it. The way the vast majority of people run their code is on servers of some type. Either they own them, or they borrow them (some people call these borrowed servers “the cloud”).

    Companies like Amazon have spent billions of dollars developing services that replace portions of what traditional servers would handle. If you develop your code specifically to run on these interesting, but expensive services (like RDS + Amazon Lamba, perhaps) you never have to run a ‘server’ to speak of. Depending on who you ask, you also aren’t allowed to have a traditional database in a ‘serverless’ architecture, even if you don’t run it yourself.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Up ↑

%d bloggers like this: