Inspired by a discussion I had with former co-workers, I wanted to write an article about why serverless might be the future for most applications and why serverless has the edge over traditional backends.
It’s not that I want to say that it’s the best choice in every situation. I believe that it has the chance to become the default, but I don’t think that it will replace any other architecture.
This article talks about typical small business applications that do a specific job. I assume that the application in question does not have a massively scalable scenario, yet should be able to grow with the audience and its usage.
Let’s jump into seven reasons why you should care about serverless and how it might help you create better applications.
Focus on your business logic
The first reason is apparent. If you don’t have to write infrastructural code like starting an app, initializing resources, setting up database connections and dependency injection containers, you’re able to focus on what matters to your customers.
Serverless solutions like Microsoft Azure care about the infrastructure you need to make your code run. You can write your business logic like creating a user or loading data from a database without worrying about the infrastructure.
Respect the stateless model
Every call to an Azure Function or an AWS Lambda implementation is stateless by default, which means that you cannot share information between multiple calls.
What seems to be a limitation at first is a strength when you think about it more deeply. When you’re forced to write your business logic in a stateless way, you build a foundation to scale your application.
Also, stateless functions are easier to understand, to refactor, and to extend. Simplicity has never been wrong when it comes to software development.
Independent scalabilty
In a scenario with a traditional ASP.NET (Core) WebAPI project where you have multiple controllers using infrastructure classes or database providers, you’ll have a hard time to split the project into different pieces to make them scalable independently.
Sure, you can always scale up the entire application, but that comes with other difficulties and is more expensive.
When you write your backend using Azure Functions, you’ll have a bunch of loosely coupled functions that will execute whenever they receive a call from your application. You don’t have to worry if Function A is called more frequently than Function B.
Save some money
The Microsoft Azure Functions platform takes care of your functions, executes them when requested, and charges only the resource consumption that happened.
When you run a traditional Web app, you have to choose a pricing plan, and you’ll have to pay whatever resources are included. It does not matter if you had a low, medium, or high load on the server/application.
Do not limit yourself
Azure Functions can be implemented in different programming languages, including C#, F#, JavaScript, Java, Python, TypeScript, and PowerShell.
C# developers might want to implement most functions in C#. But hey also have the option to write a specific function in JavaScript. It’s especially helpful when a specific framework is only available in a particular programming language.
When you create a tradition ASP.NET (Core) backend or a Node backend, you limit yourself to a specific programming language, which is not the case if you use Azure Functions.
Activate different triggers
Traditional backends are usually called sending an HTTP(s) request. That’s fine for most use cases. But, in modern cloud-based applications, there are other options too.
If you decide to build an application based on the Microsoft Azure or Amazon Web Services (AWS), you might have a data store or other cloud-specific resource that interact or communicate with your application.
Let’s say you have an application running on Microsoft Azure. You might have an MSSQL database or maybe even an Azure Cosmos DB, or a simple BLOB storage.
Those Azure services and many others offer connectors that can trigger a function when an event occurred. For example, if Function A writes a new user to the database, the database can call Function B if the user has been added.
There are many more scenarios where different resources within Microsoft Azure can call an Azure Function.
Vendor lock-in
It’s more a disadvantage than an advantage, but vendor lock-in is another reason why serverless will become more popular. Microsoft, Amazon, and Google what to lock their customers into their Cloud platform by providing the best possible service to their customers and also by making it hard to switch between the providers.
In my opinion, serverless services like Azure Functions or AWS Lambda will always be competitively priced, because all providers what to run your code.
What you can make to reduce vendor-lock-in is to use as few platform specific things as possible. As pure as your functions are (pure in the sense of as few platform-specific code as possible) the simpler it would be to change from platform A to platform B.
The question is if there will be a scenario where you want to move your application from Cloud provider A to provider B without changing the app at all.
I agree. thanks for the article. I have to write many small applications and infrastructure setup is taking too much time, I even have too wait until infrastructure team as created a database which takes 2-3 weeks…
Thanks for your comment, Andre. That’s exactly one of the use cases I’d consider Azure Function Apps a perfect fit.
Until I die, I will use as little of the cloud systems as possible.
I am sick and tired of the past screw jobs these huge corporations have already demonstrated.
These companies have only one thing in mind:
Make Money.
And they make money buy forcing changes upon business. Many of these changes are breaking changes. Meaning none of your stuff works any more.
Example: GoogleTalk:
Many people built software on top of it.
Google just turned it off.
There are many more examples of this, once you start looking.
This type of behavior, is why I only use data source cloud services, at least once they stop providing, I can find another and implement the Data retrieval from another source.
Screw Cloud Systems!
Today, young ignorant people think web pages / systems are software.
I say, web pages are not software, or applications. And never will be because of the stateless nature of the stupid web server. This data and the User Interface are mixed together using php and javascript.
Try writing 500 thousand lines of javascript, it will not scale to this level, ever. Yet, millions of web sites continue the madness. Because Microsoft, has lost market share to google and others. And those others don’t want to embrace Microsoft. Hence the chaos.
What do you call a web page accessing a C++ dll?
I call it a terrible hack, funny your stupid web page needs access to a C++ dll?
Why didn’t you just write a real application that runs on the client, and use the data layer for your stateless needs?
You see now that Microsoft has huge competition, everyone else’s solution has to be on a dumb weak web page, that ends up calling C++ dll system calls to do anything practical.
Think of flash player? It can’t run on HTTP can it?
Real software is a:
Windows Form
Linux Form
Apple Form
Accessing data (stateless), as needed.
I wish http would just die, it’s horrible way to display data.
But the real reason this madness will continue?
Because of marketing, the marketing monkey’s just want money. They get money by jamming ads on every conceivable space on a web page possible, surrounding the content.
They can’t market on Native Windows (and I include: Apple, Linux, forms).
And so a movie was created: Idiocracy 2006, to depict our future.
Perfect example of where software is headed. All stores are gone except one giant 30 mile long Costco.