I recently gave a talk at the local Microservices meetup titled “Microservices in a Serverless World”. In the talk, I contrast microservices and serverless architectures through the lenses of design, tools, and process. I wrap up the talk with a quick summary of where I think things are going from here, which is what I want to elaborate on in this post.
The promise of serverless
I believe that serverless computing (aka “functions-as-a-service” or FaaS) represents a paradigm shift in our industry, as it:
- Drops the barrier to entry
- Slashes the cost to operate
- Requires no specialized OS or hardware knowledge
Traditionally, deploying a software system requires provisioning physical or virtual hardware, installing and configuring the operating system and all of the software that the application needs to run, and then maintaining the whole thing, keeping on top of OS patches and security vulnerabilities.
With serverless, all of that is taken care of. Hardware and the operating system are abstracted away. The serverless host simply provides an execution environment for your code to run in and an interface by which to be triggered¹. Deploying to the environment is a simple process using a web console or a command-line interface. And the environment dynamically scales as the load on your system grows.
Some of these benefits are also available through Platform-as-a-service (PaaS) vendors, but at reasonably high cost. With serverless compute platforms, you pay only for the resources you need when you need them. This means that the costs are dramatically lower — especially for services that run infrequently.
The end result is that anyone who has even a basic ability to write code in one of the supported programming languages can create a service that is incredibly cheap to operate (pay per use) and can scale virtually infinitely.
Anyone who knows a bit of coding can deploy an infinitely* scalable service
The coming wave
Cost and expertise are significant barriers to people building new software services. As those barriers are eliminated, we tend to see an explosion of creativity.
Consider GitHub for a moment. GitHub is the largest repository of open source on the planet. As of 2017, they boast having over 20 million users and over 57 million git repos. GitHub makes it free for any software developer to host and share code for the open source libraries, components and applications that they’ve built. And by making this free, tonnes of people have used the GitHub platform as an outlet of their creativity.
While you can find lots of components and libraries on GitHub, there are far fewer repos for applications and services. I believe that part of the reason for that (aside from their relative complexity) is that applications or services would need to be hosted elsewhere and there can be a non-trivial cost associated with doing so — not to mention the ongoing maintenance overhead.
When the cost and maintenance burden are removed there tends to be flourishing of creativity. A good analogy for this is the Apple App Store. The App Store provides a marketplace to reach lots of users where the cost of hosting, managing and marketing a self-contained application are largely taken care of. This shows as there are currently 2.2 million apps in the Apple App Store.
Serverless removes the compute, maintenance and knowledge burden of hosting applications and services. So this begs the question: where is the marketplace for serverless services?
At this point, I don’t know. But it seems like there is a significant opportunity and I wouldn’t be surprised to see some of the main cloud providers — especially Amazon — moving to fill this void. As someone building a few niche serverless services, it would be great to have somewhere to list the service and get discovered.
Serverless is still very new and changing rapidly. It will be interesting to see how things shake out in the next few years. But I believe it’s impact on the technology landscape is going to be profound.
- Under the hood, your code is running in a dynamically instantiated container that is run within a distributed container management cluster, such as ECS or Kubernetes. That does mean that connecting to it can incur higher latency due to the increased container startup cost, though there are strategies for mitigating that.