You must have heard the term serverless. It is 2019, and everyone in IT is buzzword driven. Many of the companies are actively participating in or seriously considering taking part in the serverless revolution. Is it worth it? What is in it for you? I would like to focus on not-so-obvious advantages that the technology brings to the table - in particular, business-wise.
Serverless is much more than FaaS and Lambda
Let me start with a clarification that is present in some places over the internet that serverless equals AWS Lambda, Azure Functions, or Google Cloud Functions. It is a false assumption which simplifies and strips serverless of the most valuable premises.
Allow me to tell you an anecdote about one of the most defining experiences in my career when I joined a fast-growing German start-up that was building a marketplace for cleaners. It was 2014 and nobody even thought about serverless computing, yet our client was building their product deliberately in such a way.
They chose Salesforce as a base, deferring the decision about the storage layer and the database until the very last possible moment. On top of the features available on that platform, we built all custom integrations with the use of webhooks, straightforward back-end services hosted in PaaS solutions like Heroku and number of third party services (SaaS-based ones).
The client thought about serverless before serverless times. Why? Because they needed fast and reliable iterations, reduced time-to-market and reduced operational overhead, as they did not build just a technology company - as many start-ups build nowadays.
The critical point here is about having the ability to build mashups quickly. For such businesses, your main focus should be put on building a digital product, not spending time in digging in a technology and reinventing the wheel. Keep in mind that everything is contextual, and that is just one context where serverless shines.
Premises of Serverless
In this paragraph I will use the support of someone much wiser and well-known in the community. I would like to present a whitepaper written by Gojko Adzic and Robert Chatley titled: Serverless Computing: Economic and Architectural Impact.
It is an interesting paper that presents various case studies related to serverless computing and how it affected three areas featured projects:
- Economics (cost-efficiency)
- Software Architecture
- Operations
Economic Impact
Interestingly enough, a central point of this section of the article is the table that presents pricing differences between serverless, PaaS, and IaaS solutions. The differences are impressive. There is one catch there - the choice of case studies is very particular and contextual - and that is perfectly visible and fairly stated in the paper.
In such contexts, where workload and revenue are heavily dependent on user base, you do not have to worry about on-demand pricing even if your service works 24/7. You will compensate that in the price of your SaaS product.
An additional obvious cost optimization is cost-efficiency in the operational area. It does not mean that you do not need operations people - you do need them, but they need a slightly different skill set. However, the investment is much smaller than on-premise or even IaaS cases.
There is one point missed here. I want to talk about a topic which is skimmed in the whitepaper but gives a significant competitive advantage in the real world - which is reduced time to market. Serverless can tremendously speed up the development process, with one caveat - it requires somewhat different skills in the team, e.g., you need programmers with DevOps and Cloud Computing skills. However, after assembling such a team or developing their skills in this area, you will see how big an impact it can have on the team’s productivity.
Architectural impact
Let’s start with a quote:
[...] breaking the monolith into functions that could be independently deployed, meant that they were better able to split the team up to work on more things in parallel, and to deploy each feature separately.
It looks and hears precisely like the definition of microservices. All of you who worked with those architectures may be getting goosebumps right now. Are serverless architectures the final stadium of the microservices architecture promise with a significantly smaller operational burden? The answer is, unfortunately, much more complicated.
The state described in the quote is indeed achievable, and much less expensive than in a non-serverless environment. However, we are again facing the problem of ecosystem infancy, and we need to wait for the modern solutions available in the market. Serverless approach has bigger or smaller deficiencies all over the place starting from framework and development support, through CI/CD pipelines and ending with monitoring and observability.
However, it is a fair assumption to say that serverless in those contexts gives a significant advantage in that area as well.
Operational Impact
Last but not least, operations are the most obvious, and sometimes misunderstood area in the whitepaper. Managed services available on the cloud vendor platforms are moving significant parts of the operational burden of the customers, and they agree to pay a little bit more for that.
As usual, it is a tradeoff and a business decision as in the anecdote presented at the beginning - some companies will invest their money in building technology as it is an essential piece of their competitive advantage; other companies on the market will focus on building their products, and serverless is for them.
How can it affect your business?
I hope that at this point, you start to see the patterns.
First and foremost, the pricing of those services allows you to build elegant and predictable revenue models. It is relatively easy to calculate the total cost of a single call. Good luck and have fun with calculating the same metric with an on-premise infrastructure - difficulty skyrockets and breaks the ceiling if you have to take into account the hardware cost involved e.g., leasing or amortization, and other liabilities.
Another positive impact is related to a significant reduction in idle costs. If you are not convinced yet, I would like to present a visual example. Have you ever bought a classic gym membership card? You pay for a card which is valid for one month upfront, and you can use the gym. In many cases, it ends up in a “you have to” bucket, as you are susceptible to a sunk cost fallacy. What if gym membership could be done in a pay-as-you-go elastic way? It would be much better and allow for better resource utilization. The same is with serverless.
We briefly talked about it above, but I would like to mention a smaller operational impact once again. Thanks to a shared responsibility model in serverless architecture operations affect just the top layer of application code. For businesses which do not want to spend money on building internal platform teams, it is a great deal.
A second point is reduced time to market - and we are talking here about significant savings, as you do not want to build everything on your own if you just want to build a business instead. It is clear that not all companies want and should invest their time in building an internal technology. The distinction is clear - we have companies that are focused on that and those that are building digital businesses.
Years of working in IT and ups and downs in my career have taught me that there is no silver bullet in this business. This example is no different, and it sets some challenges, and it may as well sometimes affect your business negatively.
The first and most obvious problem is the perceived reliability and performance (from the user’s perspective). As Serverless brings new challenges to the table (e.g., cold starts), it may affect your business in that regard. You have to be aware of the constraints to build a robust and reliable solution on top of that for your business.
Not all cases are applicable for serverless. Like any tool, it should not be applied always and everywhere. One thing worth mentioning here is that you can provide a mixed architecture as a rescue. You do not have to be fully serverless, you can use that as yet another tool in your toolbelt depending on the context.
Last but not least, it requires a mind shift and different skills in the development teams. You need builders - ideally with operations knowledge inside the squad. It additionally requires a change in your way of thinking and a positive attitude as it is still an immature technology, and there will be rough edges.
Summary
The goal in this article was to present some possible impacts of serverless on your business. It is not an easy decision to use serverless, and it can be mind-boggling - especially if it influences the vital elements of your digital baby.
If you are seriously considering and evaluating such an approach for your business I would like to make you a special offer: we can schedule a free 30 minutes reconnaissance call. During that call, you can just pick my brain and learn more about how you can benefit from serverless on AWS. So, are you open to such an opportunity?
