This week for building a client-facing mobile app, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure This week to create a client-facing mobile application, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure Cloud.
One of the development teams wanted to use an Azure Function, and the other wanted to go with the simple Azure App service plan. It was not the first use case wherein I had to choose between the two services. Serverless technology has evolved and is no longer used just for independent worker-based functionalities. I have used it for several different use cases, including building a part of an e-commerce site running purely on serverless technology.
I had to take in all the pros and cons and take a logical view to choose between the two.
Step 1:
I started to understand the abilities based on the granularity of the business requirements
What are the requirements?
a. Business logic - Does the application require a full-fledged middleware with data and business logic?
b. Lightweight system - Is the application more of a lightweight web API system?
c. Expected Traffic - What will be the dedicated traffic towards the application?
d. Code complexity - Does the application require a small piece of code or function for every request?
e. Performance - Does the application require quick responses?
f. Scalability- What are the scalability requirements?
g. Ease of Development/Deployment - What is the level of ease of deployment and development?
h. Security - What are the security requirements?
i. Cost - What are the budget or cost requirements?
j. Application Design - Complexity of the application design?
k. Governance - Is governance an issue? Are there multiple teams owning and deploying modules to production regularly?
l. Maintenance - Who will maintain the application, and what are the SLAs?
m. Redundancy- What are the application redundancy requirements?
n. Technology - Is there a technology restriction?
o. Learning curve – Technology adaption and learning curve requirements?
Step 2:
As the requirements are understood, the next step is to understand and map the capabilities and challenges and compare the two services in the context of the development teams.
The Azure function has Three plans -> 1. Consumption 2. Premium, and 3. App service plan
a. Plan fitment: The consumption plan has cold start issues, less security, and less cost. So, this has to be considered before going with this plan for a production-ready product. Neither cold starts nor security is an issue in building applications with App service.
b. Cost Issue: Premium and App service plans can avoid cold starts. They also provide better security (with VNET) but at a higher cost. The cost is the same as the App service plan.
c. Complexity: With Azure functions, if several moving parts are created, and limited people are maintaining it, then it can get complex.
d. Governance issue in the future: If we are building independent decentralized functions, standardization can be an issue in the future.
e. Latency: If a function in the future needs to wait for another function to execute, then the latency becomes an issue and complexity as well.
f. Future Business logic: If writing business logic requires building several functions or classes, then an app service integration will be the way to go.
g. Learning curve and support: It can become a learning curve issue for someone new to maintain and support the applications with multiple functions.
Concluding, both services offer several similar features, In our case, the application was simple and had some future business requirements that required processing with no end-user impact, so the App Service seemed to be an apt fit. However, the choice could be totally different for another set of requirements.
No comments:
Post a Comment