A few years ago there were many articles about how containers would mean the end of servers. From a technical standpoint Function as a Service (FaaS) and containers both run on servers. So simple answer no it does not mean the end of servers. I have seen a lot of rumbling around FaaS of late. Those who have heard me speak on automation know I am all about functions and modular blocks. We do need to break code down to simplest terms to encourage innovation and re-use. FaaS has a place in your overall design. Application design continues to pivot away from monolithic design to more micro-service models. FaaS is part of that pie. When considering any of these strategies the same overall design challenges exist:
- Data persistence
- Data gravity
No matter how stateless your environment sooner or later data is involved. There are some exceptions but they are really rare. The internet runs on data. The real value is identification of you as a user and selling that data in mass not the $.99 cents you paided for the app. Applications exist to do something then keep state… or record your reactions either way the data needs to be stored. Pure stateless applications are stateless. FaaS is stateless. So somewhere in the pie we need state. Something to orchestrate the next step and provide the value to user and the developer. Where you store this data depends on the application from a simple text file to a share nothing database someone is keeping the data. Lets just be honest that 90% of the world still lives on a relational database (Oracle, MS-SQL, My-SQL) with a small portion using a share nothing database (Cassandra etc..). This persistence layer has all the same concerns as any other non-immutable infrastructure. If you loose all your copies you loose data. Even with every function of an application as a FaaS you still need a database. The challenge of persistence means you have to live in both worlds a persistent and non-persistent. It’s important to consider the manageability of both these worlds when you consider implementing new technologies.
The idea of FaaS or stateless is I can deploy anywhere… while this is technically true you want your application/functions to be close to that persistent data to ensure performance is observed. Which means you either need to real time replicate data between anywhere you want to operate or operate in the same locality as your stateless / function. No share databases have massive concerns with write amplification, confirming a write across long distances introduces unacceptable latency into every write. Sharding of these databases is touted as the solution using sync writes in the same location for redundancy, sharding is possible it’s a complex and you still have latency when the data needed is not local. Now we have created a MC Escher puzzle with our application architecture. Gravity of data will continue to drive location more than feature / functionality of location. It’s an instant world and no one is going to wait for anything anymore.
While not as interesting as the bling of FaaS security is a real concern. Unless you plan on running your FaaS inside your private datacenter it’s a concern. Your functions have data to do their work in memory. The function is running on a server. Like all multi-tenant situations how do we avoid having a bad or untrusted actor access our data in flight? Anyone who has worked in a multi-tenant provider understands this challenge. Cloud providers have long deployed containers with light weight containers to ensure isolation is present (instead of shared worker nodes). I personally don’t know what measures providers have taken to isolate FaaS offerings but you do have to consider how you will ensure there is not a hacker running a buffer overflow and reading your memory FaaS.
At the end of the day what is old is new and what is new is old. FaaS, containers, virtual machines, physical servers, laptops, phones all have the same fundamental applications challenges. These all provide options. You may be considering a FaaS strategy for many reasons. My point is don’t ignore good design principles just because its new technology.
© 2018, Joseph Griffiths. All rights reserved.