This
post discusses moving applications to the public cloud in bulk, where
dozens or hundreds of applications are in view. After reviewing the challenges and
opportunities inherent in bulk migration, an efficient factory-based approach
is outlined. Lastly, Neudesic’s bulk migration service for the Windows Azure
platform is described, Azure Migration
Factory. Here's what we'll cover:
The Nature of Cloud Migrations
Challenges and Opportunities Inherent in Bulk Migrations
A Factory Model Approach to Cloud Migration
Neudesic’s Azure Migration Factory
Summary
A Factory Model Approach to Cloud Migration
Neudesic’s Azure Migration Factory
Summary
NOTE: Everything described here is equally applicable to
both Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) cloud
computing. The term “application” refers to the IT assets that make up a
software solution. When targeting PaaS, “application” means one or more sets of
software code, configuration, and data that work together. When targeting IaaS,
“application” means one or more virtual machines containing software,
configuration, and data that work together. In either case, the “software”
could refer to existing custom-developed code and/or a commercial product.
The Nature of Cloud Migrations
Before we contrast individual migrations with bulk
migrations, let’s briefly review the common ground intrinsic to any production cloud
migration. There are application-level activities to perform as well as
organizational readiness activities.
Application Activities: Assessment, Planning, Technical Work, Support
Whether one is migrating a single application to the cloud
or a dozen, certain things always need to be done. An assessment provides the
business and technical analysis needed to make a sound go/no-go decision on
moving to the cloud. A migration plan identifies the activities and sequence
needed for an orderly and non-disruptive migration. The migration itself is
technical work that entails a variety of IT, development, and QA tasks. The
people, processes, and systems responsible for monitoring and management need
to support the application in its new setting.
Organizational Activities: Strategy, Compliance, Integration, Adaptation
There are also organizational activities that must accompany
cloud migration. These include: defining a cloud strategy and setting policies
and guidelines on appropriate uses; ensuring buy-in across the company from
stakeholder departments who must be satisfied about security, risk management,
compliance, management, and disaster recovery; integration projects to ensure
cloud-hosted assets can interoperate with internal systems; and adaptation of
existing application lifecycle processes (deployment, management) to
accommodate cloud-hosted applications.
Typically these organizational activities are trigged by the
first production migration to the cloud, and refined over time as experience
and comfort level with the cloud increases. In some ways, the first migration
is the most expensive migration.
Challenges & Opportunities Inherent in Bulk Migrations
Bulk migrations bring both challenges and opportunities:
A
bulk migration is a serious commitment. Whereas an individual
application migration might be sponsored by a single department, a bulk
migration implies broad buy-in by departments across the organization on a
cloud strategy and supporting operational changes. A bulk migration isn’t
likely to happen until there is a strong degree of confidence and consensus by
stakeholder departments on cloud vision, platform/provider, and integration
partner. A proof-of-concept often precedes a bulk migration to validate the platform
and partners.
A
bulk migration is challenging to estimate properly. In a
single-application migration the candidate application can be deeply studied.
In a bulk migration you rarely have that luxury and need to make high-level
estimates based more on tribal knowledge about applications and less on direct
examination of code.
A
bulk migration represents a sizeable effort, one that needs to be carefully
managed. Surprises can surface in the midst of any application migration; when
performing a large number of migrations in parallel a mounting number of surprises
could quickly put the budget and timeline at risk if not managed well.
A
bulk migration may encounter product obstacles. Products your software
is dependent on may or may not be compatible with the cloud. Even without
technical hurdles, you may be unable to use some products in the cloud for
licensing and support reasons. In these cases, development work may be needed
to replace some parts of your technology platform with cloud-friendlier equivalents.
This is not always bad news, as it may do away with licensing costs.
A
bulk migration requires organizational cooperation. Even if a migration
is being performed by an integration partner, the customer needs to
participate. The migration teams will need a supply line by which they can
receive, in a timely fashion, application assets (such as source code and
database scripts), answers to technical questions (such as environmental
information), and assistance integrating to internal systems. If the customer
can’t serve in this supporting role and keep pace with the migration teams, the
migration effort will be held back. The organization also needs to provide user
acceptance testing to sign off on migrated applications.
Although a bulk migration does bring its challenges, it also
brings opportunities. There are financial and technical reasons to favor a bulk
migration over a one-app-at-a-time approach.
A
bulk migration can reduce average application migration time by taking
advantage of repeatable tasks, especially when there are multiple applications that
share the same architecture and technology platform. Repeat work is an opportunity
to increase velocity.
A
bulk migration can save money. Operational costs in the cloud can be
reduced by consolidating applications and data in shared cloud resources where
it makes sense rather than provisioning each application individually.
Analysis, development, IT, and QA activities are more efficient and less costly
across a series of applications as opposed to ramping up for applications
individually. “Cookie cutter work” can be codified as step-by-step procedures
and handled by less expensive resources. Licensing costs could be reduced by
moving to application or database platforms that don’t require licensing (for
example, from IBM WebSphere in the enterprise to Tomcat in the cloud).
A
bulk migration provides better insights. When applications are migrated
individually, decisions about strategy and adapting existing processes and
systems are based on a partial view that gets refined over time. In a bulk
migration, there’s a large body of evidence to consider all at once: analysis,
financial modeling, strategy, and organizational impact are all based on a
fuller picture. This makes for better initial decisions.
A
bulk migration is an opportunity for uniformity. As applications are
migrated, they can also be retrofitted. For example, all web sites being
migrated could be retrofitted to use a common analytics system. If instrumented
for monitoring, applications can be configured for auto-scaling, where
deployment size is dynamically altered to match changes in load.
A Factory Model Approach to Bulk Cloud Migration
Cloud assessment and migration of multiple applications can
be handled well using a factory approach. The majority of personnel are
allocated to migration teams that make up the factory. QA teams validate the
correctness of what the factory produces. An Advance Team analyzes applications
first and keeps the factory equipped for the types of work it needs to do. An
Exceptions Team supports factory members, helping with problems and sometimes
taking over difficult migrations directly.
Factory Model Cloud Migration
Let’s review the teams that make up this model, their
responsibilities, and how they interact.
The “factory” is one or more technical teams who are able to
rapidly perform migration tasks. The high velocity is due to repeatable work of
the same nature (“cookie cutter” jobs), steered by concrete guidance. This type
of work favors a heavy offshore component to keep costs down. Migration tasks
could be complete migrations (e.g. “migrate a PHP web site”) or assembly-line
style partial tasks (e.g. “update this application to use a cloud-based caching
service“).
Like a physical factory, one or more supervisors are needed
to oversee how things are going and ensure the factory is humming along as it
should be. Problems that stop the assembly line need to be dealt with swiftly.
The Advance Team: Equips the Factory for New Kinds of Work
The factory only knows how to manufacture what is has been
configured to make. Someone needs to teach it new tricks to handle new kinds of
applications or variations on past patterns. The Advance Team consists of architects
and technology subject matter experts who analyze applications before they are
handed off to the factory, categorizing them as previously-encountered types or
something new. New kinds of applications are studied, and updated migration
guidance for the factory is created. If the new tasks are significantly novel,
factory members may need to be formally trained on the new pattern. The advance
team also sizes the migration effort required.
The Advance Team receives feedback from the Exceptions Team
on how migration work is going. This feedback loop drives continual improvements
into the guidance based on experiences using it.
The factory model is all well and good, but occasional surprises
and difficulties are inevitable. The Exceptions Team supports the migration
teams and helps them through problems with support. If necessary, the
Exceptions Team will take over a difficult migration directly. Unusual,
one-of-a-kind, or highly complex migrations will be handled by the Exceptions
Team.
The quality assurance teams test migrations produced by the
factory to confirm quality requirements are met and the migrated apps have
fidelity to the original apps. Often this will consist of a cursory check (performed
by the integration partner) followed by user acceptance testing (performed by
the owner organization). In the case of simple web site migrations, the
first-level quality check might consist of side-by-side comparisons of the
original and migrated web site, walking through the site by following its
navigation and ensuring pages display and interact identically.
How We Do It: Neudesic’s Azure Migration Factory
Azure Migration
Factory is Neudesic’s bulk cloud migration service offering for Microsoft’s
Windows Azure cloud computing platform. It implements the factory model
approach as described earlier and supports both Platform-as-a-Service and
Infrastructure-as-a-Service migration.
In Neudesic’s adoption of the process, a project management
office is staffed by Neudesic and client managers; migration teams are
primarily staffed with offshore resources; the advance team is staffed with
architects, Windows Azure experts, and technology subject matter experts; and
the QA/UAT teams are staffed by a mix of Neudesic and customer quality
engineers.
Azure Migration Factory
The PMO
Proactive, ongoing management is a cornerstone of Azure
Migration Factory. A project management office consisting of Neudesic and
client personnel oversee the ongoing migration effort. There are regular
meetings to review how the teams are doing against projections; and to determine
whether any changes are needed to the size or composition of teams. Work typically
proceeds in waves, where forecasts of upcoming work are used to ramp up teams
or decommission teams smoothly as the workload changes.
The Advance Team consists of architects, Windows Azure
experts, and subject matter experts on application technologies such as .NET,
Java, or PHP.
During the assessment process, the advance team evaluates
migration candidates and performs a sizing to small, medium, or large which
equates to a 1-, 2-, or 4-week migration effort. Early in the process, customers
are provided with sizing guidelines so that a preliminary scoping of the effort
can be roughed out; some of these findings may be revised once the applications
are analyzed directly by the advance team.
Applications are categorized using an application patterns
catalog for which step-by-step migration guidance has been prepared. The
catalog is updated when new application architectures or technology platforms
are encountered, or when a variation of an existing pattern needs to be
accounted for. At the customer’s option, the assessment process can run in
parallel and slightly ahead of the migration effort; alternatively, all apps
can be assessed before the migration effort gets underway.
Migration teams are made up of “pods” of consultants with a
set size, primarily consisting of offshore consultants. Pods can vary in their
skill set and platform knowledge, for example a .NET pod or a PHP pod. The
customer can balance migration speed vs. spend rate through the number of pods
approved to work in parallel.
Neudesic is able to migrate many kinds of applications to
the cloud by leveraging its technology practices, which include Business
Intelligence, Connected Systems, CRM/Dynamics, Custom Application Development,
Mobility, Portals & Collaboration.
The Exceptions Team consists of experienced consultants who
keep the migration effort on track by quickly unblocking migration teams when
they run into problems. They do this through support and, if necessary taking
over migration of especially difficult or unusual migrations.
Neudesic Quality Assurance teams verify migration success,
reporting issues back to the appropriate migration team if results do not match
expected appearance and behavior. Customer User Acceptance Teams then confirm whether
migrated applications meet their expectations.
The breadth of the Windows Azure platform allows migration
to target the most appropriate mode for an application: Platform-as-a-Service,
Infrastructure-as-a-Service, or managed web sites. Neudesic’s Windows Azure
experts are experienced across the entire platform and include
Microsoft-recognized MVPs.
Neudesic has unique intellectual property in the form of libraries and tools that accelerate the analysis and migration of applications to Windows Azure. This includes tools that partially automated the analysis of applications.
Customers who migrate to the cloud in bulk are often also in
need of a partner for support and management. Neudesic offers support and
management services for cloud applications through the Neudesic Managed
Services group.
Neudesic provides Windows Azure training services for
customers who wish to bring cloud skills in-house to their development and IT groups.
Summary
Once an organization has completed evaluating a cloud
platform and is ready for production migration, they have the option of
individual migrations or bulk migration. For companies with large numbers of
applications, bulk migrations—if planned and executed properly—offer great
economy of scale. The cost of migrating applications can be drastically lowered
when they are part of a group effort. Operational costs in the cloud may also
be lowered by finding opportunities to co-locate applications and data on
shared resources.
Bulk cloud migrations are best served by a factory approach,
in which similar applications and migration tasks can be made cookie-cutter and
easily repeatable. In this model the “factory” are lower-rate migration teams
who make up the majority of the work force. The factory is supported by an
advance team, an exceptions team, and QA teams.
Applications migrated together can be retrofitted for
uniform methods of monitoring and analytics; and configured for auto-scaling.
Neudesic has implemented the factory approach for the
Windows Azure platform in its Azure
Migration Factory service offering.
Large-scale migrations require large-scale thinking. The
factory approach described here provides a scalable pool of affordable
migration resources, coupled with the support of senior resources necessary to
ensure success.
Neudesic - The Trusted Technology Partner in Business
Innovation
http://www.neudesic.com
http://cloud-assessment.com
http://www.neudesic.com
http://cloud-assessment.com
