Towards Serverless (FaaS) as the next step in Infrastructure-as-a-Service (IaaS) evolution

Jonathan Eisenzopf
Nov 13 · 7 min read

Often called FaaS (Function-as-a-Service), Serverless is the idea that you can deploy and run applications without provisioning or managing servers where:

  • Software functions run in the cloud
  • Functions can be called by other programs or functions
  • Applications be written in any supported language

In a Serverless architecture, servers, operating systems, packaging (Docker), and orchestration (Kubernetes) are abstracted away. It allows developers to focus on development and reduces DevOps and administrator workloads, while leveraging existing CI/CD pipelines.

Serverless functions are usually logical pieces of code served as a RESTful API (or Graph QA, Protobuff, Cap’n Proto, or whatever), but without needing to worry about any of the app server logic or management. It is likely the next step after PaaS.

Source: Sam Kroonenberg, “The Next Layer of Abstraction in Cloud Computing is Serverless,” May 19, 2016.

The Serverless Provider Ecosystem

Amazon was one of the first Serverless service providers with their AWS Lambda functions. They can be written in various languages such as Javascript (Node.js), Python, and Go.

A partial list of serverless cloud providers can be found at https://www.datamation.com/cloud-computing/top-serverless-vendors.html.

Source: VentureBeat

One notable FaaS vendor not included in the image above is Fastly Terarium.

In addition to potentially eliminating Devops and capital costs of managing hardware and/or VMs, current service providers provide true pay-for-what-you-use billing. If applications aren’t being utilizing, you aren’t paying for the infrastructure.

Open Source FaaS

Not every organization is going to hand over IaaS to someone else. There’s an option for you too from Google and it’s called Knative.

Likely the tech behind Google Cloud Functions, Knative supports a number of ingress routers like Gloo, Istio, and Ambassador.

As developers and companies get more comfortable with cloud CI/CD pipelines, RESTful APIs, and cloud orchestration (Kubernetes), I believe that companies will eventually migrate to a Serverless model as they see the value in helping developers become even more efficient and collaborative by worrying even less about infrastructure.

The nice thing about Knative is that is brings all of these concepts together and provides benefits for all the constituencies:

Source: knative.dev

Towards Edge FaaS for Applications

There’s another twist on Serverless that’s emerging, and that’s the idea of deploying cloud functions to the edge. The largest data center provides have at least 45 global points of presence (PoPs), a few of them many more. Combined with regional mobile provider networks, that reach extends even further.

Instead of users traversing the internet to centralized data centers, edge cloud functions can run on-demand on one of these global networks.

One example of the possibilities is the Cloudflare Workers service. This is a FaaS service that utilizes the global Cloudflare network and offers new revenue opportunities for existing fixed assets.

For companies building apps, there’s no need to centralize data centers. Think of this as the Akamai for apps.

Stackpath is another company offering Serverless functions at the edge.

Developers can write discrete functions that run in the Chrome V8 JavaScript Engine and deploy them to the Stackpath network. They claim a startup time of 50ms compared to AWS Lambda 800ms.


Edge IoT FaaS Use Cases

If you extend the concept of FaaS to the Edge not just virtually but physically, we have IoT devices processing streams of data (video feed, sensor arrays, industrial machines).

If you move some of the data pre-processing and monitoring to the edge, it means that some of the work can be performed on-site using smaller industrial computers. Specific functions can be pushed and updated to the (IoT) device(s) instead of embedding fixed software inside an industrial (SCADA) computing unit.

As an example, there are almost 1,400 natural gas compressors across nearly 1.6 million miles of compressed natural gas pipeline in the US.

Source: Homeland Infrastructure Foundation-Level Data (HIFLD)

The majority of these compressors are manufactured by two companies (Honeywell and Emerson).

Many of these compressors are in remote areas and must be manually monitored. In some cases there may be an embedded microprocessor (SCADA) system with proprietary software that can be collected by radio or by an operator plugging a laptop into the industrial sensor. These existing systems are inflexible and are often not secure. That’s why most of them are manned and maintained at an average cost of $250,000 per year per compressor station. By utilizing remote monitoring and control using Edge Computing FaaS enabled computers and electric power vs. natural gas power, one company estimates that unmanned compressor station maintenance costs could be reduced by up to 50%, which represents a $150M per year opportunity.


What comes after Serverless FaaS?

I worked briefly for Netscape on a team that created the web version of Peoplesoft for Chrysler. Part of Netscape’s web server included a compiled Javascript app server, like Node.js today, except in 1996.

Funny enough, Netscape Enterprise Server is still out there as Oracle iPlanet Server. This was the first step towards a vision of a unified web app framework.

Browser Native

Fast forward to 2013. Mozilla created asjms which compiled apps down to Javascript. Epic demoed the Unreal Engine inside Firefox as an example of its capability.

Source: ExtremeTech

Google also developed something for Chrome called the Native Client project, which has been depreciated.

Webassembly (W3C Standard)

Fast forward to today. There is a new W3C Web proposed standard called Webassembly (also referred to as WASM) that allows compiled binary code at near native speed; and it’s already supported by all the major web browsers.

That means that developers can write applications in their favorite language and it will run in the browser if compiled to Webassembly. Over 20 languages are already supported. Many software companies like Unity have already ported their engines to compile to Webassembly and there’s a growing community of resources and contributors. Other examples of ported apps to Webassembly are Doom 3 and Google Earth.

Steve Klabnik @ Cloudflare provides a good background of how it works.

This has also made it possible for other companies like Droplet Computing (founded by a former VMWare and Citrix employee) to run OS native applications inside the web browser (like Microsoft Office) without requiring a full VM.

WASM + WASI

In addition to WASM, there is also a new interface called WASI, which is a system interface that, when combined with WASM, provides system level access in a secure way (much safer than POSIX). When you combine WASM+WASI, it means you pretty much don’t need a full operating system (potentially), but it definitely means that we can move more of the application execution onto the client without worrying about the target OS or browser, which is fantastic.

If web apps are like mainframe apps, maybe WASM+WASI will be like client/server apps (yuck)? In any case, there may soon be little reason to cross compile apps for different operating systems, which I think is probably a good thing.

Solomon Hykes, co-founder of Docker, famously said that “IF WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!”; so wow.

Edge Serverless WASM + WASI?

If you take the concept of Serverless functions running on the edge and WASM, which is essentially a uniform bytecode compiled application, we have the idea of compiled applications running in the cloud across global networks, potentially with less orchestration overhead; maybe. As an example, Fastly recently open sourced Lucet, their edge runtime for WASM, which allows administrators to run compiled applications in the cloud as a service. This potentially eliminates the need for managed Kubernetes clusters, but the possibilities are still unclear and the technology is not yet proven.

Other companies like wasmer.io provide a WASM runtime for various operating systems, allowing you to distribute and run WASM applications anywhere. Additionally, there is an open source project called wasmtime that provides a WASM+WASI runtime to run WASM applications outside the web.

Conclusion

In summary, it’s exciting to see how the industry has evolved over the last 20 years. Edge and Serverless computing options could vastly simplify computing in the future and I’m excited to see how it evolves.

Jonathan Eisenzopf is the Founder and CTO of Discourse.ai and resides in San Francisco, CA.

The Startup

Medium's largest active publication, followed by +540K people. Follow to join our community.

Jonathan Eisenzopf

Written by

Founder and CTO at discourse.ai. Focused on #ai #chatbots #machinelearning #ai #cognitive #neural #psychology #sociology #nlu #nlp #semantics #rdf #owl

The Startup

Medium's largest active publication, followed by +540K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade