Serverless computing, or more simply Serverless, is a hot topic in the software architecture world. The “Big Three” cloud vendors—Amazon, Google, and Microsoft—are heavily invested in Serverless, and we’ve seen plenty of books, open-source projects, conferences, and software vendors dedicated to the subject. But what is Serverless, and why is (or isn’t) it worth considering?

What Is Serverless Architecture?

Serverless architecture, or better yet, serverless computing as it’s also known, refers to applications that are dependent on third-party services and custom code that’s running in ephemeral containers.

Considering its name, serverless architecture doesn’t mean that it runs its code without servers. The name it has, “serverless computing“, is used only because the person or a company owning the system does not have to purchase or rent servers virtual machines for the back-end code to be able to run. Simply put, serverless architecture is a way of building and running applications and services with no need, whatsoever, for infrastructure management.

Our application will still be running on servers, but bear in mind that AWS Lambda or other hosts do all of the server management. We conclude that the user no longer needs to scale, provision, and maintain servers to run his application, database, or storage system.

Why Should We Choose Serverless Architecture?

Using serverless architecture will significantly help developers focus more on their core product. If not for serverless, developers would still be worrying about managing and operating servers or runtimes, whether managing them on the cloud or on-site. This way, the developer’s focus will solely be on individual functions in their application code. Services like AWS Lambda, Google Cloud Functions, Firebase, and Microsoft Azure Functions will take care of the physical hardware, virtual machine operating system as well as the web server, while you would only need to worry about one thing — your code.

A couple of examples:

UI-driven applications:

Let’s think about a traditional three-tier client-oriented system with server-side logic. A good example is a typical eCommerce app—dare I say an online pet store?

Traditionally, the architecture will look something like the diagram below. Let’s say it’s implemented in Java or Javascript on the server-side, with an HTML + Javascript component as the client:

With this architecture, the client can be relatively unintelligent, with much of the logic in the system—authentication, page navigation, searching, transactions—implemented by the server application.

Message-driven applications:

A different example is a backend data-processing service.

Say you’re writing a user-centric application that needs to quickly respond to UI requests, and, secondarily, it needs to capture all the different types of user activity that are occurring, for subsequent processing. Think about an online advertisement system: when a user clicks on an ad you want to very quickly redirect them to the target of that ad. At the same time, you need to collect the fact that the click has happened so that you can charge the advertiser. (This example is not hypothetical—my former team at Intent Media had exactly this need, which they implemented in a Serverless way:)

Traditionally, the architecture may look as below. The “Ad Server” synchronously responds to the user (not shown) and also posts a “click message” to a channel. This message is then asynchronously processed by a “click processor” application that updates a database, e.g., to decrement the advertiser’s budget.

The FaaS environment may also process several messages in parallel by instantiating multiple copies of the function code. Depending on how we wrote the original process this may be a new concept we need to consider.

Who Are The Ones That Should Be Using Serverless Architecture:

If you have a small number of functions that need to be hosted, you should consider switching to a serverless provider. Considering that your application is more complex, serverless architecture can still be a good choice since it comes with lots of benefits, but you’d need to architect your application quite differently. Some clear benefits are easier concurrency management at scale and optimizing resource usage. If you already have an existing application, this might not be the best solution. Consider migrating smaller pieces of the application into serverless functions over time.

Serverless Architecture And Its Advantages:

Keeping it simple, serverless architecture is an outsourcing solution allowing you to pay someone else to manage your servers, databases, and even application logic that you might manage yourself otherwise. You would pay less for your managed database because a vendor that hosts you is running thousands of very similar databases.

Reduced packaging and deployment complexity is yet another example of how packaging and deploying FaaS functions is simple if you compare it with the deployment of an entire server.

“Green” computing is considered a great hit among developers and the rest of the population. Over the last couple of decades the number of servers increased drastically, so did the need to serve those servers with sufficient power supply. Therefore, large-sized data centers in the world came into existence. Extremely large companies such as Google, Apple, Facebook, etc. are fighting their way through saving the environment from the pollution they cause by implementing and moving their servers on the clouds and moving their data centers near renewable energy sources, so that way they fight against the fossil-fuel burning impact on sites like those. Those “clouds” never produce rain, so your Facebook account is quite safe, do not worry. Making these differences should further lead to the far more efficient use of resources across the data centers. By making those differences, people are reducing the environmental impact which can be compared to a traditional capacity management approach.

The Drawbacks Of Serverless Architecture:

Since everything else in life has downsides and drawbacks, it would be unwise to believe that serverless architecture is flawless. Let’s talk about what we can expect regarding the disadvantages.

Problems that occur are vendor control and vendor lock-in, but also security concerns as well as multi-tenancy problems. Considering that you give up system control while implementing APIs, it can cause system downtime, forced API upgrades, functionality loss, as well as unexpected limits and cost changes.

Serious drawbacks, though, are the essential tools to work with we seem to be missing. Developers depend on vendors for debugging and monitoring tools. Luckily, Dashboard has an observability solution to ease the pain.

While fighting a fight without operational tools, there is another problem causing the flawed usage of serverless architecture, and it’s the architectural complexity. To decide how small a function should be, it takes quite some time to assess, implement and perform a test. The easiest way to perform such a test is with this Step Functions state machine by AWS Sr. Technical Evangelist Alex Casalboni.

Conclusion:

Serverless, despite the confusing name, is a style of architecture where we rely on running our own server-side systems as part of our applications to a smaller extent than usual. We do this through two techniques: BaaS, where we tightly integrate third-party remote application services directly into the frontend of our apps, and FaaS, which moves server-side code from long-running components to ephemeral function instances.

Serverless is not the correct approach for every problem, so be wary of anyone who says it will replace all of your existing architectures. Be careful if you take the plunge into Serverless systems now, especially in the FaaS realm. While there are riches—of scaling and saved deployment effort—to be plundered, there also be dragons—of debugging and monitoring—lurking right around the next corner.