What is Serverless?
For a long time, we have been building and deploying web applications where we have control over the HTTP request that has been made to our servers. We are responsible for provisioning and managing the resources that are required by this server. But as time passes by, there are many challenges that come along with this method of deploying and building the applications.
The server needs are constantly running even if it is not receiving any request.
The responsibility of server security is upon you.
The responsibility of maintenance and server uptime is on you.
As the application scales, we have to manage the scaling of the server. And also have to scale down the application when there is not much usage.
And to solve this issue, things like:
BaaS(Backend as a service)
DBaaS(Database as a service)
FaaS (Function as a service) came into the picture.
Backend-as-a-service(BAAS)
We talked about multi-tier architecture and how client-server software had been the approach in the past. With the evolution in the public cloud and mobile application, we started to see a different approach to application development.
Now, most of the developers who are developing mobile apps don't want to maintain a data centre to service their clients. Going further, the mobile application begins to evolve in such a way that the cloud utilizes cloud components and offering. Cloud vendors were quick to provide a solution to this in the form of a backend as a service.
Backend as a service is a cloud service model where server-side logic and state are hosted by cloud providers and utilized by client applications running via a web or mobile interface. It is more or less a series of APIs that are hosted in the cloud. So if I'm working on a web application and want to have an authentication mechanism for my users well, AUTH0 provides me with a way to authenticate my users by using their cloud-hosted APIs. So that way, I don't need to manage authentication on my servers; I can put it on AUTH0 to handle it for me.
At the end of the day, all APIs hosted on could just craft a URL, make a rest request to get some data and execute on.BAAS lays the foundation of what serverless has become.
Database as a Service
Database as a service refers to a cloud computing offering where users can use a cloud database system without purchasing and setting up the hardware, installing the database software, or operating the database themselves. The provider takes care of everything from periodic backups and upgrades to the database software, ensuring the database's high availability, security, and scalability. This service is often referred to as "Managed Databases".
Further, to simplify building serverless architecture, DBaaS(Database as a service) came into the picture.
Fauna takes DBaaS one step further.
Fauna is a data API for the client-serverless application. It has a web-native GraphQL interface, with support for custom business logic and integration with the serverless ecosystem, enabling developers to simplify code and ship faster. Fauna has transformed traditional DBMS into a Data API that gives you all of an old-guard database capability without sacrificing flexibility, security, scale, and performance. Fauna lets you build on any architecture that is best suited for your business, be it a single page application, microservices, serverless functions, jamstack, or classic three-tier web applications. Since Fauna is an API and not a DBaaS or a cluster that you must manage, no provisioning, no configuration is required to use Fauna. You can get started instantly as a serverless utility. Since it is connectionless and accessible directly from the browser or mobile clients, it makes it easy to code and ship faster using Fauna. Sounds exciting to get started with Fauna today.
Functions as a service:
Faas is a cloud service model where business logic is resented by event trigger containers ephemeral.
How is FASS different from BAAS?
In BAAS, we were using APIs effectively from cloud providers. In FASS, you provide your code, which is executed in the cloud by event-triggered containers that are dynamically allocated and ephemeral in nature.
Basically, our code is event-triggered, which means we don't have to start the application and wait to receive a request. The application only exists when it's triggered. Something has to make it spin up. The best part is you have to define what that trigger is.
They run on containers. A container provides a runtime environment for your piece of code.
There aren't any servers waiting for request containers when the events are triggered in the true nature of serverless.
Faas is also dynamic, which means you don't have to care about the scaling when you get a spike in traffic. Scaling up of application is taken care of by the cloud providers, and when the application doesn't receive a request, the scaling down of the application is taken care of for you by the cloud providers.
The last thing to keep in mind is the containers running our code are Ephemeral, meaning they are transient. They are not going to stick around. As soon as the job is done, they stop existing.
So practically speaking, you will write some code that performs some function that will do a super-specific task, whether it be collecting a user id, format some data for output.
A runtime architecture where cloud service providers and resources entirely manage the infrastructure is dynamically allocated on demand for a given unit on business logic.
The key to a serverless application is the application runs on a seemingly ethereal phantom infrastructure that exits yet doesn't exist.
Serverless uses servers, but the beautiful part is you don't have to manage or maintain them. You don't have to configure or set up a VPC, set up complex routing rules, install regular patches to the system, and more just to be able to get high performance and robust applications.
The cloud providers take care of all these details, leaving you to focus more on developing your application.
It takes a lot of overhead while developing the application; yes, you pay for every time your code has been triggered and for the time it runs to the cloud provider.
It is also important to be aware of when talking about creating a serverless application that you need to take appropriate measures to protect your application from unwanted high traffic, perhaps some kind of DDOS(Distributed Denial Of Service) attack that could spin up a lot of copies of your code and increase your bill.
Your application can be a mixture of both BASS and FASS hosted on your cloud provider's infrastructure.
Ultimately, what is essential to be aware of with serverless is that you only have to focus on developing and shipping the code.
You don't have to focus on any other component, and this makes development more comfortable. It simplifies making client-server applications because the cloud service provider is doing the heavy lifting for you.
Skill Set:
When it comes to skillset, the great thing about it, you only need a development background to be successful with it. Every complicated thing related to infrastructure will be taken care of for you by the cloud providers.
Costs:
When it comes to cost, there are arguments to be made for either architecture. The great thing about serverless is that the startup costs are really low because you will only pay for every execution of your code.
Use Cases:
This is more from the perspective of how we expect software to be used.
Serverless is fantastic for sporadic traffic or seasonal traffic.Perhaps you are looking at a retail website that does large sales periodically using traditional data centers means you will have all your infrastructure available even when you won't be using it all time, and that is a significant spike in overall cost.
Whereas in serverless, you don't have to worry about the infrastructure. It will automatically scale.
Top comments (0)