Are you considering taking advantage of the Amazon Web Services (AWS) platform but are concerned about the risks involved in moving your Oracle database?

Existing Oracle database systems in large organisations are generally well-established and finely-tuned. It’s understandable to be worried about the possible effects of making changes. But, rest assured, most (if not all) Oracle database workloads will run just fine on AWS. In this article, we give you some tips  to ensure the move is as trouble-free as possible.

Your two basic options at AWS

Just before we talk about how to get there, here are the two basic platform or infrastructure configuration options you have available when migrating your Oracle DB to AWS:

1. RDS (The Platform Option) AWS gives you the option of deploying an Oracle database on its RDS (relational database service) platform – a hosted and managed Oracle database service – aka Database As A Service (DBaaS). The idea behind RDS is to reduce the management overhead: AWS installs and patches the database server on your behalf – you just load up the data or connect your application using the SQL client connector that you’d be familiar with. Be aware, however, that (as we write) the versions you have available as RDS are 11g and 12c Also – there are some limitations, for example: APEX is only available in limited versions; Spacial is not available; and you can’t log in as SYS, SYSTEM or other administrative accounts. You also don’t have access to some system tables and procedures) By the way – you can by an Oracle licence from Amazon along with your RDS, or you can Bring Your Own Licence. The BYO Licence is particularly attractive for enterprise customers who have an “all-you-can-eat” licence deal with Oracle.

2. Build it yourself (The Infrastructure Option) Of course, if the RDS doesn’t meet your needs – for example because your version isn’t available, or your options are not available, or if some of the technical characteristics don’t work for you (which we discuss shortly) – then you can always just spin up an EC2 instance, attach some EBS storage and build it like you’ve always been doing it in your “private cloud” or on premise environment. It is of course your responsibility to make sure you’re appropriately licenced as this is not purchased from AWS in this scenario.

The six dimensions to consider when moving to your database a Cloud platform

You have probably heard of cases where migration to the Cloud has not been successful. This can most often happen when there is insufficient understanding of the fundamental characteristics of the various application components.

Data is the foundation of almost all applications. The storage and access of data can be highly I/O intensive and techniques needed to ensure the database is performant and resilient are different from the generic “web app” cloud availability techniques. Going back to basic principles, the applications tier and the database tier don’t scale the quite the same way.

With that context in mind, we’ve found that there are six key criteria that need to be considered when moving your Oracle database to the AWS cloud.

Functionality / Application changes:

Functional changes are going to cost. Any time you need to update or regression test an application you will incur cost – everything from developers implementing application code changes, to operational training and change management. Simply diverting people from doing their normal work to performing user acceptance testing can cost you productivity if not direct cost. We highly recommend the use of automated testing suites but there is no substitute for human testing of an application so don’t understate the impact! When migrating your database, the key is to minimise any application changes required – differences between your current environment and the Cloud platforms should be quantified so the impact can be assessed. It is absolutely possible to have zero functional impact – but don’t under-estimate the cost of proving that!

Capacity:

Throughput, Response, Volume and Performance are all inter-related terms or measures of Capacity. It would be rare to have end-users of an application accept a reduction in Capacity – but in different scenarios some elements of capacity are more visible than others, and all need to be considered specifically for each application. Throughput is a typical measure for API’s, Services and batch processes; Response time relates to user experience (or API/Service experience); Volume needs to be considered when planning long-term storage utilization and when considering the peak number of users or API calls you’re expecting. AWS has an enormous capacity to serve up low-cost storage volume and low cost commodity compute. You just need to ensure your database is provisioned with the correct capacity for the application loads you’re expecting to see. Some of the elements of capacity can be relatively easily changed if required (such as the compute or memory size), but that’s not necessarily true of the underlying storage layout which could require a complete re-organisation if you need to make a significant change. There are definitely flexible options on AWS but you need to gauge how to utilise this new platform capability to manage capacity compared to your current systems.

Resilience (aka Availability or Continuity)

This is arguably the most controversial topic when migrating an Oracle DB to AWS. RAC (real application clusters) has been the default technique for ensuring availability of an Oracle DB for many years now – but you can’t do RAC on AWS. So, there is no true active-active availability solution. That said, being able to quickly restart your database is enough for a lot of applications. We’ve also built solutions utilizing Data Guard which enable automatic failover in just a few minutes – including across regions, solving another potential issue, which is that the EBS storage volumes underpinning the database are constrained to a single availability zone.

Security:

We could write a whole article on security, but for the purposes of these general guidelines, let’s just say that migrating to Cloud presents a whole host of new and exciting security considerations. The actual database security doesn’t change – it is about whether you’re securing your infrastructure and storage appropriately, and limiting access on a least privilege basis as you normally should. Don’t be scared off by this one – just take it seriously! Keep in mind, too, that you’ve got options to do AWS storage level encryption that you might not have otherwise had.

Agility:

One of the major selling points of migrating to AWS is the agility – the ability to priovision and de-provision almost limitless numbers or sizes of database. (Note we said “almost”). You’ve also got the option to resize compute and storage as required (notwithstanding that you’ll need an outage). You’ll need to work on your internal processes, but there are enormous advantages available in agility.

Cost

Deploying your Oracle DB typically incurs a startup capital cost, and ongoing operating cost and a licencing cost. There is no doubt that the AWS “pay as you go” model significantly reduces or even eliminates any up front capital expenditure on the compute and storage infrastructure. Offset against this are the ongoing subscription fees. With a pay as you go subscription model you have a lot of options to manage ongoing costs: eg by stopping production instances when not required, or by stopping Dev/Test instances except when required for specific activities, or by reducing the size of instances when possible. Utilizing the RDS model, you also save on administration costs by having AWS perform patching and upgrades. Don’t forget, though, to factor in you Oracle licence cost, which may be more expensive on AWS than in an on-premise (or Oracle Cloud) model.

Each of these criteria will be weighted differently depending on the particular organisation’s requirements. It’s important to recognise that a ‘one size fits all’ approach is not likely to be viable.  And where there are features that are not provided by a Cloud platform, a truly knowledgeable partner should be clearly presenting organisations with a number of alternate solutions on each of the six dimensions which can then be tailored to their needs.

A plan for action

Migrating one or one thousand Oracle databases on to AWS (or any other Cloud) is often a sizeable, complex project. The starting point for your Oracle to AWS transition is to have a clear vision and plan. This planning process is a critical step for enterprise IT leaders and as such it’s a key service line of ours – Fusion Professionals brings proven experience in helping you assess the key requirements outlined above and planning the migration process while mitigating risk.

Steps in the planning process typically involve:

1. Assessing your current database environment

2. Evaluating requirements around the criteria outlined above

3. Demonstrating a ‘before and after’ comparison and what your database would look like on AWS

4. Creating a new demo environment to showcase what can be achieved

In our experience there are clear, quantifiable benefits to an organisation in moving to Cloud, particularly AWS. Where required, Fusion Professionals can implement alternative solutions that will satisfy your requirements in a Cloud environment at least as well as in the current environment.

About Fusion Professionals

To successfully migrate  your Oracle databases to “The Cloud” it’s absolutely imperative to partner with a solution provider that has proven experience and technical capabilities across both Oracle and AWS. Fusion Professionals technical capabilities and in-depth experience across other similar projects in Enterprise-level organisations with both Oracle and Amazon Web Services can simplify the process of moving your Oracle databases to AWS while minimizing any loss of features or behavior. The outcome for you will be the realization of benefits – particularly in cost reduction, agility and  systems management. By the way – we also migrate other SQL and No-SQL databases – so call us if you’re considering any data migration projects!

Upcoming Articles

Stay Tuned (excuse the pun): in future articles, we’ll give you:

1. Supercharging your Oracle database at AWS (technical details on how to maximize the performance of your Oracle DB on AWS); and

2. Magic Happens Here – how to migrate off your Oracle database with (almost) no impact to your application or database code.