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. These are my own views on Serverless.
Some History
As we know servers are just another computers. Similar to desktops they have Processor, RAM, etc. fixed on mother board and motherboard needs power. 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 their resources are shared by hosting multiple small machines inside it and we call them virtual machines (VMs). Another reason for VMs is that we can easily manage the VMs by software. For example, we can delete a windows VM and create complete Linux VM 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 that can respond to the dynamic needs of VMs from different apps. At any given time, most of the machines will be underutilized, considering their capacity. From software developer perspective, they have to make sure these machines has proper software installed and had to scale up/down/out, based on the usage. The old generation cloud environment i.e. IaaS easily solves this issue of provisioning machines. Although the infrastructure operations team was happy with IaaS, application software side was not because their duties did not reduce. That’s why cloud has continued to evolve to more abstracted levels such as PaaS, SaaS, etc. At each higher level, more abstraction is getting added and developer is slowly shifting from the hardware to concentrate on the software aspect of the system.
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.
Enter PaaS
In PaaS, developers don’t 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 any problems that would arise when 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 gets scaled.
Enter FaaS (Function as a Service)
We saw that scaling was a pain point 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 something that 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 of that as well and in 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 and the rest is taken care by provider. But there was monitoring overhead. When it came to FaaS, 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 it’s per function, the cost of starting a cloud based business became very less–at this point nearly 0–so obviously startups selected it to try out their ideas in this model without much investment. They could market things very fast and even if it fails, they were able to manage 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. Although present from the beginning, they were not ready to host high traffic sites. But that was not the case with git pages, amazon S3 hosting. Now, with $0 hosting cost, anyone could 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.
Fremium SaaS
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., it is now available in a matter of few 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.
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?
The term is a little confusing. There are servers but entirely managed by the cloud provider or the SaaS provider. Without server i.e. some higher end computers or generally hardware, we cannot run our web based softwares except peer to peer such as torrents.
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 makes 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.
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 with zero hosting fees. Development cost is always there. Mostly everyone starts in free tier and upgrade to paid once they are successful. 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 that nobody will know why they exist.
Does the Serverless arch require CI,CD pipeline?
Though architecturally it is not required, it is advised to set up proper CI, CD pipeline to take advantage of this model. This is applicable in Microservices too to prevent unnecessary integration efforts.
Should I switch to Serverless tomorrow?
When the cloud was announced, many industries were not ready to accept and the concern was security. But now we can see the opinions 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.
The below comparison assumes that Serverless uses FaaS along with SaaS. So some factors may seem suitable to FaaS or SaaS.
Pros
- Single responsibility at function level – This is something we were trying to achieve from the beginning of software development but since it was at the mercy of developers, achieving it was very difficult. With Serverless, responsibility is enforced by architecture.
- Cost – Theoretically, it should be less as we are only paying for what we use. But this factor will change with more real time high volume usage reports.
- Scale out coding – Coding can be scaled out efficiently and done even in browser. It should ideally be paired with a proper high level integration plan.
- Ease of code management – 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 a double edged sword.
- Easy switching of provider – Since the deployment is at function level, we can switch provider gradually function by function.
Cons
- Many points of failure – Since our app may depend on many SaaS, if one of them is down, it could lead to collapse of our entire app. Otherwise, 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 a 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, it just moved from component level to higher integration level.
- Performance of chained calls – If the business requires complex processing chain, it may affect performance. It would be better to queue those.
- 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 an unavoidable scenario of long running service, the provider may kick out our service instance due to timeouts. Although not an arch level disadvantage, it is provider dependent.
- Lack of tooling – This is a temporary disadvantage. More tools, IDEs and offline testing solutions will evolve with time.
- Developer forgets hardware – This can be seen as an advantage as well as disadvantage.
Serverless makes developers move away from hardware
This is debatable. But whatever debate we do, a good chunk of developers are getting away from hardware. But has this started with Serverless? No.
The move started when the assembly language was invented. Instead of 1s and 0s, people started using Mov A,B or PUSH B, etc. The compilers took it further down the road. Later, managed platforms came bundled with virtual machines. Those were all driving the developers from bare metal machines.
The great developer divide
But whatever happens, there is a hardware which understand 0s and 1s. Who controls the machine? Obviously, the compiler writers and runtimes coders. They are still with the machine and require skills higher than than that of business application developers. We can now tie the cloud runtime developers into the same group. Those skills are not replaceable with AI. But the business developer will sooner or later be replaced 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 which facilitates 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.
References
http://martinfowler.com/articles/serverless.html
https://read.acloud.guru/serverless-the-future-of-software-architecture-d4473ffed864
http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html
This article has been re-published from author’s personal blog. For reference, click here.
