This is part two of the Dominant Designs, a series of articles taking an in-depth look into the emergence of 4 different dominant designs in software engineering and how to recognize them in an acquisition.
_____________________________________________________________
“ The feasibility of creating scalable applications within this architecture is huge. Imagine having the ability to simply write code, upload it, and run it, without having to worry about any of the underlying infrastructure, setup, or environment maintenance…”
- Beginning Serverless Computing, Maddie Stigler
Last time around, I explained what dominant designs are, how they emerged in software engineering, and what the microservices architecture is (it’s one of the four dominant designs). This time, we take a look at another equally important design — serverless computing.
Related: Dominant Designs in Software Engineering: Microservices Architecture
What is Serverless Computing?
“In the cloud” has become quite a common phrase these days, some might say it has become dominant even.
As consumers, “in the cloud” usually just means storing our holiday pictures on iCloud and using Dropbox to share files but as producers, “in the cloud” is a design philosophy that focuses more on app development and less on deployment by taking many of the burdens and responsibilities away from the producer and automating them. If we take this philosophy and apply it to software engineering, we get the serverless architecture.
Under the serverless computing model, businesses choose Function-as-a-service (FaaS) platforms like Lambda, Azure, and GCF that run the application for the business. Unlike traditional implementations, the application in a serverless architecture runs only when someone requests it (instead of running always).
In a serverless architecture, the developer use triggers (triggers are used to define events) to tell the system when to respond, similar to a “if this happens, do that” arrangement.
Each time someone requests a serverless function, the server loads it up and processes the user’s requests. When there are a lot of people making requests, the platform automatically scales up to keep up with that demand and scale down when the number of requests decreases. Neat, isn’t it?

Another thing to note is that serverless doesn’t mean there are no servers involved at all because servers do exist in a serverless implementation. It’s just that the enterprise itself doesn’t own or run the servers themselves and the servers hosting serverless functions only are on for the duration of the function running. This actually has a lot of benefits (more on that later) but it’s similar to renting just a floor of a well-furnished building instead of buying an entire unfurnished building (buildings being the servers in this comparison). This helps businesses save on costs related to security, maintenance, and rent.
So in a nutshell, serverless computing is an arrangement where the enterprise hosts its software on a third-party FaaS or BaaS instead on its own servers. The key benefit of going serverless is the ability to dynamically turn on functionally on demand. This means that when the server usage is idle, it’s not costing the owner any money while its waiting for requests (because it’s only running when there are requests). Serverless also means that the software team has to worry less about the infrastructure or deployment, which has additional benefits to a company in the form of time and scalability.
How Serverless Computing Became a Dominant Design?
A design becomes dominant when it competes with others in the market and comes out on top. And come out on top, serverless has. In fact, serverless is the fastest-growing cloud service model right now, with an annual growth rate of 75%, according to RightScale’s 2018 State of the Cloud report. And unlike some other dominant designs in software engineering, serverless has already found its way into boardrooms and business plans. According to a recent report, 78% of participants indicated that they would use or plan to use serverless technologies in the next 18 months.

So serverless has become a dominant design because it has already been adopted by a vast majority and is seeing promising growth figures. That’s the how. Now, what about the why?
Why Are Companies Choosing To Go Serverless?
As I mentioned, having to worry less about the deployment is valuable to every enterprise, irrespective of its size. In fact, almost every enterprise will see these 5 benefits in going serverless:
1. Serverless makes deployment much easier
Need to get an app off the ground quickly? Serverless is your friend. When superstar developers don’t have to worry about the infrastructure, they can bring a working version of your application online in days if not hours using one of the many serverless vendors.
Many vendors bundle additional tools and services together that make serverless web apps even more accessible. Having all of these services and their features together in one place helps developers focus on their code and gives them enough autonomy to control the outcome while automating some aspects of the implementation.
2. Companies save a lot of money and time (Pay-per-use)
If time is money, then you’re saving a lot of money and… money by going serverless.
The fact that you don’t need to worry about deployment, future scalability, provisioning needs, and maintaining servers means you spend a whole lot less time on your applications. There are direct costs to all of this involved as well. For instance, less staff is required to run a serverless app than a traditional application, so you save on human resources and your servers don’t have to run all the time so you’re saving on hardware costs as well.
And three magical words: pay-per-use.
It’s what every business owner and executive wants to hear and that’s what serverless is all about. Instead of paying for an entire server that runs all the time, you only pay for the server space your application uses or the time your server application actually runs for. That said, most vendors will charge you per execution of the code instead.
In essence, a serverless implementation will almost always be cheaper than having your own server.
3. Operations can be easily scaled up and down
In 2020, businesses must be scalable. Most startups cannot justify paying the costs associated with having their own server because most of them are in their early stages where every penny counts. So they start slow. But what happens when the product has been validated and the company is ready to grow?
Nothing. If you built your app on a serverless architecture, it simply grows. Automatically.
That’s the beauty of serverless. You don’t need to do anything. The vendor does the scaling up for you. The only thing you need to worry about when the floodgates of users open is, focus on updates, which brings us to…
4. Allows you to focus on the user experience
Updating the software is just as easy as deploying the first version. While it is possible to use serverless computing for a monolithic application, most developers have shifted to a microservices approach which makes updates even easier.
At the end of the day, we’re all here to create great products and services and at the center of any great app is its user experience — and a serverless implementation takes care of your backend which means you can continuously develop and improve your experience without worrying about the backend becoming a bottleneck — something that happened with both Uber and Amazon.
Limitations of Serverless Computing
Serverless is being adopted by developers at an incredible pace but that doesn’t mean it’s perfect. As an executive, it’s important to know the less pleasant side of serverless computing as well. So if you choose to go serverless, here are some things you should know about:
1. Limited control over the infrastructure
This is the direct and obvious disadvantage of a shared infrastructure. There are many benefits to a private cloud but they all come at the expense of control.
2. Significant testing and debugging capabilities
This is a two-faceted problem. First, serverless inherently offers limited testing and debugging tools. Second, it’s much harder to mimic a serverless environment on a private server as there are many other variables in a serverless implementation that make it harder to get an accurate picture of how the application will perform.
It’s not impossible but testing can be harder than it would be in traditional environments.
3. It’s not made for long-running applications
Long-running applications would become costly over time and defeat the purpose of the pay-per-use pricing since vendors charge users on the time their application runs.
4. Vendor lock-in is a thing
Pouring significant time and money into developing a complex application and optimizing it for a particular vendor means you find yourself in a vendor lock where changing vendors can get expensive.
The Three Big Players in Serverless Right Now
Throughout this article, I’ve talked about vendors and platforms you can use to create your own serverless applications but who exactly are they and what do they do? These vendors and platforms are cloud service providers who leverage their established infrastructure to offer a suite of services including serverless computing.
While there are many local cloud service providers available, the market has mostly been cornered by three companies: Amazon, Microsoft, and Google with Amazon having by far the biggest lead. Part of this is because of the enormous infrastructure required to make this business model viable. For this reason, most experts recommend choosing one of these vendors. These vendors scale yields lower costs to their customers — us!
Each company has its own cloud product catalog with different benefits. Let’s take a look at each one in-depth.
1. AWS Lambda
Amazon Web Services is in the pioneer of serverless and is responsible for making serverless mainstream with AWS Lambda. The platform was launched in 2015 and has used its early mover advantage excellently, developing a rather large lead over its competitors in terms of market share. As it stands, AWS Lambda has cornered nearly 60% of the serverless industry — strong going by all accounts.

Part of the reason Lambda has not only maintained but also increased its lead over others is its accessibility. Back when it launched, it only offered support for Node.js but now it has native support for JavaScript, Node.js, Python, Java, Ruby, Go, C#, Virtual Basic, and a few others through Runtime API.
One area where Lambda is unmatched is the infrastructure. AWS has undoubtedly the biggest suite of services, many of which can be integrated with Lambda.
2. Microsoft Azure Functions
A year and half after Amazon launched Lambda, Microsoft introduced its own serverless platform called Azure Functions. Over the years, Azure has become the biggest competitor of AWS Lambda, leveraging its existing infrastructure and customer case of enterprises across the globe.
While Azure Functions can’t compete with Lambda on its portfolio of additional services, it outnumbers Lambda in other places. For instance, it has supported has native support for more languages than Lambda: JavaScript, C#, F#, Python, PHP, Bash, Batch, Node.js, and PowerShell.
Another area where Azure Functions one-ups Lambda is deployment. While Lambda only allows developers to deploy code via a Zip file, Azure supports deployment through GitHub, DropBox, Visual Studio, Kudu Console, Zip, OneDrive as well as through a .zip file.
3. Google Cloud Functions
Out of the three, Google Cloud Functions is the latest in serverless computing but has already captured a sizeable, again leveraging its existing infrastructure and customer base. But despite the market share, GCF is the weakest value proposition. It only has support for JavaScript runtime.
The reason GCF is so popular is that your application can be integrated with any Google services. It also has Firebase support which means your application can respond to a handful of triggers including cloud pub/sub triggers, HTTP triggers.
In terms of deployment options, you can deploy functions directly from a GitHub or Bitbucket repository through Cloud Source repositories as well as through zip files.
Choosing a Vendor

Choosing a vendor requires a considerable amount of thought and due diligence because of vendor lock (it’s hard to change vendors once you’ve established your application on a particular platform). Apart from languages, triggers, deployment options, additional services and tools, executives also need to consider storage construct, performance, and price.
The emergence of local cloud service providers offering FaaS and BaaS means you might be tempted to choose one for your next serverless application but make sure you understand that while scalability is inherent in a serverless application, the level of scalability varies from platform to platform.
In conclusion, AWS Lambda and Azure Functions are the most mature offerings when it comes to serverless platforms and will be the best choice for most businesses. In case you want to explore other options, IBM, another established player in IT, has recently launched its own serverless platform, IBM Cloud Functions. If vendor-lock in is your biggest concern then IronFunctions is a great alternative. It is an open-source serverless computing platform with no-vendor lock-in and deep integration options but it only supports Go. Support for a single language isn’t entirely a bad thing because Go is one of the fastest-growing languages and has already tripled in usage in AWS Lambda (which started supporting the language very recently).
Finding Business Value in (Migrating to) Serverless
Throughout this article, the efficiency of serverless has become apparent. Businesses can easily save thousands of dollars and irreplaceable hours by building their software on a serverless platform.
But it’s not everyone.
Applications that run in short-bursts and those that do not require extensive testing and debugging can make the most out of a serverless program. Similarly, applications with a user base that’s spread out across the globe are likely to perform better on a serverless platform than they would on a local server.
If your application has any of these key characteristics, then serverless is for you.
This is the second article in Dominant Designs, a 5-part series of articles taking an in-depth look into the emergence of 4 different dominant designs in software engineering and how to recognize them in an acquisition.