After Microservices, the next revolution in Software Architecture is Serverless. There are already many great blog posts on this subject and some I have indexed at the end. This is my own views on Serverless.
As we know servers are just another computers. Similar to desktops they have Processor, RAM etc...fixed on mother board and motherboard needs power. Probably they might not be having dedicated keyboard or monitor instead they can be remotely controlled. These physical server machines normally will have high hardware configuration which is not needed for normal workloads. So there resources are shared by hosting multiple small machines inside it and we call them as virtual machines. Another reason for VMs is that we can easily manage the VMs by software. For example we can delete a windows VM and create Linux VM completely via virtual machine managing software. Also we can easily adjust virtual machine's RAM, Hard disk etc....
In a traditional in-house data center, we as operations engineering/infra team have to make sure there are enough physical servers so that we can respond to the dynamic needs of VMs from different apps. At any given time, most of the machines will be under utilized considering their capacity. From software developer perspective, they have to make sure these machines are having proper software installed and had to scale up / down / out based on the usage. The old gen cloud environment ie IaaS solves this issue of provisioning machines easily. At least the infrastructure operations team is happy.
The application software side was not happy with IaaS because their duties were not reduced. That's why cloud is evolved to more abstracted levels such as PaaS, SaaS etc...In every higher level, more abstraction is getting added and developer is going away from the hardware and concentrate on the software aspect of the system.
In PaaS, developers don't need need to worry about the platform and scaling is less painful than IaaS. Using a slider or command they are able to control scaling. Some cloud providers provides auto scaling at this level but developers had to write some code to determine when to scale. This really solves, if the software is going to be deployed as a package/bundle which does related task. eg: a website or APIs exposed via web.
In PaaS, since the unit of deployment is package, the scaling applies to all the tasks in it, regardless of the individual task usage. Eg: We have 10 APIs in a WebAPI deployment and only 5 are getting high traffic. But when we scale, entire WebAPI deployment get scaled.
Enter FaaS (Function as a Service)
We saw the scaling issue in PaaS. One way to individually scale each task is to split the deployment package to task level so that each deployment package has only one job/task. This is somewhat Microservices tried to achieve. Split the app as much as possible.
But that still needs monitoring. Someone has to monitor and adjust scaling based on usage. Lazy developers wants to get out that as well and there comes FaaS. Here each function becomes a deployment unit. When it came to FaaS, the cloud providers were able to provide real auto scaling. Developer don't need to monitor anything. The provider does it.
What is Serverless
If we examine the PaaS, the cloud providers kind of started managing server. We just had to give a deployment package the rest will be done by provider. But there was monitoring overhead. When it came to FaaS the the cloud providers started taking entire ownership of servers. But those were not only the factors for the rise of Serverless.
Free high performance server side execution
Along with taking the hardware away from developers, many cloud providers started giving free tiers. Since its per function, the cost of starting a cloud based business became very less. At this point nearly 0. So obviously startups selected this way so that they can try out their ideas in this model without much investment. They can market things very fast and even if it fails, they are able to manage the financial loss. Earlier, there were very less options for getting free industry grade server side code execution.
Free industry grade HTML hosting
Another boost is the availability of free HTML web hosting providers. It was there from the beginning but they were not ready to host high traffic sites. But that is not the case with git pages, amazon S3 hosting. Now with $0 hosting cost, anyone can start online business. Only thing they need to know is how to do basic HTML+JS coding and integration skills. Integration skill are nothing but calling the above mentioned free server side APIs via XmlHttpRequest or simply AJAX.
One more benefit came in the situation is the availability of many freemium services to do cross cutting concerns or shared capabilities. If we want to provide login integration with Google, Facebook etc..., its's now matter of some hours.
Success of standardized web & Availability of mobile & high speed internet
These are some additional positive things happened which boost the evolution of Serverless. If different browsers were behaving differently, jQuery & AngularJS were not invented, internet was giving in dial-up the word Serverless might not have been heard.
Overall, the startup community found it cost effective and since they are the drivers of innovation and conferences Serverless became the next Jargon. Obviously with the support of the real giants or the cloud providers. Very soon enterprises will also follow the same route.
Are there really no servers?
There are servers but entirely managed by the cloud provider or the SaaS provider. Without server ie some higher end computers or generally hardware, we cannot run our web based softwares except peer to peer such as torrents. The term just makes confusion.
I am using FaaS. Am I in Serverless?
We have to understand first that the web applications has 2 ends. One is the front end which runs in browser, served from a web server. The other is the back-end, where the data lives and computation happens. Back-end we can again divide to computation layer(business layer) and data layer. Using FaaS make sure that our computation is Serverless. But what about data layer and front end. If the front end is served from in-house data center or from IaaS virtual machine, we cannot say the application is Serverless. This is applicable to databases or files in data layer too.
So if we are not at all worrying about any server, we can say our application is Serverless.
Does Serverless means free?
Serverless is an architecture pattern and doesn't mean it is free. But if we are choosing this architecture, we can have application up and running in zero hosting fees. Development cost is always there. Mostly everyone starts in free tier and upgrade to paid when they get success. That move doesn't usually involve any code change.
Does Serverless require strong upfront arch design?
Serverless provides great flexibility to development similar to Microservices. We can choose multiple languages which suit to the service / function. Easily get rid of technical debt by rewriting hot functions. Architecture can be easily changed as its only at the integration level.
But that demands a good architecture vision on integration. Else the functions will not work together to produce desired behavior.
Will there be function hell?
Yes, if the management & monitoring of the functions not done properly. If we let every Tim and Harry to start writing functions without a monitoring mechanism, we will soon end up in so many functions in the production environment and nobody knows why they exist.
Does the Serverless arch require CI,CD pipeline?Though architecturally doesn't require, its advvised to setup proper CI, CD pipeline to take advantage of this model. This is applicable in Microservices too. Else it will take unnecessary integration efforts.
Should I switch to Serverless tomorrow?
When the cloud is announced many industries were not ready to accept and the concern was security. But now we can see the direction is changing. Even banks are trying to use cloud as much as they can. There is no question that Serverless will be the future similar to how Microservices are doing now. But as always before we convert our existing app or start next app using Serverless, we have to compare the pros and cons.
The below comparison assumes that Serverless uses FaaS along with SaaS. So some factors may seem suitable to FaaS or SaaS.
- Single responsibility at function level - This is something we were trying to achieve from the beginning of software but at the mercy of developers which is very difficult to get. But with Serverless, this is enforced by architecture.
- Cost - Theoretically it should be less as we are truly paying for what we use. But has to wait for more real time high volume usage reports.
- Scale out coding - Coding can be scaled out efficiently and done even in browser. But this is good, if there is proper high level integration plan.
- Ease of code management - Also we can easily get rid of technical debt by rewriting functions.
- More selection of languages - We can select different languages for different functions similar to Microservices. But this is double edged sword.
- Easy switching of provider - Since the deployment is at function level we can switch provider gradually function by function.
- Many points of failure - Since our app may depend on many SaaS, if one of them down our entire app may get down. Else we have to use fallback mechanisms.
- Not all SaaS available equally in the entire world - If we are using Facebook as the only login provider, people from countries where Facebook is banned cannot use our software. Also any country or region may block anything. So need to monitor the world.
- Function hell
- Performance - The end user don't need to worry that the app is Serverless and the performance hit is due to X SaaS or Y cloud provider. To them the site /app is single unit and ensuring performance is the developer's duty.
- Integration complexity - The total business complexity of app cannot be changed but can be moved. In Serverless tt just moved from component level to higher integration level.
- Performance of chained calls - If the business requires complex processing chain, it may affect performance. Better those should be queued.
- Performance of service instance activation - Upon a trigger the cloud runtime is expected to select one from existing or start a new runtime environment for the function before execution. The time to setup that environment affects the performance. This depend on the provider specific FaaS runtime implementation.
- Less control - If we have a unavoidable scenario of long running service, the provider may kick out our service instance due to timeouts. Not an arch level disadvantage. Its provider dependent.
- Lack of tooling - This is a temporary disadvantage. Soon more tools, IDEs and offline testing solutions will evolve.
- Developer forgets hardware - This can be seens advantage as well as disadvantage. Discussed more below.
Serverless makes developers moving away from hardware
This is a debatable. But whatever debate we do a good chunk of developers are getting away from hardware. But is this started with Serverless?
Never. The move has started when the assembly language is invented. Instead of 1's ans 0's people then started using Mov A,B or PUSH B etc...The compilers took it further. Later the managed platforms came with virtual machines. Those were all driving the developers from bare metal machine.
The great developer divide
But whatever happens, there is a hardware which understand 0's and 1's. Who control the machine. Obvisouly the compiler writers & runtimes coders. They are still with the machine and require high skills than the business application developers. We can now tie the cloud runtime developers into the same group. Those skills are not replaceble with AI. But the business developer will soon or later taken by AI. Another group of developers who will join with the system and cloud makers are the AI algorithm authors. There are already sites like Algorithmia who facilitate Algorithms as a Service.
This is more like the natural evolution. It take considerable amount of time to see 2 species of developers. Its again it's own topic to be discussed in separate post and not sure the term 'The great developer divide' suits to the phonomenon.
Whether the author use Serverless?
I always believe in solving my problems first before I solve other's with my code. Yes I am taking 2 of my personal projects to Serverless. My personal website http://www.joymononline.in & Karel simulator. My main motivating factor is the hosting cost than the eager to try out new Architecture. More updates will be shared later via this blog.