clckwrk (an RDX company) and NetApp recently joined forces to present Moving Oracle Systems to the AWS Cloud. During the webinarIan Lewis, Principal Consultant at clckwrk, and Jeff Steiner, Principle Architect at NetApp, discussed the benefits of moving your Oracle workloads to the AWS cloud. Ian highlighted the importance of using a consultant like clckwrk to help implement migration best practices, and Jeff provided insight into how NetApp’s Cloud Volumes Technology helps organizations optimize the way they store data in the cloud.

If you missed the informative presentation, don’t fear! We took notes during the Q&A session and are providing the valuable answers here.

Question 1: This question is for clckwrk. Are most databases you manage in EC2 or RDS? We are trying to determine which to you since RDS has some access limitations, one of them being that we cannot grant certain privileges as a systems user in RDS.

Ian: That’s a good question. We do see a split between EC2 and RDS. When we engage with a customer, that’s one of the main things we discuss during the discovery process. We understand what the application is and what requirements it has, and that feeds into our decision tree. The leaders to be can then recommend either EC2 or RDS based on our discovery process. There is a short list of requirements that can indicate that RDS is not an option for an Oracle, but that's based on a customer-by-customer and application-by-application basis.

There are some well-known applications, like Oracle EBS, that can't go to RDS because they have the requirements of certain functions and admin tasks that have to be carried out directly on the database from our end. If you don't have access to the command line in RDS, that means it has to go to EC2. There are certain AWS equivalents to SYS, which can sometimes be enough to work around the fact that we don't have direct SYS access in RDS that will enable you to use RDS.

Another reason why you can't use RDS is if you run a particularly old version of Oracle.that RDS doesn't support. You then might have to go to EC2 instead. So, there is a list of things that we look at and questions we ask, which enables us to give a definite answer if RDS is a possibility. That’s what we feed back to the customer as part of the discovery process.

Question 2: How does Oracle on AWS compare to Oracle Cloud?

Jeff: That is a really good question and honestly, I'm still trying to get a handle on where the value of Oracle Cloud lies so far. We just don't see that come up a lot. I was thinking, personally, as someone who managed a large Oracle state, including applications. I think the primary value of Oracle Cloud is more of a software as a service.

It just doesn't have the cloud capabilities of AWS. So if you want, for example, to host an Oracle, HR and Oracle financials application, I think Oracle Cloud looks pretty compelling. You don't have to hire the administrators anymore. You just pay the subscription fee and someone else is managing it, including the backups, the updates, patches, etc. So, that is definitely the sweet spot for Oracle Cloud. They’re certainly trying, but they just don't stand up to the flexibility of what you get on AWS.

The only time that I really see people going over to Oracle Cloud is Fortune 50-level companies where they don't want to have a data center anymore, but they have a particular workload that just flat out needs a full RAC Exadata, and there’s no Exadata as a service on AWS. It is also getting easier and easier to link multiple clouds together, so that doesn't mean that it has to be an either-or question. You can use both. But that's the best I've seen. It really is about the flexibility. If all you want is an Oracle application with an Oracle database, it's pretty much out of the box and you want to cobble a lot of different Oracle products together, an Oracle cloud looks pretty compelling. But, the more you want to do something that falls outside of Oracle products and technologies, the better AWS looks. That might mean you've got a little more work to make the database perform the way you want it, but that's offset by all the other benefits you get.

Question 3: Where do we start and how do we engage in a migration?

Ian:.A customer would perhaps engage us at the very beginning of the cloud journey when they’re thinking of moving to the cloud, but they don’t know what that entails. Also, customers might have attended an AWS event, and through that, they may have met us as a partner at these events. We would then understand what they have and help them to formulate a roadmap that includes migrating to the cloud. And if that proceeds, we would go through the discovery phase, where we drill into more detail as to how what they currently have could be migrated into AWS, ie, how that would happen, how it would look, all the ongoing costs to take into consideration. We would also look at other services that can be brought to bear, native AWS services such as NetApp’s Cloud Volumes technology that Jeff talked about.

It's normally at that early stages in the company’s path to AWS where we get engaged. It could be the strategy, or it could be the actual discovery and design phase if the customer has already started or already has AWS in mind. Also, some of our customers may already be in AWS or may have migrated a large number of their workloads, but we often find the ones left behind. The ones still on premise are often the Oracle workloads because they can be more complicated to move. A customer may already be well acquainted with AWS but may have engaged at that later stage. That’s when we then can dive in again and do the discovery stage, the design phase and move into a migration for them.

Jeff: I've got something to add to that as well. I committed these cloud databases from a different angle where we'll typically have an established customer who’s looking for a cloud solution, and we go through the slides, explain how it works and talk about the benefits and the performance. Then they say, “Ok, I believe you. Now, what?” That's my answer. If you can get it, I know it will work. That’s where I've been sending people over to clckwrk and just say, “Talk to these guys. They’ve got the experience and know what sort of snags you are likely to go into, what kind of timeframes you're going to face, even the little things like how you get the data from on premises to the cloud.”

I'm sure I could figure it out, but I just don't have the experience in that.

Question 4: Is network latency a concern for our applications deployed on the cloud? We have custom applications running on WebLogic, app server and Oracle database.

Jeff: Yes, that is a very significant issue. Network latency between the app server and the Oracle database should not be a problem. It’s not quite local land speed, but it's close. Storage latency is definitely something to watch, and that will vary even depending on what region you're working in. One of the main things that Cloud Volumes ONTAP and Cloud Volumes Service does, especially Cloud Volumes Service, is provide superior latency, but it's still not going to be quite what you get on premises. In almost every case, it's better than what you can achieve with the native resources and that's it. So, it's subtle, but that really is the number one benefit that makes the difference between being able to run a database in the cloud and flat out not being able to. It's not the IOPS, and it's not the size. It really comes down to the latency, and the only advice I can give on that one is that you have to test this. I mean, I see Oracle AWR reports every day, and I do have to tell someone this will not work in AWS. Sometimes there are ways around it. I actually know one very large customer that overcame the latency by using huge amounts of RAM and licensing Oracle in memory. So they were avoiding the storage IO and the associated latency. Sometimes you might have to actually change some queries around to change some application logic, but it is definitely something to watch very carefully. It can be done. I mean, that's in almost every case. Yes, you do have a way to make it work, but the important thing is just simply transplanting things as-is is shaky. We can usually make a pretty good guess of whether it will work based on some AWR data, though.

Question 5: How does Oracle on Azure compared to Oracle on AWS?

Jeff: So far, it seems like a business decision. Microsoft has been really aggressive out there. Some customers signed contracts with Azure, and that's the preferred vendor, but in the end, the products, the features and the capabilities are pretty much the same.

Question 6: Are Oracle databases licensed per instance on AWS? We virtualized our Oracle databases and have several databases running on the same physical server to save on licensing costs, for example, an eight CPU server with three databases.

Ian: Yes, the Oracle licensing on AWS is done on the virtual CPU count. You need one Oracle license to two virtual CPUs in AWS, so you can still consolidate and have multiple databases running a single EC2 instance. For example, you would license the EC2 instance based on its virtual CPU count, but you could run multiple databases on that single server. So, if you've consolidated on premise, you can still lift and shift and copy that site consolidation setup in AWS.

Jeff: And Oracle has a document on how to calculate how many cores of licenses you will burn for a given AWS instance. I've seen a handful of customers switch to Standard Edition of on premises and in the cloud.

A lot of the time, you lose enough to where that option’s just not favorable, but it is something to consider. One last thing- I've presented on virtualizing Oracle for years, and I have a whole section in one presentation about wasting licenses. Based off of almost every AWR report I've ever seen, if an organization is using half the cores and the servers, that's unusual. I mean, most of the time it's twenty-five percent at peak because these modern cores are so ridiculously powerful. So, odds are you're already using and you're already licensing more cores than you really need.

Ian: Yes, that's a good point. Part of our discovery process is when we drill down into what features are enabled in a database and which of those features are actually used. We often find a customer has an enterprise database and an enterprise license, but they’re actually not using any of the enterprise features. So, we can move them onto Standard Edition in AWS, and that greatly cuts the cost. More so, Jeff, the multi AZ RAC-level replication that you have in NetApp could be an alternative to using Data Guard, so you could lose Data Guard in AWS and potentially lose the enterprise database license as well, as you can then go to standard. You also mentioned CPU performance. We often find that the CPUs in AWS are normally more high performance than those on premise typically. One reason people are starting to move away from on premise and onto AWS is because their hardware is getting towards the end of life. The CPUs in those servers could be quite old compared to the virtual CPUs in AWS. We did some benchmarking, and you can normally get better performance from AWS CPUs. You can actually choose the number of CPUs in AWS compared to on premise and still get equal or better performance, and that's a good way of saving licenses as well.

Question 7: How long does a migration take? Is there a certain range we should expect?

Ian: The “it depends” answer is probably the best one. During the presentation, we mentioned we migrated a customer to AWS in four weeks. That’s not typical, but it is something that can be done. The AWS tools are there to enable getting large amounts of data into AWS quickly, but we've had other projects that have been eighteen months in duration. There are many factors in migrations of that size, the amount of application testing, the business change freezes, etc., which means you can’t do the actual cutover until the late stage. Is there an average? Well, maybe six months, but it's very hard to say without actually doing the discovery and understanding what the customer has.

But, as output from our discoveries, we do give pretty accurate time scales and costs for performing a migration because we've been doing them for around eight to nine years. We have a very defined set of metrics, and there are patterns that we see, so we can give pretty accurate ideas on how long that migration may take.

Question 8: What are the typical reasons to keep Oracle in your data center as opposed to moving it to the cloud?

Jeff: It usually comes down to the IOPS and the latency. I've got a project going right now where we've wrapped up migrating a single eight hundred terabyte database from on premise to AWS and to make it even more fun, we had to convert it from AIX to Linux along the way. So, size really isn't the problem. Now, I wouldn't try an eight hundred terabyte database on EBS volumes under any circumstances, but Cloud Volumes Services? Sure, no problem.

It comes down to the IOPS and the latency, so I help out the account teams with quick little performance overviews all the time. And if someone brings me an Oracle AWR report and I see two hundred and twenty thousand random IOPS or ten thousand random IOPS that are currently getting four hundred microseconds of re-latency and a hundred and twenty microseconds of right latency, I don't think that can go right now. Maybe someday it will, but what's going to happen to that application? Now, if that that application is just for people that are submitting online orders, no problem. Nobody cares if it takes an extra two milliseconds for an order to be submitted and to have your web browser refresh, but if that's like a banking application or something that's producing invoices, that kind of latency will hurt. It's not a matter of how can you do it or if it would be too hard. It becomes flat-out impossible, and this will keep changing for every storage vendor. Every cloud vendor is fully aware of the latency within their networks. The storage latency is a lot higher than a lot of customers want. Every time they improve something, it becomes more of a competitive problem for us. Maybe you can start doing more things natively, but at the same time, we can also use that as well.

So, that's why what we've done, solved a lot of right latency and IOPS problems because AWS gave us the ability to get a little MVME drive inside of a VM. But that's really what ends up being a limitation.

And if anybody is coming to NetApp Insight October 28-30, I've got five different presentations there that go into every aspect of database on everybody's technology.

Still looking for more information about moving your Oracle workloads to AWS? Listen to the full recording here!