Azure
What is Azure
Cloud:-
Microsoft has
been building highly scalable applications in datacenters around the
world—applications that have global reach and high availability, and offer
great functionality to users. Azure allows you to take advantage of the same
infrastructure to deploy your own applications, with the corresponding
capabilities to reduce your maintenance requirements, maximize performance and
minimize costs.
Though we know
that cloud adds lot of value but that only happens when it is done right and
hence we need have thought of below
before taking a call:-
1. Always
plan for the long-term.
It’s easy to be tempted by solutions that promise immediate benefit and what
looks like the quickest route to the cloud. While the PaaS (platform as a
service) approach may appear more complex, the long-term benefits such as
built-in elasticity, service healing, patch management, and so forth, make it a
worthwhile investment that will pay dividends both on the technology and
business sides of the house.
2. Its okay
to start with something simple.
Many companies use smaller applications with fewer dependencies as a way kick
start their Windows Azure journey. Rather than taking a “fork lift” approach
and moving everything all at once you can think of hybrid scenarios where you
tactically move individual pieces to the cloud – one at a time, but as part of
a larger, interconnected architecture.
3. Know the
outcomes you want to achieve.
It could be cost savings or time to market; regardless, know what you want to
achieve and design the solution accordingly.
With these “tips”
in mind, I put together a series of questions for customers to keep in mind as
they consider moving different workloads to Windows Azure. This is by no means
exhaustive, but it helps set the context of how and what people should think
about.
Are you
building a new application or are you able to adapt an existing application to
operate in the cloud?
You can certainly
move existing applications into Windows Azure, but oftentimes you’ll have to
make changes so that you can benefit from the elasticity of the platform.
Consequently it is sometimes easier to target new applications when first
moving to Windows Azure.
Do you have
large amounts of data that you either have to store or process in your
solution? Do you worry about running out of storage capacity on any apps with
more users coming on board?
The low cost and
durability of storage in the cloud make it extremely practical to start
collecting and storing data that you otherwise would have thrown away. This
opens up all kinds of opportunities to start mining your data for patterns and
insights that you otherwise would have missed.
Do you have
a predictable pattern of usage with your applications? Alternatively, do you
have spikey and unpredictable usage patterns?
The ability to
scale horizontally means you only need to allocate enough compute to satisfy
the immediate needs of the application. When you need more servers, spin
up more servers. When you’re doing with them, shut them down.
Is having a
global presence for your application important?
Windows Azure has
eight data centers worldwide – and a lot more content delivery networks for
caching your static data – which makes it easy to target a worldwide audience.
Additionally, there’s a service called Traffic Manager that lets you define a
policy for routing your users to the closest datacenter to reduce latency.
Do you have
solutions that require access to services that exist inside secure networks?
There are many
ways to securely connect back into your on-premises assets – this can be
especially important if you’re in a regulated industry or have information that
you cannot move into the cloud. You can target specific services by using the
Service Bus to relay messages through your firewall, benefiting from a
service-oriented approach on-premises. Furthermore, you can also segregate your
systems by using queuing technologies – e.g. drop a message into queue in the
cloud and pick it up from a local machine
Migration
consideration and methodology
Several
things should be considered while moving an application to Windows Azure. Major
points that need to be addressed are:
Application compatibility
– analyze if the application is architecturally fit for Windows Azure before
moving.
·
External / internal dependencies – check if
there are any external application dependencies and need to analyze and if
those are accessible through Azure.
·
Application
class – verify how the application is classified in the business. Business
critical and LOB applications demand high availability.
·
Application
integration – check whether candidate application is integrated with other on
premise applications and shared services.
Database compatibility
– analyze whether the existing database is best fit to migrate to Azure.
·
Application
maintenance / management – identify how the logs are maintained and where they
are stored.
·
Scalability
/ elasticity – identify whether the application design supports scalability as
Azure supports it.
·
Compliance
requirements – check if there are enterprise compliance and regulations that
govern whether the data can be moved / stored outside the enterprise’s control.
·
Cost
- verify whether the moving application is cost effective for the enterprise.
·
Security
– clarify whether the same level of security can be provided after migrating to
Windows Azure in terms of:
1) Data security
2) Authentication
3) Authorizations
Migration
strategy / approach
Before we jump
into UI analysis let’s see 2 main ways of deploying your application on Azure.
Platform as a
Service - Azure Cloud Services
An Azure
Cloud Service consists of two components: your application files (source code,
DLLs, etc.) and a configuration file. Together, these two elements will spin up
a combination of Web Roles and Worker Roles to
execute your application. With Cloud Services, Azure handles all of the tedious
Operating System details for you, so you can focus on what matters - building a
quality application for your users.
A Web Role is an Azure VM that is
pre-configured as a web server (running IIS) and will automatically have your
application loaded on it by the time the server fully spins up. This will
create the public endpoint for your application - usually a website, but it
could also be an API or something similar.
Worker Roles run
alongside your Web Roles and are responsible for performing computing functions
to support your application. Typically, the Web Role will accept some sort of
user input and queue up an action for the Worker Role to process at a later
time. This allows the Web Roles to be more responsive and to fire-and-forget tasks
to be processed later.
You can pre-configure the number of Web and Worker Roles you
want to start your application with and Autoscale to add or remove
additional resources depending on demand.
Infrastructure as a Service - Azure Virtual Machines
IaaS gives you a server in the
cloud (virtual
machine) that you have complete control over. With an Azure VM, you are
responsible for managing everything from the Operating System on up to the
application you are running.
This mode of
operation will feel most like a typical on premises virtual machine where you
remote desktop into the server to manage it instead of sitting down in front of
a physical keyboard and mouse.
If you need a
solution that requires custom third party software or multiple applications
running on a single machine, then IaaS might be for you.
a. UI
analysis
Analyze if UI
interface can be migrated to Azure directly in the PaaS model, web applications
and web services in non-cloud solutions can be mapped to Windows Azure web
roles, while the non-web applications are kept on premise. Re-engineering work
is required to modify the existing web application code to use the Windows
Azure SDK. This is to ensure it runs on Windows Azure as hosted Cloud services.
In addition, if any third party framework / class library that is not supported
by Azure is used, the library may need some modifications or, will have to be re-written.
In case of the
IaaS model, no code changes are required. Instead, the entire server image will
be migrated to the Windows Azure virtual machine.
The sections
below focus on the PaaS approach as no major changes are required in the IaaS
one.
·
Database
compatibility – analyze whether the existing database is best fit to migrate to
Azure.
·
Application
maintenance / management – identify how the logs are maintained and where they
are stored.
·
Scalability
/ elasticity – identify whether the application design supports scalability as
Azure supports it.
·
Compliance
requirements – check if there are enterprise compliance and regulations that
govern whether the data can be moved / stored outside the enterprise’s control.
·
Cost
- verify whether the moving application is cost effective for the enterprise.
·
Security
– clarify whether the same level of security can be provided after migrating to
Windows Azure in terms of:
1. Data security
2. Authentication
3. Authorizations
b.
Transactions / session handling
Session state management:
In Azure, each
web role instance runs on its own VM server and are configured behind a load
balancer. The ASP.Net session state is not automatically shared across instance
in this load balanced environment.
Various
approaches to address this are as follows:
1. Session state
management using Inproc:
Inproc session state may be the best
performing option and is the default state management, unless overridden. In
load balanced environments such as Windows Azure, this will only function for
single instance setup. If more than one instance is used, it might result in
inconsistency.
2. Table storage
session provider:
It is a subset of
the Windows Azure ASP.NET providers specifically designed and written for use
in Windows Azure. The table storage session provider is a custom provider that
is compiled into a class library (.dll file), enabling developers to store
session state inside Windows Azure table storage. Thus Analyze
·
Is
it benefitial?
·
What
can be done?
·
Business
analysis
·
Impact
analysis
Strategize
·
Identifying
alternate approaches
How to implement
·
Planning
·
POCs
Implement
·
Migrate
·
Validate
3. Windows Azure
SQL database session provider:
Windows Azure SQL
database is essentially a subset of SQL server. It can also be used as storage
for session state. With just a few modifications, it can be derived from SQL
server session provider. When used with the existing database, it is cost
effective.
4. Windows Azure
cache:
4.1) In-role
cache allows caching. It uses a portion of its memory for the web or worker
role instances that host an application, or with a dedicated one deployed to Windows
Azure Cloud services. One does not have to pay any premium for cache.
4.2) Azure cache
preview gives access to a secure, dedicated cache that is managed by Microsoft.
A cache created using the service is accessible from applications within
Windows Azure, running on Azure Web sites, web and worker roles and virtual
machines.
c. Business
layer analysis
Windows Azure
caching remains the recommended option, despite the debates. Developers and
architects could always consider a different option, if it suits a given
scenario.
a. Authentication and authorization model
Analyze and understand the current authentication mechanism in the application.
1. Check if the
same authentication approach in the cloud application can be adopted (for
instance, using forms- based authentication).
2. Explore cloud
based solutions for authentication. Utilize Windows Azure Active Directory
Access Control (also known as Access Control Service or
ACS) to authenticate users from identity
providers, when they try to gain access to a web application. These include
Microsoft, Google, Yahoo and Facebook.
Deploy Azure virtual private network to
communicate with enterprise active directory. Use Windows Azure Active
Directory with integrated on-premise organization active directory.
b. Interaction with other modules /
applications
Web services:
They can be converted to Azure WCF services,
hosted either as a web role or worker role.
They can be left as on-premise services and
can be exposed through Azure service bus or Azure VPN.
Windows Services:
They can be hosted as worker roles.
Native code:
A managed wrapper can be created and deployed
as part of an Azure package. It can be consumed from any Azure hosted service.
Third party / non-Microsoft dependency:
Need to confirm if they can be consumed
directly from Azure application.
c. Diagnostics support
Windows
Azure diagnostics provides non-intrusive capture of diagnostic data and its
sub-sequent data to the Windows Azure storage service.
With
WA diagnostics, one can:
Implement custom logging and save the log
information to Windows Azure storage tables.
Push event logs to diagnostics store.
Push failed request logs to diagnostic store.
Push performance counter data to diagnostics
store.
d. Message queues
Currently,
MSMQ is not supported in Windows Azure.
Azure
storage queue and service bus queue features can be used to implement queues in
Azure.
Azure
service bus topics / subscriptions can be used for message publish and
subscribe model.
e. Configuration changes
If the application accesses any information
from physical storage, it needs to be migrated to Azure storage / CDN / Windows
Azure SQL database.
Check for any hard coded physical disk paths
in the applications. Azure applications should not have any hardcoded physical
disk or network access values.
Ex: Application saves any information to local
system / access information.
Check for any third-party library or content
references.
They need to be included as part of the Azure
package.
Provide session and identify provider (ADFS /
ACS information) in the web configuration file.
f. Miscellaneous
Replace static values and application states
to handle scalability applications in Azure.
d. Database
analysis
Three
ways to maintain application data while migrating an application to Windows
Azure:
1.
Reside on premise
2.
Create SQL server in Azure VM
3.
Windows Azure SQL Database (PaaS)
The
section below describes the approaches and recommendations:
a. Analyze the DAL layer and see if any
framework / class library is being used. Determine whether it is supported with
Windows Azure SQL database.
Frameworks such as Entity Framework (EF) are
supported with Windows Azure SQL Database. In case any third party class
library / framework that is not compatible with Windows Azure SQL Database is
used, the DAL layer code needs to be re-written. This is to achieve
compatibility with the database.
Windows Azure SQL Database supports only SQL
authentication. One should consider whether the changes are needed to the
authentication scheme in the application.
b. Determine whether all the data required by
the application is in a single database or if it is dependent on:
If the application database uses linked server
concept to interact with another database, it cannot be moved to Windows Azure
SQL Database. This is because it does not support the linked server feature.
The above problem can be solved by using
Windows Azure Virtual Network feature. This is where the on premise application
database is exposed to Azure cloud applications.
c. Determine the modifications required to be
done in the database schema for migration to Windows AzureSQL Database.
Run SQL Migration Wizard to have a complete
list of all the modifications required for Azure porting.
Windows Azure SQL Database demands some
constraints on the database schema to be deployed, such as the primary key
constraint on all the tables.
One should make necessary modifications on the
database schema to be ported to Windows Azure SQL Database.
Data
migration strategy
Application
migration strategy should also include data migration strategy as most of the
applications are typically data centric.
Hence, while
migrating application from on premise to Cloud, we need to ensure that the
users do not see any discrepancy in their data. Application can store data onto
disk, into a database, network stores and more.
Cloud
provides the flexibility to persist data in the same way they are stored in the
on premise application.
Azure
hosted applications data can be saved in the following ways.
a.
Data from Database to Windows Azure SQL Database /Windows Azure storage
c.
Message queues to Windows Azure queue storage /service bus queue.
Migrating
Enterprise Architecture to Cloud:-
What is
Enterprise Architecture:-
Unlike standalone
application architecture, enterprise architecture involves architecting various
applications (internal/external) involved in fully functional business.
Let’s consider
travel domain where there are following applications:-
1) Master Data Entry:-
This is windows application written in
VB 6.0 or .NET (VB/C#). This uses on premise SQL database GoRoamingDB.
2) Online Booking:-
This is web application exposed on
public IP to general consumers. This uses on premise SQL database GoRoamingDB.
3) Reporting Services:-
SSRS reports using on premise SQL database
GoRoamingDB.
Enterprise
architecture is responsible for communication between different
applications/components involved to keep business functional and keep the
architecture ready for scalability/portability.
So when we want
to move any application to cloud its related components will also need
modification. In case of standalone application PaaS becomes an obvious choice
and application can be moved to cloud very quickly without much of issue.
Whereas when we
have dependent applications/ components we need to make conscious choice of how
we go into cloud.
Now let’s see
what all can be migrated and how:-
Master Data Entry
(When to be moved and how):-
This is a windows application and should remain on premise
unless there is one of the following reasons:-
Case 1 – Productivity and high sensitive data
loss
I have observed a very common scenario in my country India where
data entry work is outsourced from various global companies. Let’s say a data
entry company in India is having a couple of hundred workers performing data
entry, related to health care claims information. These workers are allocated a
desktop machine which has an application developed using C# or WPF. Now imagine
if the hardware crashes for a desktop machine, then that unfortunate employee
has to go to Support IT team of his/her organization and report the problem. The
IT team will then need to provide a new desktop machine. They will need to
configure the pre-requisites on the new desktop, then install the actual
application. In big companies, this can take a couple of days, after which that
employee can start his/her work. Additionally if there is any sensitive data on
the failed machine, then it needs to be restored. This problem arose at the
first place because a local desktop machine was being used for performing some
sensitive work. In this scenario, Productivity is affected and Loss of
sensitive data is high.
Case 2 – Device Portability
Today, the world is experiencing an explosion of devices. People
want an application that can work on Laptop, should be able to work on their
tablet, smartphone, mobile, desktop and so on. Additionally if an application
can run on any device, users of the application don’t necessarily have to be
part of their corporate network and don’t have to be present in their company
premises. Rather they should be able to work remotely. However if an
application is a legacy app, then it may not work on the latest hardware/
software. Here device portability of desktop application and mobility
is another challenge corporates face.
Case 3 – Moving from Capex to Opex
Usually large organization take the help from vendors to perform
many activities. Sometimes these corporates hire people on contract for a short
duration to get their work done. In such cases, companies are not willing to
spend on hardware cost as this might be a temporary affair for them. In other
words, they don’t want to spend money on Capex (Capital Expenditure) but they
want to move to Opex (that is operational cost), so that they use the resources
when in need and free them when not required. In traditional model of desktop
application environments, this flexibility is quite challenging. So moving
from Capex to Opex which is recommended in today’s IT world is another
important challenge corporates face.
High Level
Solution
To overcome these challenges faced in corporate and domestic scenarios,
companies like Microsoft offering cloud computing for Enterprise Web
Applications came up with the concept of Desktop
as a Service (DaaS) commonly known as Desktop Virtualization.
So as a part of this concept, there is a desktop application
installed on user’s machine/ device. The user logs in to that desktop
application from his machine / device. After successful login, all the modern
software & services would be available for consumption. Although the
services/ application run on remote machine (cloud environment), they will
appear to the user as if they are running locally. Once done, the user closes
the application and he would be charged only for what he has consumed.
This approach helps in –
1. Getting rid of hardware and software upgrades
2. Any modern device compatibility can be achieved easily
3. Applications scale without large capital expense
4. Provide access to corporate applications from anywhere
5. User specific shared storage helps in avoiding data loss
Looking at these benefits, it is quite clear running desktop
applications in Cloud environment is a much better option.
Azure Remote Apps is an
offering from Microsoft Azure that makes it easy to run desktop applications on
the reliable platform of Azure.
Hybrid Solution:-
Now let’s say we want to keep the application/database on
premise and move the other part of it, in this case we can opt for Hybrid
Connection provided by Azure.
Online
Booking (When to be moved and how):-
Online Booking is
a web application which you can easily move to IaaS or PaaS depending on the
application complexity and other factors.
But before
anything else it is of utmost importance to go through below:-
1) If you already have existing Infra, Is new
cloud investment have business return in long run?
2) Estimate time and money required to do the
change.
3) How do you align yourself for Disaster
recovery/Security for on premise components?
SSRS Reports (When to be moved and how):-
Reporting service
here is again pointing to the common database (GoRoamingDB), now depending on
where you have hosted the consuming application you may need hybrid connection
discussed earlier.
Database
(When to be moved and how):-
Depending upon
security policy and other business decisions you may end up using on premise
database or would host your database on cloud.
You can use MS
SQL, MySQL , Azure SQL and etc. database
can be converted to target type by readily available tools which have been
tested and improved in course of time.
***Note:-
1) Do your analysis in advance else you may
suffer at the end.
2) Any cloud platform is no must it is only to be
used if need be.
3) Poorly designed cloud application will result
in deteriorated performance.
4) Opt for readily available tools , don’t re-invent
the wheel.
Comments
Post a Comment