Moving
applications to the cloud can bring great benefits to your organization and
increase the flexibility and responsiveness of your IT department. However,
when making this move, there are lots of issues to think about. For example, how
secure is my data in the cloud? How reliable is the cloud-based application?
What is the actual cost? How can I migrate my existing data to the cloud? And
so on.
In this
post, we’ll discuss some of these issues and look at the questions that you
should ask before you make the move to the cloud. This list is not intended to
be exhaustive and, depending upon your particular circumstances, some of these
things might not apply – or there might be other things that you need to add to
the list.
1.
Objectives/Goals
What
are the goals and objectives of moving to cloud? Is it to reduce costs, or reduce
time-to-deployment, or free up IT resources for other tasks? If you don’t know
what your goals are, then how do you know whether moving to the cloud has been
successful or not? If you don’t know your goals, then why are you moving to the
cloud at all – just because it seems like a cool idea?
List
your goals and objectives, prioritize them, and quantify them. This will give
you a measuring stick to determine if the Cloud is successful for you.
2.
Security
Security
is important – whether it is securing data stored in the cloud (“data at rest”)
or data moving between cloud apps and on-premise apps (“data in motion”).
Security breaches can be very embarrassing and can lead to financial loss (and
regulatory penalties if the breach affects data covered by privacy laws).
Wherever
the data is stored or in motion, it is your data and therefore your
responsibility to ensure that it is secure and protected. Just because your app
is in the cloud and supplied to you by a cloud provider does not absolve you of
responsibility for the security of your data. You need to make sure that your
cloud provider is securing and protecting the data on your behalf, whether the
data is at rest or in motion.
So you
should ask your cloud application provider how they secure your data in the
cloud. Do they encrypt the data? What about when the data is in motion? How is
it protected then? How do they protect the application against security
breaches? Do they perform threat analysis and penetration testing of the
application? Are they willing to discuss the results with you? The answers to
these types of questions will give you an understanding of whether your application
provider is securing and protecting your valuable data.
3.
Reliability
Make
sure that the cloud application reliability (as defined in your SLA) matches
your needs. If your cloud application is, say, an HR application, then having
12x5 availability is probably going to be OK. But what if the application is a
part of a mission critical business process that needs to be available 24x7? Or
what if the application must have guaranteed availability and reliability at
certain times of the day e.g. at the close of trading for financial
applications or at closing time for retail applications (for end of day
processing, in both cases)?
Check
that your cloud application SLA meets your particular requirements with regards
to reliability and availability – don’t just assume that, because the
application is in the cloud, it’s always available. Ask your cloud provider how
they provide the reliability and availability – do they have load balancing and
a high availability architecture in the cloud? Or are there points of failure
that could halt the whole application?
4.
Disaster recovery
Disaster
Recovery (DR) is somewhat related to reliability and availability, but in a
slightly different context. DR covers the situation where there is a total
failure of the data center where your cloud application is running. This has
happened recently when Amazon lost power to one of their data centers in
Virginia due to an electrical storm in the U.S. Mid-Atlantic region. This power
outage affected services such as Netflix, Instagram, and Pinterest – albeit
only for a few hours. Last year, a transformer failure knocked out the power to
Amazon and Microsoft data centers in Dublin, Ireland. It took up to 2 days to
restore some of the services running in these data centers.
How
would you be able to withstand a loss of your cloud application for an extended
period of time? How would this affect your ability to do business? If your
cloud application is important, then look for a cloud provider that offers a DR
capability. You will almost certainly have to pay for this functionality, but
it will be worth it if it prevents extended application outages.
Ask
your cloud provider how they support DR e.g. is the DR application located in a
physically different data center to protect against problems such has power
outages or natural disasters? What is the replication strategy between the
‘live’ data center and the backup (DR) data center? How frequently is the data
replicated? How long of an outage at the live data center is required before
triggering the DR application to start up? How long does it take for the DR
application to start up? What is the recovery strategy for interrupted
processes and transactions?
The
answers to these questions will help you to determine whether the cloud
provider’s DR capability is suitable for your needs.
5.
Cloud operations – who is
monitoring your application?
When
you use a cloud application, you are effectively outsourcing some of the
administration and monitoring of the application to a third party i.e. your
cloud provider. You need to understand what application and system health
metrics the cloud provider is monitoring on your behalf. You need to make sure
that they are monitoring enough metrics to catch problems as soon as possible –
preferably before they affect the performance or availability of the cloud
application. Items to be monitored by the cloud provider should include:
- CPU
Thresholds
- Load
balancing functionality
- Disk
utilization and volume capacity
- Database
metrics, e.g. utilization, I/O, etc.
- Application
specific metrics, e.g. listening ports, process pid’s, etc.
- URL
availability for user interface access
- Security
attacks:
- Denial of service attacks
- Brute force attacks
- Illegal log-in attempts
- Unauthorized file access, e.g.,
non-root user attempting access to host files
- Virus scanning
These
metrics – and alerts based on metric thresholds – should provide suitable information
about whether the application is running or not and whether anything abnormal
has occurred (e.g. a runaway application consuming all CPU cycles). However,
system or application level metrics and alerts don’t tell you whether the
application is performing as promised. If application performance – whether
response time, throughput, etc. – is important, then you need to ask your cloud
provider about mechanisms to monitor performance. For example, this could be
sending a test transaction through the application on a periodic basis to
measure the processing time or response time for the transaction. If they don’t
have any such mechanism or process, then how do you know whether your
application is meeting your performance criteria?
6.
Self-serve dashboards
Although
moving an application to the cloud means that someone else will be monitoring
the health of your application, it doesn’t completely absolve you of all of
that responsibility. After all, if something goes wrong with the cloud
application, the users within your organization won’t be able to contact the
cloud provider to find out what’s happening – they’ll need someone within the
organization who can tell them what’s going on.
This
means that your cloud application will need some type of self-service dashboard
which can provide a view on to the application and its health. Using the
dashboard, you will be able to notify your users if there are any problems,
such as slow performance, the application being unavailable, etc. This, in
turn, will result in a better user experience as they will be informed about
problems rather than just staring at a blank screen.
7.
Transparent pricing
Before
you sign up for any cloud-based application make sure that you fully understand
the pricing model. This sounds obvious but often people are caught unaware by
‘hidden charges’ that were not fully explained before they signed up.
For
example, if your cloud application costs are based on a ‘per user’ subscription
is this concurrent users or named users? What is the cost of adding more users?
How easy is it to add more users?
If your
application costs are based on throughput or transactions, what is the cost of
going over your quota or limits? Are there ‘overage’ charges (similar to cell
phone plans)? Or are you automatically bumped up to a higher quota plan with a
higher subscription cost? Is there a grace period if this is a one-off
occurrence? Or are the additional fees (overage or plan upgrade) automatic?
Also
consider the commitment period for your subscription. If this is month-by-month
with no lock in, then this is not going to be a problem. However, if you pay
for a year’s subscription in advance, what happens if you decide to cancel
before the year is up? Do you get a refund for the unused portion of your
annual subscription?
The
answers to these questions might not affect your decision to use a particular
cloud application, but you should at least be aware of the costs before you
sign up, so that you’re not hit with unexpected fees when it’s too late to
change.
8.
Migration
Unless
you are starting from scratch with a brand new application, the chances are
that you’ll have some existing data that you want to convert and migrate to
your new cloud application. You’ll need to understand what bulk data import
capabilities are provided with your application. Most applications offer some
form of data import capability and they are usually fairly easy and
straightforward to use.
However,
you shouldn’t underestimate the amount of effort involved in migrating your
data to the cloud. The data import mechanisms usually require that your data is
in a certain format before it can be imported, so you will need extract and
convert your existing data to match the import format. You should also take
this opportunity to cleanse and refresh the data before you import it into the
cloud application. If you’re importing CRM data, this is a good chance to go
through the data and refresh any old and old-of-date customer information or
delete any obsolete product or pricing data. If you need to enhance or extend
the data, e.g. by merging in data from another source, now is a good time to do
this.
Migration
should also include the training users on the new application and planning
their switch over to the cloud. Is this going to be a ‘big bang’ approach where
everyone will move to the new application at the same time and any old
applications will be switched off? Or will you have a phased approach to moving
user to the new cloud application? Both approaches have pros and cons and you
need to decide upon your approach to this.
9.
Integration
While
using applications in the cloud can bring great benefits to your organization,
you won’t truly realize those benefits until you integrate your cloud
application with your existing applications and business processes. If you
don’t do this then you get application silos that result in fragmented business
processes with too many manual steps or data duplication and data rekeying. If
you consider a basic application, such as an HR application, even this needs to
be integrated to other applications, such as your talent management
application, your IT systems for provisioning of email accounts and system
logins, etc. Additionally, your HR application is just one part of your new
employee on-boarding business process, so your HR application needs to be integrated
into the process flows for on-boarding your new employees.
When
planning to integrate your new cloud applications with your existing
applications and business processes, you need to consider how you access the
data and functionality of the new application. Is this via an API? If so, what
standards and formats does the API use? The most common cloud application APIs
are Web Services based, but do they support SOAP/XML or REST protocols? If the
cloud application has a ‘batch’ import/export interface, what sort of data
format does it support (e.g. XML, CSV, or JSON)? Are these protocols and
formats compatible with your existing applications? Do you have in-house
knowledge of the protocols and formats?
Answering
these types of questions will help you to prepare the integration of your new
cloud application to your existing applications and processes.
10.
Managed Services
Last
but not least, we have managed services. Cloud providers are increasingly
complementing their cloud-based applications with managed services offerings to
help you to get the best out of the application. These managed services can
range from offerings to get you started quickly, such as migration services or
‘quick start’ services, all the way through to managing the full solution on
your behalf. These managed services can complement the skills and expertise
that you have in-house and make it easier to get value from your new
application.
Managed
services are also a good way to free the IT staff from the routine tasks of
managing and administering the cloud application. Hopefully, with the time
freed up they can focus on more valuable work for the organization. Ask your
cloud provider about any managed services that they offer. If these are of
interest, find out about the scope of the services – exactly what does the
cloud provider do? And what is still left for you to do? For example, if you
are using a full managed service to run and administer the cloud application on
your behalf, are there any limits on the work provided? Is it based on hours of
effort? Or number of tasks? Or will they do anything requested? How do you
request work to be done such as adding a new user to the application)? How long
does it take before they perform the requested work? How can you get urgent
work performed as a priority task e.g. if your CEO wants a report immediately?
This
type of information should be supplied, by your cloud application provider, as
a definition of the scope of a particular managed service offering. Make sure
that you understand what you are getting before you sign up for a managed
service for your new application.
So there it is – ten things
to think about when moving to the cloud. As I said earlier, this list is not
exhaustive. Your particular circumstances might add new things to the list and
make some of the above things irrelevant. However, if you use this list as a
starting point, you will be able to ask the right questions to your cloud
providers and your move to the cloud will be from a perspective of knowledge
and understanding the challenges, and not from one of blind optimism and hope.
