Azure has a variety of Virtual Machines (VMs) targeted at general use cases. Organizations often look to a bake-off between B-series and Dv3-series.
Which is right for your organization? Emerge looks at the latest generation of each family as they offer up the best price/performance ratio.
Dv3-series VMs are meant for workloads that have consistent behavior, with a balance of CPU, RAM, and storage.
For a normal application server workload, Dv3-series is often the best choice, and many companies run their production applications on it.
Dv3-series is a good place to start if you’re not sure about the performance characteristics of your application. With balanced CPU, RAM, and storage, Dv3-series makes it easier to see if one of the three is maxing out and holding your application back (e.g., memory-intensive applications may be less suitable for D-series and more appropriate for memory-optimized Ev3).
B-series VMs are also aimed at general purpose workloads, but at a lower price point than Dv3-series. B-series VMs are burstable, and ideal for applications that are CPU-intensive in short bursts, as opposed to needing 100% CPU utilization all the time. Capacity is available when needed, but there’s an assumption (captured in the pricing structure) that it’s not needed all the time.
Continuous integration servers or build servers are good candidates for B-series VMs. These resources have lots of short bursts while a build is going on but are idle the rest of the time. Average CPU usage is low, but when the build is running, you’re getting great performance—allowing quick builds and happy developers.
Virtual desktop applications or line-of-business applications are also suitable for B-series VMs—longer bursts during business hours with not much going on during evenings and weekends.
An example of a bad fit is video transcoding. This has high CPU usage all the time, so it needs the full-time high performance of D-series VMs.
If your workloads can run on smaller instances and don’t require lots of memory, then B-series might be your best bet. The smallest B-series instance is Standard_B1ls, with 1 virtual CPU (vCPU) and 4GiB of memory. B-series instances have more options on the smaller end of the scale. All the smaller sizes, from Standard_B1ls to Standard_B1ms, have 1 vCPU with memory specs from 0.5 GiB to 2 GiB.
Once you get to Standard_B2ms, it’s the same as Standard_D2_v3, with 2 vCPUs and 8 GiB of memory. (To dig into the full numbers, check out Azure VM Instance types.)
Let’s compare apples to apples by looking at Standard_D2_v3 vs. Standard_B2ms. Both have 2 vCPUs and 8 GiB memory.
Let’s start with cost. Here’s an On-Demand price comparison for the US West 2.
|Instance||CentOS or Ubuntu Linux||Windows|
It’s obviously cheaper to use the Standard_B2ms but there is something else to consider.
The amount you pay for a D-series instance is always the same—they’re designed with consistent workloads in mind. Burstable VMs work differently.
Burstable VMs are ideal for workloads that do not need full CPU performance all the time (e.g., web servers or dev build environments). The peaks and valleys of demand create a market in CPU credits.
When demand is beneath baseline performance, VMs are idle. When demand exceeds baseline performance, organizations spend those same VM credits.
Organizations wanting the preferential pricing of burstable VMs must judge the correct base CPU performance to commit to striking a balance between cost and CPU consumption.
If usage is below the CPU baseline, the VM will accumulate credits. Select too low a CPU base, and the VM will rarely accumulate credits and will be throttled at the CPU baseline: Pick too high a CPU base and the economics of Bs-series VMs don’t make sense.
|Size||Base CPU Perf||Max CPU Perf||Initial Credits||Credits banked / hour||Max Banked Credits||Pay as you go|
Burstable VMs and their CPU performance parameters
A single CPU credit is equal to one vCPU running at 100% utilization for one minute, and each instance earns a set rate of CPU credits per hour.
A B2ms instance, for example, earns 36 CPU credits per hour. Comparing this rate to CPU utilization gives you a baseline performance (as a percentage) for each vCPU that’s the break-even point for earning or using CPU credits.
A B2ms instance has two vCPUs. Divide 36 by two, then 18/60 minutes, and you get a baseline rate per CPU of 30%. Azure blends this number into one “Base CPU perf of VM” value of 60%.
When the vCPU utilization is below 60%, more CPU credits are earned than used. Earned CPU credits cover future bursts.
Azure looks at the accrual model as a bucket of CPU credits, with a capacity based on how many credits an instance can earn in 24 hours, which is why Standard_B2ms can accrue up to 864 credits.
Accrued CPU credits are lost after specific events. When a VM is redeployed, and the VM moves to another node, accumulated credit is lost. If the VM is stopped/started, but remains on the same node, the VM retains the accumulated credit.
In the end, as with all Azure decisions, cost and usage drive the right decision.
There are dozens of variables in play—from the cloud architecture to the number of users to your work schedule.
The only way to know for certain is to have full visibility into how you’re using Azure.
Our cloud cost management platform gives you the Azure VM visibility you need, including features like Rightsizing that can make recommendations to lower your Azure VM costs without lowering performance.
When it comes to Azure VMs, the right instance choice isn’t a cut-and-dry decision.
B-series VMs may look like the option to save money (without lowering performance), but loses out to D-series VMs when CPU baselines and insufficient CPU credits throttle performance.
And that’s really the key question for choosing between D-series and B-series: Which meets performance expectations and costs the least?
Once you have visibility the answer will be clear.