"It Doesn't Work That Way in Enterprise". This is a famous quote when we work in enterprise. Many things which does in a tick at startups never work that way in enterprise. Coming to Azure development, if we want to create a new Azure Function it might be just an entry in ARM template in startup and next deployment will have the Azure Function, but it might be 2 weeks process in Enterprise. Sometimes the Azure Function might have to be created manually based on tickets in Enterprise after multi level approvals and refer its name in ARM.
The focus of this post is 'Is Azure Function Enterprise ready?' Azure Functions is the flagship product from Microsoft to meet the demands of Serverless world.
Signing the assemblies
The basic thing in .Net is to sign our assemblies before shipping them. If we use third party libraries and those contain unsigned assemblies, we cannot sign our assemblies.
Why we are discussing this basics with Functions? The current Azure Functions SDK which is coming via nuget package has references / dependencies which are not signed!!!
At the time of writing this post, Visual Studio 2017 (15.4.0) creates Azure Function projects which has references to unsigned dlls.
To be more precise, SDK has dependency to Microsoft.Azure.WebJobs.Extensions.Http which has the assembly with same name. If we open the assembly in JustDecompile, we can see the below.
Microsoft.Azure.WebJobs.Extensions.Http, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
It is reader choice to decide whether a SDK with unsigned assembly is Enterprise ready.
Beta dependencies of Azure Functions SDK
No need to explain in detail. The Function SDK has dependency Microsoft.Azure.WebJobs.Extensions.Http which is still in beta1 stage. Yes its the same which has unsigned assembly referred above. The latest Functions.SDK version available at the time of writing this post in nuget repo is 1.0.7 and it still has this beta reference. Refer the below link for dependencies. The SDK is in production but not the dependencies.
Another thing Enterprise loves to put into production.
Pricing & vNet capability
If a service is internal ie called by other front end services or scheduled tasks etc..., enterprise never want to put it publicly. The solution in Azure Function to have internal service is to use the AppServiceEnvironment+AppServicePlan combination. What we loose there is the cost factor. ASE has fixed money in it and never pay per use.
Execution timeout of Functions
At the of writing this post the max timeout of a Function is 10 mins if it is in consumption plan ie the real pay per use model. But Enterprise may need to execute long running operations greater than 10 mins if there is queuing system or scheduled processes and those should be strictly internal. In order to achieve it they can never use pay per use model of Functions, instead use either ASE+Function or WebJobs. It would be considered as road block by enterprise users.
It seems Microsoft wanted to have an answer to Amazon Lambda in the Serverless world and someone hacked Azure WebJobs to become Azure Functions. But its really excellent idea for start ups to reduce time to market and reduce upfront investments.
Comparing Amazon v/s Azure Function for enterprise use is altogether separate topic.
Comparing Amazon v/s Azure Function for enterprise use is altogether separate topic.
Disclaimer
The Azure evolves at a fast pace and the facts might not be relevant in future.
No comments:
Post a Comment