On-premise To Cloud To Serverless To Cloud Native To Serverless Less Applications??
A story on digital transformation
Ok! So the journey started when you created the first application and hosted it in your server; let it be on-premise or on the cloud. Gradually as part of the digital transformation journey, you got compelled to create a mobile application and you ended up creating one! You wrote separate services along with the backend- both for mobile as well as a web application. Later you unified the logic and decoupled the services from the thick monolithic structured application and embraced the ‘Microservices Architecture’. And then, backend and the services for mobile and web application became the same.
Microservice Architecture
The Microservices architecture started with “Container” adoption. Each service in this ran independently in an isolated place called “container”. This helped the application to work as a single unit. At a not so later stage, cloud hit the market with container strategies. We then deployed our application workloads on cloud-based container solutions. Kubernetes helped the microservice adoption flourish by making the management of container easier. Cloud played equally well by providing Container as well as Kubernetes service. After the container adoption or at the beginning of the container adoption, we started to hear a new term -‘Serverless’.
Serverless
Serverless is cloud-born application architecture. It is purely based on FaaS, SaaS and some of the PaaS components provided by cloud vendors. “Serverless” is very attractive owing to its own benefits. Zero upfront cost — just pay for the time consumed by the CPU to process a task for a trigger, no need of the server to be up and run 24/7 to serve the requests, high scalability and high immutability are few of its great advantages. It is, in fact, the most efficient and cost-effective (to say “costless” would be better) way to deploy an application (though not all applications can be deployed in serverless functions). In spite of all, serverless functions- the compute unit, holds few limitations as well — it can run only for a few minutes, variables have validity till the run time, it is more stateless application friendly. These limitations exist for a reason, serverless functions are PaaS services which runs on a shared environment. Let’s say you have some issues with the current cloud vendor where you have deployed your serverless application, it can be cost-related issues, lack of developers, lack of features, lack of community support etc. So, you decided to migrate your serverless application from one cloud vendor platform to different. You might have used object store, database, compute functions, in memory cache etc to create the application. The look, feel and the behaviour of the mentioned services is entirely different for each cloud vendor. This validates and reaffirms that you cannot run your serverless application deployed in one cloud vendor platform in a different cloud platform. If you want to migrate, you will have to rewrite the application for the new platform. Ideally saying, your application is vendor locked. It’s not as easy as you think to migrate your serverless application from one cloud vendor to the other cloud vendor. Here come’s our next destination in the journey, “Cloud native with Kubernetes”.
Cloud native with Kubernetes!!
Several myths and fallacies about Cloud native architecture are found among developers. Cloud native promotes a set of tools for deploying cloud-native serverless applications on the cloud. So now, if you think to switch the cloud vendor by re-engineering and re-platforming your entire application design, think twice and design and deploy your application in a cloud-native way. I’ve already mentioned earlier that cloud-native promotes a set of tools for deploying serverless applications or systems; we should thus focus more on Kubernetes based cloud-native toolsets to build the solution. All cloud vendors provide service to run a Kubernetes cluster. If you look at the CNCF landscape, you will identify a set of open source tools for serverless platforms which can be deployed on top of Kubernetes. There will be tools for serverless functions, databases, observability, logging, tracing, management and more. Pick up the tools required, cook it on top of Kubernetes cluster, scale the pods as needed, create your serverless functions, connect it with the database and other components. Sounds like a recipe? Yes, that’s it. This is what is cloud-native now. The application now you created can be deployed in on-premise, any cloud platform and in the hybrid cloud. The only disadvantage is that there will be a fleet of servers up and running always which incur you more cost than a true serverless.
It’s always a tradeoff. If you are sure you can stick with a single cloud provider in the entire digital transformation journey, no offence, go serverless. If not, go cloud-native with Kubernetes.
So, what’s next? Serverless less application?
It may feel like a bit futuristic, or maybe strange, but lets debate. Most of the online applications require a server only for fetching the data. These days all of us have smartphones and better computing devices with good processing capacity, wherein processing can be done at the client side. The server is needed only for storing the data. If people can store and exchange/share the data, your application will be decentralized. This idea of serverless less originally came from the concept of Flat web/open web. The “serverless less” cannot fit in all the cases. This space is very new, there is no proper protocol or standard adopted by the community for creating P2P(peer to peer) network. Still, our tech heroes are working towards it. IPFS(Internet planetary filesystem), DAT, SSB, Storj are some of the projects which I found so far.
Benefits of this architecture are very attractive than serverless. In addition to the advantages of serverless, we don’t have to invest money for infrastructure anymore. The application will be self-sustainable, will run by itself. More users in the network would mean richer experience for the users. Thus, the data is not stored centrally anywhere, but relevant data will be available virtually everywhere. Privacy is the primary concern on the internet. Yes, you might have security concerns, but I would say you will have more control over the data in this architecture. Think of a future where applications connect devices to share data and run without a server remotely.
The takeaway from this, ‘Digital transformation journey is an endless trip’.
Let’s discuss more decentralized applications in the next part.
