Introduction:
Many learning programs and tutorials on the topic of
solution implementations using the Azure Public cloud include pertinent
questions using case studies. While they are dressed up in different criteria,
most of them probe for some of the fundamentals in design and architecture with
the typical use and nuance of the cloud services. These services all conform
for use with the Azure resource manager, provide high availability and
performance guarantees and come with significant cost savings and management
features. With well over a hundred services in its portfolio, the Azure public
cloud poses several choices for solution architects, and they must know their
tools to sharpen their blades. There doesn’t seem to be a questionnaire bank
that can collect all the knowledge base questions about their use that these
experts can go through in one session. On the other hand, the tenets underlying
those questionnaires are easy to relate and remember. This article continues to
serve that purpose along with some of
the earlier that were written and include in the reference.
While there is no particular place to start, the cloud won’t
be significant without compute and the most important aspect of compute are
virtual machines. There is tremendous documentation on the virtual machines and
scale sets. Their definitions are maintained as VHD and VHDX formats, but the
difference is that the latter is supported exclusively by windows and includes
up to 64 TB of storage capacity. It also supports live resizing with logical
sector size of 4KB with better data alignment. Hyper-V supports both formats
and the administrator mode is required for both the Hyper-V manager and the
Powershell scripts. One can be converted to another format and they can be
merged as well. They can be mounted and dismounted independently.
The Azure site recovery can be used to replicate sql server
to Azure. Although there are many cases and choices for hosting a relational
data store, the most convenient way with full parity is when we host the server
on a VM. The managed database instance deployed to the cloud does not give the
same amount of control as the one hosted on VM but eventually managed database serve
better in the long run and do away with the maintenance and performance tuning
that accrues otherwise. It is also unimaginable to host an Master data
management catalog on a single Virtual Machine at this time. If a
database has become slow on a target instance of the SQL Server, leverage the
auto-tuning feature to improve performance. A single
Azure SQL instance can host many databases,
and many write regions. There is no need to provision a dedicated instance for
every region or application. This strategy is different from that of keyvault
which can even be provisioned as many as those that use them.
Data, data store and analytics have huge surface area to
cover but one of the most useful source of operational data for any deployment
is the logs pertaining to the services. These don’t need to be setup per
instance but the solutions that are built over the services must have an
account for its storage. There is only one storage account that can be bound to
the log analytics workspace. Logs from many
places can flow to the account but there must only be one account. Use
AzCopy with cron jobs for high-rate data transfer that are typical for logs.
This will cut costs when compared to Azure Data Factory and Azure Data Lake
resources. Create diagnostic settings to
send platform logs and metrics to different destinations. A single diagnostic
setting can define no more than one of each destination. A resource can have up
to 5 destination settings. If metrics
must flow into logs, leverage the Azure monitor metrics REST API and import
them into the Azure Monitor logs using the Azure monitor Data Collector API.
There is difference between fad and fact even on services
that are dedicated for a specific purpose. Serverless computing for example is
great when the logic is small, isolated and needs to scale but the choices are
not that clear when they can proliferate in an uncontrolled manner. A service is ideal for incubation of features
because the additions are not only incremental, they usually conform to top
down planning and not pander to bottom up convenience. Then there is the cost
of ownership for serverless computing that does not factor into the cost
advisor because they are usually on the user side. Cost of maintaining logic
hosted on serverless computing is significantly more than that of well designed
services with modular components that also have the convenience of being hosted
in the cloud.
Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhKYBNRZosAThWjmojg?e=d52IAU
No comments:
Post a Comment