Hello, my name is Yatin Aras
and I lead Avanade's Azure Platform Services Offering
in North America.
For Microsoft's Azure IaaS Day digital event,
Avanade has developed a white paper titled,
Mission Critical Applications on Azure IaaS.
This white paper provides valuable insights from our field.
So do take a look if you're currently running
or will be running Mission Critical Applications in Azure.
In this session, we'll analyze why many organizations
fail to realize the anticipated value
from the Azure journey.
Industry Thought leaders and Cloud strategist
often recommend moving quickly beyond IaaS focused solutions
and into the consumption of PaaS or SaaS offerings
where the value proposition of Cloud can be fully realized.
While this advice holds some truth,
it is also true that IaaS represents a significant
and legitimate answer for many.
Most organizations begin their journey to Azure
with the intent of achieving tangible value from the Cloud.
We do ask the right questions.
At the start of every journey we identify
immediate and long-term organization benefits and costs.
Our value case might look something like this
in the chart on the slide.
We count on Azure providing us improved reliability,
scale on demand, optimized cost and other such values.
However, most organizations fail to realize
the anticipated value from their cloud journey.
If there's one misstep and the reason why this happens
is that organizations introduce cloud as another data center
and just extend the existing design patterns and models.
If the goal of moving to Azure
was to increase speed and agility,
What prevents us from achieving that goal?
It is probably our slow and restrictive
provisioning processes.
Azure may remove the long lead-time
for hardware procurement
but if a process for provisioning services
and Azure continue to follow
existing manual resource requests,
gated approvals, architecture review boards
and practices designed around hardware assets
instead of consumption services,
the agility possible from the public cloud
cannot be attained.
Now that the goal was to lower costs,
what prevents us from achieving that goal?
If Azure is viewed as just another data center
and the existing processes tools and teams
are simply extended to support it,
the cost of public cloud is almost higher on premises.
If that is the case,
Why is public cloud considered
a valid option for reducing overall costs?
Azure does offer the ability to dramatically lower costs
but the value proposition is predicated
on two main principles that likely don't exist
in the current data center model.
The first is aligning with the consumption model.
Effective on-premises data center operations,
take a capacity management focus with existing processes
and tools supporting that approach.
One of the primary challenges with this approach however,
is that once capacity has been allocated,
it is difficult to reclaim.
In addition, when capacity management processes
are cumbersome and take time,
customers are incented to oversize the resource request
to avoid having to make additional requests later.
As a result, traditional data center is littered
with systems which have minimal utilization
and significant excess capacity.
Capacity in Azure is available on demand
and in most cases instantly
which means continuing with our old model of provisioning
prevents organization from taking advantage,
potential savings from the cloud.
Instead, the focus must shift from capacity management
to efficient consumption of resources in Azure.
The second principle is automation.
Hyper-scale platforms in Azure are designed to support
the complexity of delivering resilient high-performance
self service resources on top of massive arrays
of commodity hardware, all with no manual intervention.
Organizations must adopt a public cloud provider like model
and place increase priority
on removing barriers via automation.
Legitimate concerns will surface.
With self service, how do we ensure users
aren't consuming resources that are too expensive?
How do we prevent users from deploying configurations
that don't align to our security standards?
How can we be sure that resources being deployed
are services we can support?
These are valid questions and can be daunting
for any organization.
But if an organization is to realize the value
of public cloud, they must take a page
from the hyper-scale cloud provider playbook
and embrace automation at every layer.
Let's look at four anti-patterns that address this.
The first two cover capacity versus consumption
and the next two cover designing for Azure
and hyper automation.
As we discussed previously architecture limitations within
a data center coupled with IT apprehensions
typically fuels over-provisioning.
The consumption based model and in Azure
and it's capability to scale up rapidly
provides an opportunity for organization right-size
without increasing risk.
So when we migrate IaaS workloads to Azure,
let's consider right-sizing.
Most migration assessment tools
can assess utilization on a current environment
and provide recommendations on the best fit in Azure.
If our current application uses a certain number of cores
with a certain level of utilization,
the tools will recommend cost effective VM sizing in Azure
that should meet the performance we need.
But note, the number of course does not show
how fast the server is.
Applications could be running on older machines
with slower CPUs than what we typically find in Azure.
So simple CPU to CPU account conversion
may not give us the right-size design.
We may need to dig deeper.
There are also a storage and network throughput CAPS
set on Azure VMs SQL.
In general, the higher the size, the better the throughput.
If our application requires high-performing disks
or high network throughput, we will need higher size VMs.
Even if the application does not need the CPU or RAM.
As we can see recommendations
from migration assessment tools get us started
but we need to take it to the next level.
We need to truly understand our application requirements
for performance and provision appropriately.
In a data center shared SAN and NAS infrastructure
are already paid for.
So providing applications
more than what is required is common.
On one engagement, we asked an application team
for performance requirements.
They provided us historical metrics that showed applications
requiring very high IOPS and high-end disks.
How did they get that number?
Well, they did a Disk benchmark on the current system
and that's the throughput they got.
That is what they provided an application,
but not necessarily what that application needed.
We should design based on what the application really needs.
An important step is to create a performance baseline.
The next would be to test the application in Azure
to validate that the plan size and capacity
meets or exceeds this performance baseline.
In our experience right-sizing saves about 30%
over migrating like-to-like.
So it's definitely worth the effort.
Moreover, right-sizing for efficient consumption
should not be a one-off event but a continuous practice.
Start by implementing FinOps.
A practice as important the Cloud as DevOps and SRE.
Make consumption management part of the culture.
Understand workloads, right-size, dual-over.
This process should never end.
These practices should include the management of Zombies,
Orphans, and Childless resources.
For example, a VM in Azure is not a single object.
Yes, there is the VM object but in addition
there are also NIC, a Hotdesk, Public IP and SGS.
These are all separate objects and each one
is a separate line item in our Azure invoice.
It is very important to note that these objects
do not get deleted when a VM is deleted.
So we need an automated process that provisions
and de-provisions correctly.
However, we also need a FinOps process
to detect and clean unused resources
or the financial impact is obvious.
This was just one example
but there are other resources that need to be monitored.
SQL Servers that have no databases, for instance.
While we look at ways to optimize consumption,
why not make our lower environments cheaper to operate?
When we first migrated to Azure, we may have right-size VMs
but still brought over all our production
and non-production environments to Azure.
We must ask, do we really need that QA environment up,
7 by 24 by 365.
Can we shut it down when it's not in use?
With automation, we can certainly have
non-production environments built on demand
or at least started or stopped on demand.
We can use burstable VMs SKUs
where performance is not critical
to reduce the overall cost of these lower environments.
Moreover, consider using Azure Dev Test subscriptions
to get discounted rates for non-production workloads.
While we are at it, let's also make our
DR environments cheaper to operate.
In our Data Center
whether we use warm or cold standby DR Model,
investment and physical hardware
in the passive secondary side is relatively similar.
In Azure services such as Azure Site Recovery
can provide much better RTOs and RPOs
compared to on-premise warm standby solutions
with no upfront investment
and very low consumption costs.
So let's understand the RTO and RPO requirements
for every application and determine
the right size Azure DR environment for each one.
To further reduce consumption costs,
let's take advantage of reserved instances
and Hybrid Use Benefits, where possible.
We have seen many organizations due to Azure,
start with a very on-premises mindset when designing
their foundations and landing zones in Azure.
Instead, we must take advantage of the strengths
of the Azure Fabric and understand the immense possibilities
that are not available to us in our own data centers.
As outlined earlier, a significant factor
in the realization of cost savings
from the cloud is tied to the operating model
and how cloud resources are viewed.
But equally important is how the foundation
and landing zones are designed
which is necessary for applications to function
with adequate security, reliability,
manageability and performance.
The Avanade white paper I mentioned
covers these topics in more details.
However, there are some factors to consider
as we design our application environments for Azure.
Let's start with storage.
Storage in Azure is designed differently
than most traditional on-premises storage area networks
that connect machines to a storage array.
Most of these on-premises storage solutions can provide us
all the IOPS and Throughput we need
which means we just need to plan for storage size.
The way disks work in Azure is different
from the way they work in our data centers.
All storage in Azure is network storage.
So we should understand how Disks perform in Azure
under the covers and what that performance
means to our applications.
For example, a common on-premises design pattern
for storage is RAID 10
which provides striping and mirroring.
In Azure, the underlying Fabric maintains
three copies of configuring mirroring in that scenario
is just a waste of money.
Then there are all the options.
Standard HDD or Premiere SSD, Azure Files, Blobs
or Tables for shared storage and redundancy options.
Locally redundant versus globally redundant storage.
With all these options, choosing the right storage
can be a challenge.
So we must absolutely understand our application needs.
How will the application access storage?
What are the IOPS and throughput requirements
for each tier of our application?
How much latency can be tolerated by each tier
before there will be a performance impact?
What are the available requirements for storage?
How much storage growth is expected for the application?
Similarly, designing Azure networking will require
a paradigm shift, since it is software defined networking
which is at the layer 3 and up.
Achieving connectivity, performance and security in Azure
will require an openness to new approaches.
For example, Azure Virtual WAN makes it easy to use
the Microsoft backbone for any-to-any connectivity
with an Azure and between on-premises data centers.
It is a networking service that brings together
many networking security and routing functionalities
under one operational interface.
Azure also provides network performance improvement options.
If you have extreme performance requirements,
we could use Proximity Placement Groups
or on our VMs, enable accelerated networking
to move much of Azure's networking stack off from the CPU.
In our on-premises data centers,
we use network zones and diligently control access
in and out of those zones.
With Microsoft Zero Touch security model in Azure
we are shifting control to the data and at the device level
enabled by a security policy enforcement engine,
identity and endpoint risk management,
threat intelligence and adaptive access control.
Is there a need for a centralized DMZ
like we have on-premises today?
Do we need to packet everything for data leak protection
and end up Hairpinning all outgoing traffic?
There are other ways to solve the problem,
for instance, Private Links.
So let's be open to the possibilities.
Let's be open to change.
We can use Load Balancers and also cluster
our database servers using Azure Shared Disk
or storage spaces direct.
However, there are more options in Azure
for high availability.
We recommend using fault domains to protect against
unexpected Azure infrastructure outages
and update domains to protect against
an Azure Fabric level update, causing an unexpected issue.
Also consider using Availability Sets and Availability Zones
for additional protection against rack level
and Azure data center level failures.
Do we have IaaS workloads that will benefit
from automatic scalability?
Azure VM scale sets can be used to enable those scenarios,
point being, designed for the cloud.
There are a lot of features available to us
even for IaaS workloads that require
minimal application level changes.
What happens in that data centers
when we need to provision a VM for an application team?
John's team needs to provision the VM
and John, the OS who had Active Directory Domain
then Jason comes and provides additional SAN attached Disk
Mukesh deploys monitoring and security agents
and Dan deploys SQL Server.
Finally, the savvy application team uses the CI/CD pipeline
that takes care of deploying software,
configuration of code and custom code.
Total provisioning time two days in the best case
since Dan did deploy that version of SQL Server,
the first time around.
Two months, if hardware needs to be purchased.
We have all lived through this.
But we shouldn't need to an Azure.
The Azure Fabric is built for hyper automation.
Complete landing zones can be provisioned
with a touch of a button from networking,
compute, storage, everything.
Every resource in Azure,
every action and activity is defined and controlled
through the underlying layer of Azure Resource Manager
or commonly known as ARM.
Implement a good operating model for Azure
with good Infrastructure as Code processes
and tools to support it.
Infrastructure as Code, but the modern Declarative Method
to provision resources and integrate with DevOps
repositories and deployment pipelines
to enable end-to-end automated deployment
across all lifecycle environments.
If done correctly, we will see faster deployments
by reviewing the manual process.
Consistent and repeatable deployment
across all lifecycle environments.
Improved manageability of environments
and improved overall operational efficiency.
As I mentioned earlier,
Avanade has developed a white paper titled,
Mission Critical Application on Azure IaaS.
This white paper provides valuable insight
from the field, so do take a look.
Thank you for joining us at IaaS Days.