Tuesday, June 7, 2016

Serverless Architecture


The first thing to understand about Serverless architecture is that it's not about the absence of a server. What it means is that as a developer you are not concerned with the server. You provide a code piece to an environment and it will be executed and results will be returned to you. You are just responsible for providing the code piece and generally, the code piece has to adhere to some contract so that the execution environment can understand it. AWS Lambda is an example of Serverless architecture. 

Serverless architecture is important from the perspective that
  • Development is very easy as it is easy to write code, test, and deploy. However, with serverless one cannot build complex in-memory data models which usually helps in performance and doing complicated workflows. Serverless is more about shoot and run. Basic CRUD functionality with minimal or no business logic is a good candidate for the same. 
  • It saves the developers from dealing with servers and in dealing with deployments. Write code, load it in the execution environment, and let it run. This helps developers in focusing on the core stuff than on other aspects of development.
  • Hot redeployments are very easy and can be done selectively.
  • Handles scalability transparently. This is one of the biggest selling points of Serverless architecture
The current notion of Serverless architecture as presented by AWS Lambda, however, has its limitations. There is a limitation in terms of computing time and memory resources it can use. So generally they are good to do a well-defined piece of work which is time and memory-bound. Don't attempt to build a complicated piece of work as part of lambda, as of now.

Hopefully, the notion of Serverless architecture will evolve more with time. We can expect to see more complicated functionality built and supported in a Serverless fashion. The key here is to remove the notion of the server from a maintenance perspective and let developers focus on actual development. 

The other developments that will help in building a Serverless future are
  • Need to build smart servers. Of course, someone has to deal with the smartness at the server level what we call server configuration, management, and maintenance today. 
  • The Serverless need to know how to scale itself as per the need during individual executions.
  • Issues of authentication and authorization and how the execution context handles them.
  • Logging is another area that needs to be handled as executions are distributed.
  • The execution environment will have to provide multiple capabilities that are provided by frameworks. For example, connecting to datastores, messaging systems, etc. need to be handled by the execution environment to an extent. This is also relevant from the context of performance. For example, creating a connection to the database every time a Serverless code is executed can be costly. The execution environment needs to handle such notions smartly. Lately, AWS has started supporting the notion of connection pools using RDS proxies.
  • Testing frameworks need to evolve to handle the Serverless.
  • Limitations on execution time and resources.



Image Reference: Pixabay

No comments:

Post a Comment