There’s a lot of talk about multi-cloud architecture – and apparently, a lot of disagreement about whether there is actually any logical use case to use multiple public clouds.
How many use multi-cloud already?
First question: are companies actually using a multi-cloud architecture?
According to a recent survey by IDG: yes. More than half (55%) of respondents use multiple public clouds: 34% use two, 10% use three, and 11% use more than three. IDG did not provide a term definition for multi-cloud. Given the limited list of major public clouds, the “more than three set” might be counting smaller providers. Or, respondents could be counting combinations such as AWS EC2 and Google G-Suite or Microsoft 365.
There certainly are some using multiple major providers – as one example, ParkMyCloud has at least one customer using compute infrastructure in AWS, Azure, Google Cloud, and Alibaba Cloud concurrently. In our observation, this is frequently manifested as separate applications architected on separate cloud providers by separate teams within the greater organization.
Why do organizations (say they) prefer multi-cloud?
With more than half of IDG’s respondents reporting a multi-cloud architecture, now we wonder: why? Or at least – since we humans are poor judges of our own behavior – why do they say they use multiple clouds? On survey, public cloud users indicated they adopted a multi-cloud approach to get best-of-breed platform and service options, while other goals included cost savings, risk mitigation, and flexibility.
Are these good reasons to use multiple clouds? Maybe. The idea of mixing service options from different clouds within a single application is more a dream than reality. Even with Kubernetes. (Stay tuned for a rant post on this soon).
Cloud economist Corey Quinn discussed this on a recent livestream with ParkMyCloud customer Rob Weaver. He asked Rob why his team at Workfront hadn’t yet completed a full Kubernetes architecture.
Rob said, “we had everything in a datacenter, and we decided, we’re going to AWS. We’re going there as fast as we can because it’s going to make us more flexible. Once we’re there, we’ll figure out how to make it save us money. We did basically lift and shift. …. Then, all of the sudden, we had an enormous deal come up, and we had to go into another cloud. Had we taken the approach of writing our own Lambdas to park this stuff, now GCP comes along. We would have to have written a completely different language, a completely different architecture to do the same thing. The idea of software-as-a-service and making things modular where I don’t really care what the implementation is has a lot of value.”
Corey chimed in, “I tend to give a lot of talks, podcasts, blog posts, screaming at people in the street, etc. about the idea that multi-cloud as a best practice is nuts and you shouldn’t be doing it. Whenever I do that, I always make it a point to caveat that, ‘unless you have a business reason to do it.’ You just gave the perfect example of a business reason that makes sense – you have a customer who requires it for a variety of reasons. When you have a strategic reason to go multi-cloud, you go multi-cloud. It makes sense. But designing that from day one doesn’t always make a lot of sense.”
So, Corey would say: Rob’s situation is the one use case where a multi-cloud architecture actually makes sense. Do you agree?
Cloud spend optimization is always top of mind for public cloud users. It’s usually up there with Security, Governance, and Compliance – and now in 2020, 73% of respondents to Flexera’s State of the Cloud report said that ‘Optimize existing use of cloud (cost savings)’ was their #1 initiative this year.
So – what the heck does that mean? There are many ways to spin it, and while “cost optimization” is broadly applicable, the strategies and tactics to get there will vary widely based on your organization and the maturity of your cloud use.
Having this discussion within enterprises can be challenging, and perspectives change depending on who you talk to within an organization – FinOps? CloudOps? ITOps? DevOps?. And outside of operations, what about the Line of Business (LoB) or the Application owners? Maybe they don’t care about optimization in terms of cost but in terms of performance, so in reality optimization can mean something different to cloud owners and users based on your role and responsibility.
Ultimately though, there are a number of steps that are common no matter who you are. In order to facilitate this discussion and understand where enterprises are in their cloud cost optimization journey, we created a framework called the Cloud Cost Optimization Maturity Curve to identify these common steps.
Cloud Spend Optimization Maturity Curve
While cloud users could be doing any combination of these actions, this is a representation of actions you can take to control cloud spend in order of complexity. For example, Visibility in and of itself does not necessarily save you money but can help identify areas ripe for optimization based on data. And taking scaling actions on IaaS may or may not save you money, but may help you improve application performance through better resource allocation, scaling either up (more $$$) or down (less $$$).
Let’s dig into each in a little more detail:
Visibility – visibility of all costs across clouds, accounts, and applications. This is cloud cost management 1.0, the ability to see cost data better through budgeting, chargeback, and showback.
Schedule suspend – turn off idle resources like virtual machines, databases, scale groups, and container services when not being used, such as nights and weekends based on usage data. This is most common for non-production resources but can have a big bang in terms of savings – 65% savings is a good target that many ParkMyCloud customers achieve even during a free trial.
Delete unused resources – this includes identifying orphaned resources and volumes and then deleting them. Even though you may not be using them, your cloud provider is still charging you for them.
Sizing IaaS (non-production) – many enterprises overprovision their non-production resources and are using only 5-10% of the capacity of a given resource, meaning 90% is unused (really!) so by leveraging usage data you can get recommendations to resize those under utilized resources to save 50% or more.
RI / Savings Plan Management – AWS, Azure, and Google provide the ability to pre-buy capacity and get discounts ranging from 20-60% based on your commitments in both spend and terms. While the savings make it worthwhile, this is not a simple process (though it’s improved with AWS’s savings plans) and requires a very good understanding of the services you will need 12-36 months out.
Scaling IaaS (prod) – this requires collecting data and understanding both the infrastructure and application layers and taking sizing actions up or down to improve both performance and cost. Taking these actions on production resources requires strong communication between Operations and LoB.
Optimizing PaaS – virtual machines, databases, and storage are all physical in nature and can be turned off and resized, but these top the maturity curve since many PaaS services have to be optimized in other ways like scaling the service up/down based on usage or rearchitecting parts of your application.
For more ways to reduce costs, check out the cloud waste checklist for 26 steps to take to eliminate wasted spend at a more granular level.
When most enterprise users hear that their organization will start heavily using ServiceNow governance, they assume that their job is about to get much harder, not easier. This stems from admins putting overly-restrictive policies in place, even with the good intentions of preventing security or financial problems. The negative side effect of this often manifests itself as a huge limitation for users who are just trying to do their job. Ultimately, this can lead to “shadow IT”, angry users, and inefficient business processes. So how can you use ServiceNow governance to increase efficiency rather than prohibit it?
What is ServiceNow governance?
One of the main features of ServiceNow is the ability to implement processes for approvals, requests, and delegation. Governance in ServiceNow includes the policies and definitions of how decisions are made and who can make those decisions. For example, if a user needs a new virtual machine in AWS, they can be required to request one through the ServiceNow portal. Depending on the choices made during this request, cloud admins or finance team members can be alerted to this request and be asked to approve the request before it is carried out. Once approved, the VM will have specific tags and configuration options that match compliance and risk profiles.
What Drives Governance?
Governance policies are implemented with some presumably well-intentioned business goal in mind. Some organizations are trying to keep risk managed through approvals and visibility. Others are trying to rein in IT spending by guiding users to lower-cost alternatives to what they were requesting.
Too often, to the end user, the goal gets lost behind the frustration of actions being slowed, blocked, or redirected by the (beautifully automated) red tape. Admins lose sight of the central business needs while implementing a governance structure that is trying to protect those business needs. For users to comply with these policies, it’s crucial that they understand the motivations behind them – so they don’t work around them.
In practice, this turns into a balancing act. The guiding question that needs to be answered by ServiceNow governance is, “How can we enable our users to do their jobs while preventing costly (or risky) behavior?”
Additionally, it’s critical that new policies are clearly communicated, and that they hook into existing processes. Not to say that this is easy. To be done well, it requires a team of technical and business stakeholders to provide their needs and perspectives. Knowing the technical possibilities and limitations must match up with the business needs and overall organizational plans, while avoiding roadblocks and managing edge cases. There’s a lot to mesh together, and each organization has unique challenges and desires, which makes this whole process hard to generalize.
The End Result
At ParkMyCloud, we try to help facilitate these kinds of governance frameworks. The ParkMyCloud application allows admins to set permissions on users and give access to teams. By reading from resource tags, existing processes for tagging and naming can be utilized. New processes around resource schedule management can be easily communicated via chat or email notifications. Users get the access they need to keep doing their job, but don’t get more access than required. Employing similar ideas in your ServiceNow governance policies can make your users successful and your admins happy.
Now more than ever, organizations have been implementing multi-cloud environments for their public cloud infrastructure.
We not only see this in our customers’ environments: a growing proportion use multiple cloud providers. Additionally, industry experts and analysts report the same. In early June, IDG released its 8th Cloud Computing Survey results where they broke down IT environments, multi-cloud and IT budgets by the numbers. This report also goes into both the upsides and downsides using multiple public clouds. Here’s what they found:
More than half (55%) of respondents use multiple public clouds:
34% use two, 10% use three, and 11% use more than three
49% of respondents say they adopted a multi-cloud approach to get best-of-breed platform and service options.
Interestingly, within multi-cloud customers of ParkMyCloud, the majority are users of AWS and Google Cloud, or AWS and Azure; very few are users of Azure and Google Cloud. About 1% of customers have a presence in all three.
Multi-Cloud Across Organizations
The study found that the likelihood of an organization using a multi-cloud environment depends on its size and industry. For instance, government, financial services and manufacturing organizations are less likely to stick to one cloud due to possible security concerns that come with using multiple clouds. IDG concluded that enterprises are more concerned with avoiding vendor lock-in while SMBs are more likely to make cost savings/optimization a priority (makes sense, the smaller the company, the more worried they are about finances).
Fewer than half of SMBs (47%) use multiple public clouds
Meanwhile, 66% of enterprises use multiple clouds
What are the advantages of multi-cloud?
Since multi-cloud has been a growing trend over the last few years, we thought it’d be interesting to take a look at why businesses are heading this direction with their infrastructure. More often than not, public cloud users and enterprises have adopted multi-cloud to meet their cloud computing needs. The following are a few advantages and typically the most common reasons users adopt multi-cloud.
Workload Optimization – place your workloads to optimize for cost and performance
Cloud providers’ unique capabilities – take advantage of offerings in AI, IOT, Machine Learning, and more
While taking advantage of features and capabilities from different cloud providers can be a great way to get the most out of the benefits that cloud services can offer, if not used optimally, these strategies can also result in wasted time, money, and computing capacity. The reality is that these are sometimes only perceived advantages that never come to fruition.
What are the negatives?
As companies implement their multi-cloud environments, they are finding downsides. A staggering 94% of respondents – regardless of the number of clouds they use or size of their organization – find it hard to fully take advantage of their public cloud resources. The survey cited the biggest challenge is controlling cloud costs – users think they’ll be saving money but end up spending more. When organizations migrate to multi-cloud they think they will be cutting costs, but what they typically fail to account for is the growing cloud services and data as well as lack of visibility. For many organizations we talk to, multiple clouds are being used because different groups within the organization use different cloud providers, which makes for challenges in centralized control and management. Controlling these issues brings about another issue of increased costs due to the need of cloud management tools.
Some other challenges companies using multiple public clouds run into are:
Data privacy and security issues (38%)
Securing and protecting cloud resources (31%)
Governance/ compliance concerns (30%)
Lack of security skills/expertise (30%)
Configuring and managing different CSPs requires deep expertise which makes it more of a pressing need to find employees that have the experience and capabilities to manage multiple clouds. This means that more staff are needed to manage multi-cloud environments confidentiality so it can be done in a way that is secure and highly available. The lack of skills and expertise for managing multiple clouds can become a major issue for organizations as their cloud environments won’t be managed efficiently. In order to try fix this issue, organizations are allocating a decent amount of their IT budget to cloud-specific roles with the hope that adding more specialization in this area can help improve efficiency.
Multi-Cloud Statistics: Use is Still Growing
The statistics on cloud computing show that companies not only use multiple clouds today, but they have plans to expand multi-cloud investments:
In a survey of nearly 551 IT people who are involved in the purchasing process for cloud computing, 55% of organizations currently use multiple public clouds.
Organizations using multiple cloud platforms say they will allocate more (35%) of their IT budget to cloud computing.
SMBs plan to include slightly more for cloud computing in their budgets (33%) compared to enterprises
While this seems significant, if measured in dollars, enterprises plan a much larger cloud spend than SMBs do $158 million compared to $11.5 million.
The Future of Managing Cloud Costs for Multi-Cloud
As cloud costs remain a primary concern, especially for SMBs, it’s important organizations keep up with the latest cloud usage trends to manage spend and prevent waste. To keep costs in check for a multi-cloud, you can make things easier for your IT department and implement an optimization tool that can track usage and spend across different cloud providers.
For more insight on the rise of multi-cloud and hybrid cloud strategies, and to demonstrate the impact on cloud spend, check out the drain of wasted spend on IT budgets here.
Azure Spot Virtual Machines are a purchasing option that can save significant amounts on infrastructure, for certain types of workloads. Azure Spot VMs are not created as a separate type of VM in Azure, instead, it’s a capability to bid for spare capacity at a discount from on demand pricing. But there’s one caveat: at any given point in time when Azure needs the capacity back, the Azure infrastructure will deallocate and evict the Spot VM from your environment.
In the past, Azure offered Low Priority VMs, which were charged at a fixed price. In March this year, that option was replaced by Azure Spot VMs. With the newer option, you bid by indicating the maximum price you are willing to pay for a VM.
Why Use Azure Spot VMs
Microsoft allows you to use their unused compute capacity at a discounted rate. These discounts are variable and can go up to >90% of the pay-as-you-go rates, depending on the size of the VM and the unused capacity available. The amount of capacity available can vary based on region, time of day, and more.
You can use Azure Spot VMs for workloads that are not critical or need to run 24×7. For example, a basic scenario would be for testing the load of a particular workload that you want to perform for a fraction of the cost. Other use cases include batch processing, stateless applications that can scale out, short-lived jobs that can be run again if the workload is evicted, etc.
Keeping in mind that there are no SLAs or availability guarantees for these Spot VMs. The most significant concern users have is that they may not be available to you to get resources, especially at peak load times. The issue is not with the service, it’s with how it is intended to work. Be aware of this when making the decision to use this approach.
Some important things to consider when using Azure Spot VMs:
VMs are evicted based on capacity or by if the price exceeds your maximum set price
Azure’s infrastructure will evict Spot VMs if Azure needs the capacity for pay-as-you-go workloads
B-series and promo versions of any size (like Dv2, NV, NC, H promo sizes) are not supported
A Spot VM cannot be converted to a regular VM or vice versa. You would have to delete the VM and attach the disk to a new VM
VMs that are evicted and deallocated are not turned back on when capacity or price comes back inside allowed limits, you will need to manually turn them back on
You will be unable to create your VM if the capacity or pricing are not inside the allowed limits
How to Use Azure Spot VMs
You have two choices when deploying Azure Spot VMs. When you enable the feature in your Azure environment, you need to select what type of eviction and eviction policy you want for the capacity:
Types of eviction:
By capacity only – the VM is evicted when Azure needs capacity. In other words, your maximum price for the spot VM is the current price of the regular VM
By maximum price – the VM is evicted when the spot price is greater than the maximum price
Eviction policy (currently available):
Stop / Deallocate
The eviction policy for Spot VMs is set to Stop / Deallocate which moves your evicted VMs to the stopped-deallocated state, allowing you to redeploy the evicted VMs at a later time. Remember reallocating Spot VMs will be dependent on there being available Spot capacity. However, the deallocated VMs will count against your spot vCPU quota and you will be charged for your underlying disks. If your Spot VM is evicted, but you still need capacity right away, Azure recommends you use a standard VM instead of Spot VM.
Do Azure Spot VMs Save You Money?
Yes: these discounted VMs can save you money. How much will vary? Azure Spot VMs prices are not fixed like standard instances, they change over the day and vary based on the supply and demand in a particular region.
Azure Spot VMs are a good option that can provide cost savings if your application can handle unexpected interruptions.
Use Spot VMs as part of your full cost-saving strategy. For on-demand workloads that aren’t needed 24×7, ensure you have appropriate on/off schedules in place. All VMs should be properly sized to the workload. You can start automating these Azure cost optimization tasks with ParkMyCloud today.
There are a wide range of Microsoft Azure VM types that are optimized to meet various needs. Machine types are specialized, and vary by virtual CPU (vCPU), disk capability, and memory size, offering a number of options to match any workload.
With so many options available, finding the right machine type for your workload can be confusing – which is why we’ve created this overview of Azure VM types (as we’ve done with EC2 instance types, and Google Cloud machine types). Note that while AWS EC2 instance types have names associated with their purpose, Azure instance type names are simply in a series from A to N. The chart below and written descriptions are a brief and easy reference, but remember that finding the right machine type for your workload will always depend on your needs.
General purpose VMs have a balanced CPU and memory, making them a great option for testing and development, smaller to medium databases, and web servers with low to medium traffic:
The newest size recommendation in the DC-series, the DCsv2, stands out because of the data protection and code confidentiality it provides while it’s being processed in the cloud. SGX technology and the latest generation of Intel XEON E-2288G Processor back these machines – these VMs can go up to 5.0GHz.
A-series VMs have a CPU-to-memory ratio that works best for entry-level workloads, like those for development and testing. Sizing is throttled for consistent processor performance to run the instance. Av2-series has the option to be deployed on a number of hardware types and processors. To figure out which hardware the size should be deployed on, users must query the virtual hardware in the VM.
Dv2 and Dsv2-series
Dv2 VMs boast powerful CPUs – roughly 35% faster than D-series VMs – and optimized memory, great for production workloads. They have the same memory and disk configurations as the D-series, based upon either a 2.1 GHz, 2.3 GHz or 2.4 GHz processor and Intel Boost Technology.
Dsv2-series sizes run on the same Dv2 processors with Intel Turbo Boost Technology 2.0 and also use premium storage.
With expanded memory (from ~3.5 GiB/vCPU to 4 GiB/vCPU) and adjustments for disk and network limits, the Dv3 series Azure VM type offers the most value to general purpose workloads. The sizes in this series offer a combination of memory, temporary storage, and vCPU that best fits best for enterprise applications, relational databases, in-memory caching, and analytics. It’s important to note that the Dv3-series no longer has the high memory VM sizes of the D/Dv2-series.
This series’ sizes feature premium storage disks and run on 2.1, 2.3, or 2.4 GHz Intel Xeon processors with Intel Turbo Boost Technology 2.0, the Dsv3-series is best suited for most production workloads.
Similar to the AWS t-series machine type family, B-series burstable VMs and ideal for workloads that do not rely on full and continuous CPU performance. Use cases for this series’ VM types include small databases, dev and test environments and low-trafficweb servers, microservices and more. Thanks to the B-series, customers can purchase a VM size that builds up credits when underutilizedcompared to its base performance, and the accumulated credits can be used as bursts. Spikes in compute power allow the VM to burst above the base performance if for higher CPU performance when needed.
Dav4 and Dasv4-series
Dav4-series are one of the new sizes that utilize a 2.35Ghz AMD EPYCTM 7452 processor and can reach a max frequency of 3.35GHz. The combination of memory, temporary storage and vCPU makes these VMs suitable for most production workloads. For premium SSD, Dasv4-series sizes are the best option.
Ddv4 and Ddsv4-series
Similar to other VMs in the D-series, these sizes utilize a combination of memory, temporary disk storage and vCPU that provides a better value for most general-purpose workloads. These new VM sizes have faster and 50% larger local storage (up to 2,400 GiB) and are designed for applications that benefit from low latency, high-speed local storage. The Ddv4-series processors run in a hyper-threaded configuration making them a great option for enterprise-grade applications, relational databases, in-memory caching, and analytics.
The major difference between the two series is that the Ddsv4-series supports Premium Storage and premium Storage caching, while Ddv4-series does not.
Dv4 and Dsv4-series
Both of these new series are currently in preview. The Dv4-series is optimal for general purpose workloads since they run on processors in a hyper-threaded configuration. It features a sustained all core Turbo clock speed of 3.4 GHz.
The Dsv4-series runs on the same processors as the Dv4-series, and even has the same features. The major difference between the two series is that the Dsv4-series supports Premium Storage and premium Storage caching, while Dv4-series does not.
Compute optimized Azure VM types offer a high CPU-to-memory ratio. They’re suitable for medium traffic web servers, network appliances, batch processing, and application servers.
With a base core frequency of 3.4 GHz and a maximum single-core turbo frequency of 3.7 GHz, Fsv2 series VM types offer up to twice the performance boost for vector processing workloads. Not only do they offer great speed for any workload, the Fsv2 also offers the best value for its price based on the ratio of Azure Compute Unit (ACU) per vCPU.
Memory optimized VM types are higher in memory as opposed to CPU, and best suited for relational database services, analytics, and larger caches.
Enterprise applications and large databases will benefit most from the M-series for having the most memory (up to 3.8 TiB) and the highest vCPU count (up to 128) of any VM in the cloud.
The VMs in this series offer the highest vCPU count (up to 416 vCPUs) and largest memory (up to 11.4 TiB) of any VM. Because of these features, It’s ideal for extremely large databases or applications that benefit from high vCPU counts and large amounts of memory. The Mv2-series runs on an Intel® Xeon® processor with an all core base frequency of 2.5 GHz and a max turbo frequency of 3.8 GHz.
Dv2 and DSv2-series 11-15
The Dv2 and DSv2-series 11-15 follow in the footsteps of the original D-series, the main differentiation is a more powerful CPU. For applications that require fast vCPUs, reliable temporary storage, and demand more memory, the Dv2 and DSv2-series all fit the bill for enterprise applications. The Dv2 series offers speed and power with a CPU about 35% faster than that of the D-series. Based on the 2.1, 2.3 and 2.4 GHz Intel Xeon® processors and with Intel Turbo Boost Technology 2.0, they can reach up to 3.1 GHz. The Dv2-series also has the same memory and disk configurations as the D-series.
Ev3-series and Esv3-series
The Ev3 follows in the footsteps of the high memory VM sizes originating from the D/Dv2 families. This Azure VM types provides excellent value for general purpose workloads, boasting expanded memory (from 7 GiB/vCPU to 8 GiB/vCPU) with adjustments to disk and network limits per core basis in alignment with the move to hyperthreading.
The Esv3-series is the optimal choice for memory-intensive enterprise applications. If you want premium storage disks, the Esv3-series sizes are the perfect ones. A difference between the two series is that the Esv3-series supports Premium Storage and premium Storage caching, while Ev3-series does not.
Eav4 and Easv4-series
The Eav4 and Easv4-series utilize the processors they run on in a multi-threaded configuration increasing options for running memory optimized workloads. Though the Eav4-series and Easv4-series have the same memory and disk configurations as the Ev3 & Esv3-series, the Eav4-series sizes are ideal for memory-intensive enterprise applications.
Use the Easv4-series sizes for premium SSD. The Easv4-series sizes are ideal for memory-intensive enterprise applications. Easv4-series sizes can achieve a boosted maximum frequency of 3.35GHz.
Edv4 and Edsv4-series
High vCPU counts and large amounts of memory make Edv4 and Edsv4-series the ideal option for extremely large databases and other applications that benefit from these features. It features a sustained all core Turbo clock speed of 3.4 GHz and many new technology features. Unlike the Ev3/Esv3 sizes with Gen2 VMs, these new VM sizes will have 50% larger local storage, as well as better local disk IOPS for both read and write.
The Edv4 and Edsv4 virtual machine sizes feature up to 504 GiB of RAM, in addition to fast and large local SSD storage (up to 2,400 GiB). These virtual machines are ideal for memory-intensive enterprise applications and applications that benefit from low latency, high-speed local storage. You can attach Standard SSDs and Standard HDDs disk storage to the Edv4 VMs.
Ev4 and Esv4-series
These new sizes are currently under Public Preview Only – you can signup to access them here.
The Ev4 and Esv4-series are ideal for various memory-intensive enterprise applications. They run in a hyper-threaded configuration on 2nd Generation Intel® Xeon® processors and feature up to 504 GiB of RAM.
For big data, data warehousing, large transactional databases, SQL, and NoSQL databases, storage optimized VMs are the best type for their high disk throughput and IO.
Lsv2-series VMs provide high throughput, low latency, directly mapped local NVMe making it these VMs ideal for NoSQL stores such as Apache Cassandra and MongoDB. The Lsv2-series comes in sizes 8 to 80 vCPU and each vCPU has 8 GiB of memory. VMs in this series are optimized and use the local disk on the node that is attached directly to the VM.
GPU VM types, specialized with single or multiple NVIDIA GPUs, work best for video editing and heavy graphics rendering – as in compute-intensive, graphics-intensive, and visualization workloads.
NC, NCv2 and NCv3-series
The sizes in these series are optimized for compute-intensive and network-intensive applications and algorithms. The NCv2-series is powered by NVIDIA Tesla P100 GPUs and provides more than double the computational performance of the NC-series. The NCv3-series is powered by NVIDIA Tesla V100 GPUs and can provide 1.5x the computational performance of the NCv2-series.
NV and NVv3-series
These sizes were made and optimized for remote visualization, streaming, gaming, encoding, and VDI scenarios. These VMs are targeted for GPU accelerated graphics applications and virtual desktops where customers want to visualize their data, simulate results to view, work on CAD, or render and stream content.
ND and NDv2-series
These series are focused on training and inference scenarios for deep learning. The ND-series VMs are a new addition to the GPU family and offer excellent performance for training and inference making them ideal for Deep Learning workloads and AI. The ND-series is also enabled to fit much larger neural net models thanks to the much larger GPU memory size (24 GB).
The NDv2-series is another new addition to the GPU family and with its excellent performance, it meets the needs of the most demanding machine learning, GPU-accelerated AI, HPC workloads and simulation.
The NVv4-series VMs are optimized and designed for remote visualization and VDI. With partitioned GPUs, NVv4 offers the right size for workloads requiring smaller GPU resources. With separated GPUs, this series offers the perfect size VMs for workloads that require smaller GPU resources.
High Performance Compute
For the fastest and most powerful virtual machines, high performance compute is the best choice with optional high-throughput network interfaces (RDMA).
The H-series VMs were built for handling batch workloads, analytics, molecular modeling, and fluid dynamics. These 8 or 16 vCPU VMs are built on the Intel Haswell E5-2667 v3 processor technology and up to 14 GB of RAM per CPU core, and no hyperthreading.
Besides sizable CPU power, the H-series provides options for low latency RDMA networking with FDR InfiniBand and different memory configurations for supporting memory intensive compute requirements.
Applications driven by memory bandwidth, such as explicit finite element analysis, fluid dynamics, and weather modeling are the best fit for HB-series VMs. These VMs feature 4 GB of RAM per CPU core and no simultaneous multithreading.
For applications driven by dense computation, like implicit finite element analysis, molecular dynamics, and computational chemistry HC-series VMs are the best fit. HC VMs feature 8 GB of RAM per CPU core, and no hyperthreading.
Similar to other VMs in the High Performance compute family, HBv2-series VMs are optimized for applications driven by memory bandwidth, such as fluid dynamics, finite element analysis, and reservoir simulation. HBv2 VMs feature 4 GB of RAM per CPU core, and no simultaneous multithreading. These VMs enhance application performance, scalability, and consistency.
What Azure VM type is right for your workload?
The good news is that with this many options VM types, you’re bound to find the right type to meet your computing needs – as long as you know what those needs are. With good insight into your workload, usage trends, and business needs, you’ll be able to find the Azure VM type that’s right for your workloads.