Serverless is an architecture and set of technologies that move on-demand computing to the next level since a request will trigger the deployment of the function that handles the request itself. Serverless is a misnomer since you still need a listening component (a server), but instead of having a complete server waiting for the request, only an API gateway is required and the API gateway will instantiate the function or microservice needed to process the request.
If limited to that approach, serverless is just an evolution of IT architecture. However, by making the deployment of a function or microservice dynamic, serverless architecture also introduces the notion of fluid software since it is possible to decide where and when the function or microservice will be deployed. Therefore, based on conditions (derived from analytics), it will be possible to deploy the function or microservice closer to the request generator, which could be an edge node.
In this case, serverless architecture is a fundamental transformation since it breaks away from client-server architecture. The shift from legacy architecture will include the following considerations:
It is important to understand extreme decomposition since serverless implies microservices, which then means understanding clusters and cluster management, and then because of the fluidity of the solution it is important to understand extreme distribution: including edge-cloud which modifies the criteria and scope of the cloud-based cluster management (for clustering based on proximity or on user’s account). So technology like kubernetes for cluster management, and sidecar patterns like Istio or mimik edgeEngine are important to understand. It is also important to understand automated deployment, since non-human-driven deployment and SCM will be mandatory for the success of a serverless/microservice architecture.
The security protocols do not change. However, since serverless-microservice-based solutions are distributed, it is important not to depend on a central trust authority and use peer to peer token validation for API requests. But also not assume that the system’s components will be behind a firewall and that the network is untrustworthy. Finally, it is also important to handle multiple levels of security, since sensitive payload may go through relay microservices. For example, user information may go through a tunnel microservice and the call to the tunnel is protected by a token, but it is also necessary to protect the user information by avoiding the tunnel to be able to interpret the information itself.
In serverless-microservice-based architectures, each instance has to be stateless. Therefore the storage components are essential in storing states, as opposed to some legacy systems where the states are maintained by non-storage components. Based on the distributed nature of serverless-microservice-based systems, and due to theoretical limitations (CAP Theorem), the storage will most likely be BASE as opposed to ACID legacy storage. Clever partitioning strategies like explicit addressing and geocentric storage have to be put in place in order to cope with the eventual consistency of the system.
In serverless-microservice systems, the computing demand is mediated by the application itself, resulting in a closer fit between the allocated computing power and the used computing power. Due to the dynamic and fluid nature of the systems, it is also possible to offload the required computing power to other computing nodes (like edge devices or gateways) and thereby further optimize the allocation of cloud-like computing power.