WHAT IS SERVERLESS ARCHITECTURE?
Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best-known vendor host of which currently is AWS Lambda.
WHAT IS SERVERLESS APPLICATION?
Applications made using Serverless architecture or Function as a Service or “FaaS” are generally known as serverless apps.
The Serverless code can be used in conjunction with code written in traditional server style, such as microservices. For example, part of a web application could be written as microservices and another part could be written as serverless code. Alternatively, an application could be written that uses no provisioned servers at all, being completely serverless.
Serverless apps can also handle both asynchronous and synchronous interactions. The serverless platform you are using will dictate the input/output options and language you can write the app in.
WHY SHOULD I ADOPT SERVERLESS ARCHITECTURE?
- Simplifies deployment and packaging and eliminates the need for system administration.
- Decreases the complexity of software.
- Fits well with microservices (they can be implemented as functions).
- Works with agile development and enables the developers to concentrate on code and deliver quickly.
- The lesser cost to scale – the developers need not to implement code to scale and the administrators need not to upgrade the servers that are existing or add any additional servers.
- Smaller development and operational costs.
- Decreased time to market and faster software release.
USE CASES OF SERVERLESS APPLICATION
- Mobile backends
- IoT sensor input messages
- Stream processing at scale
- HTTP REST APIs and web apps
- Event-driven apps
DRAWBACKS OF SERVERLESS APPLICATION
- Vendor lock in:
Running your applications in a serverless environment can tightly couple your applications and services with your platform provider. You lose control over the hardware, the run times, and updates. This can create issues in consistency and limit the resources you have available.
If you build your application on one serverless infrastructure, and then you want to transition to another vendor, they don’t make it easy to switch. It is a very difficult process, and you may need to reengineer your application if you wish to do so.
- Slower service start:
Because you’re serverless provider is automatically scaling your applications, if you don’t have any activity for a longer time some of your application instances may be down when a new request arrives. The situation then requires a “cold” start of your services, which may result in a higher latency of up to 1s.
- Unsuitable for long-term tasks:
Serverless is great for short-term or real-time processes like sending out emails. However, for longer duration tasks, where functions are running constantly, you may end up paying more for compute time than when paying for a reserved instance.
WHAT WE HAVE DONE?
- We have developed serverless application known as AWSScheduler which has written in react as frontend, asp.net core web API as backend with MYSQL database.
- The backend has the ability to deploy as a lambda function.
- Additional to lambda function, we have used AWS simple queue service (SQS) and simple notification service (SNS).
- SNS is used to subscribe SQS and which will send a notification to SQS based on a triggered event of a lambda function.
- An event of adding a new schedule, it will trigger SNS which will write data into SQS queue.
- AWS Cognito has used for user authentication and management.