Serverless @ enterprise
Serverless is a buzzword in the software industry right now after Microservices. As with any other technology revolution, startups will jump into it and Enterprise will only be entering to Serverless slowly. Earlier the technologies would be Enterprise ready from the starting itself. But now a days it seems Enterprise support is little behind at the technology edge.
This post is an attempt to examine the Serverless offering is ready for enterprise. Since the series is Azure @ Enterprise, lets see from the Azure side.
Cost
If we consider cost, that was not a big factor for Enterprise. They usually buy big boxes to meet their peak load and enjoy during the normal load and struggle during the heavy load. Whatever capacity planning we do there are chances that the real load differ because of unknowns.
But with the Cloud adoption, enterprise started thinking about cost. If they had embraced 2 pizza team strategy or Microservice architecture style or devOps teams there are high chances that small teams started maintaining services / applications end to end. In order to prove their success they are forced to reduce cost in the operations. Ultimately cost becomes a factor in Enterprise.
This think enterprise to adopt Serverless or true pay per use cloud offerings. At present in Azure, Functions are the real pay per use service. Hence the title limited to Functions. Cost wise, Functions has got good score.
Versioning
The versioning might be a concern if the enterprise is using blue green deployment where the applications move to production and there might be some rollbacks required.
In Azure Functions there is no versioning concept except pulling from the source control repo. But in Amazon lambda which is the Function equivalent in Amazon cloud, there is versioning. We can have smooth version control of Functions in even in the production environment.
Security
Next factor is securing the Enterprise. There will be less chance for the Enterprise to compromise on security because something is cheap. If we take that thought to Functions, there are 2 challenges with Functions right now.
Securing external internet facing Functions
This can be done via API Gateways. There is not much challenge in that once the suitable gateway is selected. It ensure there is no DDoS, brute force, injections etc...
Securing internal Functions
There could be lot of internal services which are supposed to be exposed inside Enterprise. Normally on premise network would be protected using appropriate measures. The end points might not be visible to outside. This is the area Functions lag.Suppose we need to have an internal Function there are 2 options. One is to setup the firewall rules. Second to host inside vNet or virtual network. Then the Functions end point will not be accessible outside.
The best way is to use vNet but the problem here is pay per use Functions don't support hosting inside vNet unless they are under AppServiceEnvironment (ASE). AppServiceEnvironment provides an isolated environment for the Enterprise to host things. But the problem with ASE is that it is highly costly. around $1200/month. The real problem is that the cost is fixed regardless of the usage. We lost everything we talked about Serverless if it is fixed billing.
Amazon Lambda
Amazon have VPC instead of vNet. It doesn't seems there is a fixed high cost if we wanted to host Lambda inside the VPC. Please note the information is obtained from google and feel free to correct.
Some links below on Lambda and VPC
https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/
https://aws.amazon.com/blogs/apn/why-use-aws-lambda-in-a-custom-vpc/
More differences
There are more links out there which compare Azure Function with Lambda and Cloud Functions from Google cloud.https://cloudacademy.com/blog/microsoft-azure-functions-vs-google-cloud-functions-fight-for-serverless-cloud-domination-continues/
No comments:
Post a Comment