My website has a free "live test" tool. In order to reduce serverless costs and avoid abuse, I'd like to run it on one separate machine. If users spam the machine, it'll become slower, but it won't ruin me.
Is there a tool in Azure or AWS that would allow this? To have an Azure function 24/7 running on a low-cost server -- without any scaling and so on.
Is there a tool in Azure or AWS that would allow this? To have an
Azure function 24/7 running on a low-cost server -- without any
scaling and so on.
Yes, both providers have a pay per consumption model that you could use Azure Functions / AWS Lambda. However, you pay based on resource consumption * time spent to process each request. It means you can easily suffer Denial of Wallet
As an alternative, you can spin up a very cheap Virtual Machine and route requests to it.
Related
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service (EDIT: for a restful API) associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
Well, an Azure Function is a different beast than an App Service. An Azure function is triggered by an external event or a timer. It then executes the code of the function. When hosted on a consumption plan this execution is allowed to run for 5 or 10 minutes max. When you need a longer execution time you need to run it on an App Service Plan.
An App Service can host any app you've created. Like a website (that runs continuously and doesn't need to be triggered before it starts doing something) or an api for example.
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
Correct, when hosting Azure Functions in an App Service Plan you are responsible for making sure the app service is scaled to allow the function to perform well under load. Thats why the consumption plan is designed to handle this so the developer can focus on the functionality and does not need to worry about the infrastructure.
So, for integration scenario's azure functions are a very natural fit. For web sites an App Service might be the best solution.
To address your comment:
I should have mentioned that this question was in the context of hosting a restful API and not a UI application. In this scenario, I'm not seeing much difference between a Function and App Service, but please correct me if I'm missing something
A couple of things: For one, there is a certain sweet spot. If traffic is heavy enough a consumption plan based azure function might be more costly than having a dedicated app service plan. That depends of course on a lot of factors (CPU usage, request duration etc.). Also, you won't be able to use things like Asp.Net Core Middleware out of the box.
Finally, I'd argue that if your api is becoming large enough managing a single asp.net core solution may be easier than having to manage a lot of azure functions with small functions or one azure function project with lots and lots of functions, but hey, that's just my opinion (haven't actually dealt with it to be honest)
Some resources to consider:
https://www.taztopia.com/single-post/2019/07/28/azure-function-vs-web-app-aka-serverless-vs-paas
https://dasith.me/2018/01/20/using-azure-functions-httptrigger-as-web-api/
The main difference is in how you pay for it:
Azure Functions Consumption plan you pay per execution
Azure Functions in an App Service (dedicated plan) you pay for the allocated hardware per minute.
You also have control of which VNET your functions run in when you use an app service plan. You may have security requirements that make this important.
You are correct that if you run it in an app service that is not configured to scale, then throughput will be limited by the allocated hardware.
For details see: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
If you are having limited and predictable workload then deploy az function in AppService plan with supports VNET integration for private compute otherwise go for Premium plan which will provide autoscaling capability of your compute environment.
Is it possible to load balance between multiple Function apps (say 10 of them) on consumption plan in the same region? Each app would have the same source code and can individually be upgraded to prevent downtime. Unfortunately, sometimes I get 503 errors when I deploy changes to a Function app, in which case I have to manually restart the app in the portal. Auto-swap has the same issues. This is not acceptable in a production environment, so I'm thinking of using multiple apps. I looked into using Traffic Manager, but that seems to be suited for a multi-region deployment.
You can use Traffic Manager also for backends that are all in the same region. However, I would rather recommend to use Azure Front Door as it provides more capabilities and faster failover times.
you can use the same solution, as Microsoft recommended for HA (totally agree with previous commentator):
https://learn.microsoft.com/en-us/azure/azure-functions/functions-geo-disaster-recovery
Please help me understand why we say azure functions is a serverless compute service. It does require cloud to host it and run. Cloud is also a server still why we are saying it is serverless?
Serverless computing does not mean that servers are out of the picture. Servers are very much required, just like they have been for all these years, or else, where will your code run. The reason why the phrase was coined is that as a developer, you do not need to worry about what server your code runs on. In fact, you do not know which server it eventually runs on. Once your code is deployed, Azure assigns the responsibility of executing the code to the next available server. What Azure ensures, and what is ultimately important for you, is that your code will execute whenever required.
Ref: Serverless Computing with Azure Functions
Hope it makes sense :)
To get a better idea this is how we evolved. Cloud providers are making sure we should only worry about the business logic but nothing else.
IaaS (Infrastructure as a service)
You get a running VM somewhere in the data centre but you are required to maintain everything. From Deployment to patching your VMs or anything running on the VM.
PaaS(Platform as a service)
You are not longer required to maintain platForm but you are still responsible to manage your server in terms of load balancing etc.
FaaS(Function as a service)
Servers are abstracted from you . You are only required to maintain your code without worrying about what's under the hood or how to load balance your servers. It's then cloud provider responsibility to package your code and run it for you. But servers are still there.
Going by the official documentation of Azure Serverless computing service, Azure Functions can be defined as;
Azure Functions is a serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure. Use Azure Functions to run a script or piece of code in response to a variety of events.
Azure Functions is an event driven, compute-on-demand experience that
extends the existing Azure application platform with capabilities to
implement code triggered by events occurring in virtually any Azure or
3rd party service as well as on-premises systems. Azure Functions
allows developers to take action by connecting to data sources or
messaging solutions, thus making it easy to process and react to
events. Azure Functions scale based on demand and you pay only for the
resources you consume.
Here the serverless compute service is like a metaphor which implies, the end user doesn't need to manage the servers or infrastructure to run the applications over the Azure and can spend time to focus on managing and improving the business logic.
Few more points to consider,
Serverless in Azure builds on an open-source foundation, the core of
which is Azure Functions, an event-driven compute experience and open
source project. Community contributions include support for new
languages, integrations and deployment targets.
Azure Functions can be used on-premises, in hybrid environments such as Azure Stack, on IoT Edge devices and deployed on top of orchestrators such as Kubernetes – as well as in other clouds.
They enable faster time to market with lower infrastructure and operating costs.
There are heaps of definition of serverless which you can easily google. But I will share my understanding anyways.
1. It does require cloud to host it and run.
You are correct with this. But anything on Cloud requires Cloud, doesn't it? Azure being one of the cloud providers consists of hundreds of services to cater to different needs people are after from using Cloud.
2. Cloud is also a server still why we are saying is serverless
This is not quite right. Cloud is different from a server. Server is a physical box sitting somewhere. With hundreds of thousands of servers all over the world, Cloud hosts all sorts of different services on these servers.
The reason we say Functions are serverless is that the infrastructure of hosting a Function is abstracted away from devs. It is still deployed to some servers but Azure is responsible for all the resource managing, configuration, load balancing, scaling and networking etc. It allows developers to focus primarily on their code, not having to worry about servers.
We are working on architecture of new web application to be hosted on Azure. This application would run only in day time (Say 9AM to 5PM). What I read so far about Azure is we would continue be billed even when we stop the deployment.
However in case of Azure VM (IAAS) billing stops when we stop the VM.
Client is keenly interested in running the IT cost to the minimum. We are planning to use WASABi/Auto-scaling block to auto shutdown & auto-start the app to run only during (9AM-5PM)
Deploying application every morning & deleting every evening even programmatically doesn't sound like a good architecture.
Should we target the app for VM rather than Azure web role?
While hourly billing cost is definitely a consideration and it is true that if you stop a VM in IaaS, billing stops, there are other considerations as well. Some of them are:
With Cloud Services, you have to architect the application in a certain way to take advantage of statelessness there. So there may be a bit of a learning curve there. With Virtual Machines, in theory you can build an application the way you are used to and deploy that in the cloud.
With Cloud Services, the major advantage is that you don't have to maintain the VM. This is something Microsoft does that for you. So there's little or no IT-admin overhead. With VMs, maintaining the VM is your responsibility so that's an additional cost which is recurring as well (assuming you (or your client) have an IT Admin kind of guy on the payroll).
Generally speaking, if the application is a stand-alone application with quite simple deployment topology and is brand new application it is recommended that you write them as Cloud Service but do take the costs (development / IT admin) into consideration as well.
When you stop the virtual machine through a standard shutdown (through the machine itself for example), it does continue to incur charges. The portal will eventually show it as shutdown, but the VM still has resources allocated.
However, if you stop the machine through the portal, API, or PowerShell, it will stop and DEALLOCATE the machine. This means the VM will use storage space, but will not incur compute charges.
Simply schedule the deallocation of the machines during off-hours, and you will only page for the usage during the day.
I am recently evaluating Windows Azure. One of the problems I found is that Azure start charging as soon as the app is deployed even if it is in the testing stage.
I want to ask existing Azures how much of your tests are done locally and how much are done after it is deployed? Does Azure provide any means of testing web services locally?
Many thanks.
Yes, Azure provides an emulation framework that largely (but not completely) mimics the Azure deployment environment. This is usually sufficient for testing.
Costs of test deployments can be controlled somewhat, however:
It's possible to deploy "extra-small" instances that are significantly less expensive than larger instances, at the expense of throughput - which unless you're doing load testing isn't usually an issue
You won't generally need to have multiple instances of a role deployed, just one will usually do, unless you have major concurrency issues under load
Some of the cost of Azure is in data traffic, which will obviously be less expensive for test instances
It's not necessary to have test instances permanently available. They can be torn down or re-deployed at will; if your environment becomes sophisticated this can be done programmatically by a continuous integration engine.
In practice we're finding that the cost of test instances is relatively insignificant compared to the cost of our developers and the alternative, which would be to provision and maintain our own data centre.
In particular, being able to quickly spin up a test environment that is a direct mimic of production in a few minutes is a very powerful feature.
Windows azure already provide option to do testing locally.
The Microsoft Azure storage emulator provides a local environment that emulates the Azure Blob, Queue, and Table services for development purposes. Using the storage emulator, you can test your application against the storage services locally, without creating an Azure subscription or incurring any costs. When you're satisfied with how your application is working in the emulator, you can switch to using an Azure storage account in the cloud.
To get complete detail please check link below.
https://azure.microsoft.com/en-in/documentation/articles/storage-use-emulator/