A collection of technologies grouped as Serverless or Function as a Service (FaaS) are bringing us one step closer to the world where non-technical founders can build and run their own highly complex enterprise-level applications at startup-friendly costs.
Some largest enterprises have invested deeply in serverless, including Netflix, Nordstrom, and Coca-Cola.
The inclusive startup founders’ community
One area where this technology is likely to have an enormous impact in the next decade is by empowering a more inclusive founder community. As serverless abstracts away more technical details that require engineers, the face of the startup community will change dramatically. The community’s makeup is changing, as startups will not always need technical founders.
Today, many startups come together with either a) a marketing-oriented founder with a big idea who brings on engineers to build a working prototype or b) engineers with a developed technology who hire a sales team to gain traction in the market. Serverless has a special appeal for the type a) startup teams with more dreams than technical resources.
Tesla is a good example of Type b), founded by electrical engineer Martin Eberhard and software developer Marc Tarpenning. One of their critical turning points in profitability came after Elon Musk hired marketing gurus Hamish McKenzie and Simon Sproule to turn electric cars from slow and boring to rock-star cool.
Harvard Business Review on Tech Giants
On the other hand, there are certainly many examples of type a) that have made it work, despite the complexity. A few of the tech giants that began with “big picture” founders who hired the tech talent they needed to include YouTube (founder Chad Hurley with BA in Art) Oracle (Larry Ellison, a programmer but not a database expert) and Airbnb (Brian Chesky had a Bachelor’s in Fine Arts for Industrial Design).
In the Harvard Business Review, researchers Martin Murmann and Bettina Müller presented their case that the most successful and innovative startups have grown from type b)—a team of technical founders who brought on business experts quickly. The study concluded that “the founder’s choice of employees is crucial for the success of a new venture.” They suggested that type b) often does better because non-technical founders tend to have difficulty judging the technical skills of the teams they hire. In contrast, everyone has an easier time judging their hires’ marketing and business skills.
That’s all in the past. Now the advances in serverless and FaaS have simplified creating and running any web-based application even more than containers and container orchestrators like Kubernetes.
Frenemies or Collaborators? Kubernetes and FaaS
For non-technical founders and cost-sensitive early-stage startups, serverless deployments’ techniques and technologies are more financially responsible and practical because they abstract away the underlying hardware decisions from the design of applications.
Like Docker and containerization did five years ago, serverless is empowering a new generation of entrepreneurs just as client servers in place of mainframes decades before.
While some industry analysts have suggested that serverless may be on the road to replacing Kubernetes and containers, shortly, FaaS providers are counting on Kubernetes to prove the value of serverless options.
While there are certainly lower costs for computing and storage when you pay for functions by the microsecond in serverless architectures, there are many reasons that developers have converged around Kubernetes as their preferred orchestration tool. Evidence includes more than 388,000 comments on the Kubernetes repository in GitHub, giving it the lead as the most discussed repository by a wide margin. Another telling stat is that 60% of those running containers in production are managing those containers with Kubernetes, in a survey by The New Stack.
Too Much of a Good Thing
The other consideration is that serverless may be too efficient in some situations. In a conversation with Erica Windisch, co-founder and CTO of IOpipe.com, she pointed out that serverless’s nearly infinite, nearly instantaneous scalability can be a problem for I/O to components that prefer steady states.
“One of the challenges of building serverless apps,” she explained, “is that building a serverless app that doesn’t scale can be quite hard. Sometimes you’re building an application that needs to talk to something that doesn’t scale well, like a database. Databases are scalable, but have hard requirements for scaling. Maybe my database can support 10K updates per second. That’s great until you get 20K updates per second; your database falls over. With traditional servers, you could prevent that by having your servers fall over first. Serverless doesn’t fall over. That application will not break, but it’s talking about something that might. This is one of the key challenges of combining these two models.”
One of her side projects is creating her private email server, which can handle protocols and email clients that pre-date HTTP and web hosting providers. She said, “Running containers on platforms like Kubernetes or Amazon’s elastic container service (ECS) can do things you can’t do any other way.” Containers easily handle the hard lifting of communications across protocols. She continued, “Containers can then hand off emails to serverless functions to do things like machine learning and things that require a lot of computing and scale-like spam processing.”
Security in the Transitional Phase
Online security is another area that could require a combination of Kubernetes and serverless in coordination, according to Ory Segal, co-founder and CTO of the serverless security firm PureSec.
In a private conversation on Twitter, Segal explained, “A hybrid serverless-container application is feasible, and is something that in some cases might be required. From a security perspective, this means that security should be applied to both components of the application, and depending on the security solution, this might require two different security solutions or one that can be used for both.”
As a caution, he added that this must be handled with great care to avoid exposing more attack surfaces unnecessarily. “Containers and container orchestration are technologies whose natural target audience are IT and Ops—they were created to solve problems related to ease of deployment. On the other hand, serverless is an approach that more naturally fits developers—it completely disregards the underlying platform. It concentrates on ease of development while reducing dev dependency on IT and Ops. It enables rapid development and independence.”
He was confident that the current state of containers + serverless is a transitional phase. “At PureSec, we believe that shortly, most applications will be developed for serverless on the public cloud, as there’s no real justification or need to control or manage the underlying infrastructure. However, some organizations might still use container technologies, for applications with special needs.”
Segal concluded, “Serverless is expected to replace containers in most relevant scenarios, while it will still be used on-premise in certain cases.”
Where Empowerment Begins
Overall, both container orchestration platforms like Kubernetes and cloud infrastructure on-demand in the serverless environment have one common goal: getting great ideas to market faster at lower cost and reduced developer complexity.
This does much more than make it easier to start a company. It encourages and empowers individuals to make a difference in an increasingly turbulent, interconnected world. “A friend of mine does a lot of anti-fascist work and is involved in projects to track down and get these people on the radar sooner. Independent researchers and data scientists work to identify patterns and behaviors. They use serverless technologies to do this at a relatively low cost. If I were doing this with servers, I would probably have a bill of half a million dollars a month. Instead, I can do serverless with a couple of thousand dollars a month. If I wanted to ingest every message on Twitter and scan it for motivations related to terrorism, I could do it for thousands rather than millions. That’s empowering. That really enables people to build tools to fight these kinds of problems.”
That’s where the real strength of these new technologies lie—in making it more likely for big idea founders to solve bigger problems, without getting bogged down in details like cash flows and resource allocations.
The Final Verdict: Serverless and Containers Have Different Areas of Excellence
So yes, they can work together, even if there is some overlap. On Twitter, BG Adrian summed it up as, “#serverless is not killing the container, it solves only one portion of the market, the event-based flows. It is not a 1-1 replacement for containers, as #blockchains is not a 1-1 substitute for databases.” The most significant difference is that serverless is meant for burst, intermittent code, it can instantly scale, but that can be a problem when it’s adding records faster than your database can handle them.
The fact that serverless is charged by the microsecond also means that you don’t want, and won’t be able to afford, serverless code running constantly. Even if you did, the max run time for AWS Lambda functions is 5 minutes. Serverless works well with microservices architectures, running APIs on demand, or processing data streams related to images, where you may need instant scaling capabilities. For intense computes, monitoring an environment, and listening for inputs, that’s where containers excel, and none of that is going away anytime soon.
