Skip to main content

Windows Azure Billing model - per-minute granularity tip

By
Windows Azure is changing. A lot of new features were released and existing one were improved. In this post I want to talk about one thing that was changed on Azure – the billing model.
Until now the paying granularity was per hour. This means that if I use a web-role for 30 minutes, then I would pay for an hour. If I use it for 1 hour and 1 minutes, then I would pay for 2 hours. Because other cloud providers offer services with per-minute granularity, Microsoft also decided to change the granularity to minutes.

This is great, you will pay only the time when you use a compute resource like web-roles, worker-roles, VMs, Mobile Services and so on). For classic application that use Azure for hosting and don’t scale (up and down) for short period of time this change will not affect the bill value at the end of the month – we will have the same flat value.
The true value of per-minute will be for application that scale up for very short period of time. For example we have a scenario where a client needs to process tens of millions of requests in a very short period of time. For example we want to process all this requests in 6 minutes – this task would repeat every day.
For this case when you need to scale for a very short period of time, a per-minutes payment solution is perfect. We can have for the same price 30 worker-roles that process the request instead of 10 or 15.
BUT, be aware of one thing – DON’T FORGET THAT YOU PAY FROM THE MOMENT WHEN THE INSTANCE STARTED AND THE DEPLOYMENT RUN ON THAT SPECIFIC INSTANCE.
This means that if you have a 6 minute job on the instance plus 10 minutes to start the instance and deploy your solution plus maybe 1 or 2 minute to stop the machine you will end up with 17-18 minutes. Is better then paying for a full hour, but we need to take care of this aspect when we prepare a cost estimation.

In conclusion, this change is great and give us the possibility to scale more with the same cost.

Comments

Post a Comment

Popular posts from this blog

How to audit an Azure Cosmos DB

By
In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...
Post a Comment
Read more

Can User Technical Profile Influence AI Architecture Decisions?

By
In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...
Post a Comment
Read more

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

By
Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...
8 comments
Read more