Server-less eats the infrastructure

Sudip Chakrabarti and Barry Eggers

Last Fall, the Australian census website crashed within hours of launching because of heavy traffic. The following weekend, two university students at a hackathon built an unofficial census website that was able to handle 4x the traffic that had crashed the official site. The kicker here? The unofficial site was built for a grand total of ~$400, about $10 million less than what the Australian government had spent on the official site!

The real story here isn’t about governmental waste. It is about what a small team, in a short time and apparently with little prior knowledge of the cloud could accomplish — provided they had the right infrastructure technology — which in this case was AWS Lambda, Amazon’s server-less offering.

Deliver business value, not software

As software eats the world, we routinely fall into the trap of forgetting that the mission of a business is to deliver value to its customers. It is definitely not to write software. Software is simply a means to the end and we should write as little of it as possible. Sad how often we forget that…

Fortunately, software development is going through some fundamental rethinking — breaking away from monolithic applications, long build-test-release cycles, and the inability to quickly incorporate user feedback. The following macro trends, in particular, are fueling that:

• Microservices going mainstream. Once exclusive to the web-scale companies, the microservices architecture is now being broadly adopted by main street developers. Because of the benefits — faster deployment cycles, higher resource utilization and better design autonomy — application development is rapidly moving from monoliths to distributed, service-oriented architectures.
• Rise of open source. Rapidly growing popularity of open source software and shared code repositories (e.g., GitHub) has transformed software development into a community exercise. Today’s developers extensively leverage open source and third party services to incorporate best-in-class technologies and significantly shorten the time to market.
• Successful products demand rapid experimentation. Unlike a few years ago, when a software product would go through year long cycles of design, implementation and testing without any contact with the user, the best products today are built on the foundation of rapid build-measure-learn feedback loops. That is true for startups, and is also for large corporations.

Taking advantage of the above trends, however, requires the right infrastructure. To this day, we remain captive of the infrastructure IT stack we have so painstakingly built over the last couple of decades in which applications were designed to conform to the infrastructure and not the other way around. Yes, we have certainly tried to put lipstick on the pig in the form of containers and DevOps innovations, but that has created more complexity (as Paul Biggar outlines it here). Clearly, the infrastructure we have today is not going to carry us into the next couple of decades once we have billions of devices sending petabytes of data that need to be analyzed and acted upon in real-time or close thereof. What we need is a fundamentally new infrastructure stack that is application first and lets the developer focus on delivering business value.

Enter server-less …

The server-less architecture (aka Function-as-a-service or FaaS) is precisely that next-generation infrastructure that we need.

Introduced by Amazon couple of re:Invent’s ago, the server-less architecture allows developers to run back-end code without having to manage their own server systems or server-side applications. Developers can combine their own code with best-in-class services from others to create applications that they could rapidly release and iterate through user testing.

There are several benefits to server-less architectures. First, abstracting away the infrastructure relieves the developer from the operational complexity of running applications. Second, horizontal scaling is completely automated and elastic. Third, reduced packaging and deployment complexity enables the developer to rapidly iterate through multiple implementations. Finally, with the unit of compute shrinking down to a function (as opposed to a VM or a container), the level of resource utilization is unprecedented and allows the user to pay exactly for the compute she uses.

As a result, the growth in popularity of server-less has been nothing short of phenomenal. The use cases so far have been integration (exposing functions within an application to external callers), event-driven use cases (moving logs from one place to another based on an event trigger), DevOps (CI/CD chron jobs), and data processing. But, as we had seen with VMs and containers (both were initially constrained to dev-test use cases), we expect server-less to soon evolve into more general purpose workloads. In fact, the top public cloud providers estimate that, in 3–5 years, 50–60% of the cloud workload will be server-less. Already, one of the top three cloud providers is experiencing 100%+ MoM growth in their server-less workload. And finally, Google Trends, often a good leading indicator, shows a 20x increase in search popularity for server-less in the last 18 months! Surely, something is afoot here.

The obligatory “but …”

In spite of all its promises, it is important to recognize that server-less is a really young technology and has ways to go before it becomes mainstream.

Of all the limitations server-less has, two stand out. First, server-less functions, as of today, are stateless. State information cannot be passed from one invocation of a function to the next. This constrains the kinds of applications that can be built on a server-less infrastructure.

Second, like any new technology, server-less lacks a mature tools ecosystem. Monitoring and debugging server-less applications is really tricky because of the highly distributed architecture. Ditto for securing. In addition, server-less has some unique challenges — e.g., discovering available functions and stitching those together to build an application — that call for additional tooling.

Having said that, we fully expect the tools ecosystem to mature fast given the strong user interest and the investments that are being made by large cloud providers and small startups alike.

Peering into the crystal ball

Infrastructure abstraction, auto-scaling and better resource utilization alone should make server-less a legitimate success. But, thinking of server-less just as a next-generation infrastructure would be shortsighted. The real opportunity for server-less is much, much larger. In fact, server-less could fundamentally redefine how enterprise software is distributed, consumed and monetized.

As of today, enterprise software is consumed in two primary ways — on-premise installs and SaaS. The onus of running and managing the corresponding infrastructure rests with the consumer (of the software) in the former case, and with the provider in the latter. Server-less, in contrast, does not require either the consumer or the provider to run or manage any infrastructure. This is huge, and it opens up the new possibility to distribute and consume enterprise software through a marketplace. For example, a security vendor could package and deploy its malware detection software as a function on the server-less platform and sell it to multiple different consumers such as a mobile app developer, an IoT device manufacturer and a drone operating company. Those consumers could just call that function and pay for only what they use. Similarly, other specialized services (e.g., machine learning, authentication, payment processing, etc.) could be packaged and monetized in a similar fashion.

Furthermore, server-less could facilitate unbundling of enterprise software and thereby lead to larger monetization opportunities. For example, a chat-ops business could expose its natural language processing capability as a service on the above marketplace and monetize it without taking on the headache of managing the underlying infrastructure. If that happens widely then enterprises will be able to provide and consume software at a more granular level than they ever have.

Finally, as we have argued before, applications are morphing into a tapestry of services with application logic gluing those services together. Some of those services would be built in-house, some would come from another team within the same company, and some from a completely external third party. Additionally, those services could be run on premise, on one or multiple public clouds, or on a combination of all of those (i.e., a hybrid setting). When that happens — and it is happening already — we would need an infrastructure framework sitting on top of all the IaaS providers (public or private) providing service discovery, call routing, and metering (for monetization) regardless of which IaaS each individual service is running on. It is not a stretch to imagine an application running on that framework that calls a machine learning service from GCP, a database service from AWS (or Azure) and a group of internal services from a private cloud. When that happens, the power will start shifting away from the almighty IaaS providers of today to that framework. That will be when server-less will truly end up eating the infrastructure as we know it today!

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!