SERVERLESS APPLICATION

WHAT IS SERVERLESS ARCHITECTURE?

Serverless Architectures refer to applications that rely on third-party services or on custom code that’s run in containers, the well-known vendor host of the serverless application currently is AWS Lambda.

WHAT IS SERVERLESS APPLICATION?

Applications made using Serverless architecture or Function as a Service are generally known as serverless apps.

The Serverless code can be used in combination with code written in conventional server style, such as microservices. For example, some part of a web application could be written as microservices and another part could be written as serverless code. Alternatively, an application could be composed that utilizes no provisioned servers by any means, being totally serverless.

Serverless apps can also handle both asynchronous and synchronous operations. The serverless platform you are using will manage the input/output options and language you can write the app in.

WHY SHOULD I ADOPT SERVERLESS ARCHITECTURE?

  • Simplifies deployment and packaging and removes 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 focus on code and quick deployment.
  • 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.
  • Reduce time to market and faster software release

USE CASES OF SERVERLESS APPLICATION

  • Mobile backends
  • IoT sensor input messages
  • Stream processing at scale
  • Bots
  • HTTP REST APIs and web apps
  • Event-driven apps

DRAWBACKS OF SERVERLESS APPLICATION

  • Vendor lock in:
    Running your applications in a serverless environment can firmly couple your applications and services with your platform provider. You lose control over the hardware, the running times, and updates. This can make consistency issue and limit the resources you have accessible.
    If you build your application on one serverless environment, and then you want to transition to another vendor, they don’t make it easy to switch. It is a troublesome 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 emails. However, for long running 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.

 

Add comment

Loading