If you’ve provisioned a Virtual Machine (VM) via the Azure Portal in recent months, I am sure you have noticed a new series of VM that sits at a cheaper price point to some of the regular alternatives. This is the B-series and it has some special features.
Immediately you would think based on the specifications presented that this series was a relative bargain in comparison to the D series. Take a look at the table below to see a comparison of prices presented for B and Dv3 series VMs: (NOTE: These are from an EA subscription, prices are relative)
Comparing a B2ms and a D2s_V3, there is a saving of approximately ten euro per month. You can see they have the same amount of vCPU and RAM. Which is the most common deciding factor when sizing a VM. However, if you look closer you’ll notice the B series actually has more Max IOPS, how or why is that possible? (Read a previous post on iops etc here)
The B-series VMs are designed to offer “burstable” performance. They leverage flexible CPU usage, suitable for workloads that will run for a long time using a small fraction of the CPU performance possible and then spike to needing the full power of the CPU due to incoming traffic or required work.
This burst isn’t unlimited though. While B-Series VMs are running in the low-points and not fully utilizing the baseline performance of the CPU, your VM instance builds up credits. When the VM has accumulated enough credit, you can burst your usage, up to 100% of the vCPU for the period of time when your application requires the higher CPU performance.
Here is a great example from Microsoft Docs of how credits are accumulated and spent.
“I deploy a VM using the B1ms size for my application. This size allows my application to use up to 20% of a vCPU as my baseline, which is .2 credits per minute I can use or bank.
My application is busy at the beginning and end of my employees work day, between 7:00-9:00 AM and 4:00 – 6:00PM. During the other 20 hours of the day, my application is typically at idle, only using 10% of the vCPU. For the non-peak hours I earn 0.2 credits per minute but only consume 0.l credits per minute, so my VM will bank .1 x 60 = 6 credits per hour. For the 20 hours that I am off-peak, I will bank 120 credits.
During peak hours my application averages 60% vCPU utilization, I still earn 0.2 credits per minute but I consume 0.6 credits per minute, for a net cost of .4 credits a minute or .4 x 60 = 24 credits per hour. I have 4 hours per day of peak usage, so it costs 4 x 24 = 96 credits for my peak usage.
If I take the 120 credits I earned off-peak and subtract the 96 credits I used for my peak times, I bank an additional 24 credits per day that I can use for other bursts of activity.”
So, there was quite a bit of maths there, what are the important points?
- Baseline vCPU performance. This dictates your earn/spend threshold. There is a chart here.
- Peak utilisation consumption. If this is not allowing you to bank credits, you will eventually end up in a situation where you cannot burst. Size up your VM.
- Automation doesn’t work here, you only earn credits when the VM is allocated.
Overall I think the B-series is a good option, but only in specific scenarios. A different way of thinking is required to size and manage your application. If you get it right, you can make some savings on running a standard VM.
There is a Q&A on some common topics here.