cloud | The ORACLE-BASE Blog

Why Automation Matters : Can’t the cloud do it for you?

One of the comments on my previous post in the series mentioned using the cloud may solve a lot of these issues, implying you don’t have to bother with your own automation. Cursed with the ability to see both sides to any argument, I both agree and disagree with this. 🙂

Cloud providers bring a lot to the table as far as automation is concerned. Firing up new VMs and containers is really simple, and of course platforms such as RDS and the Oracle Autonomous Database family take over many of the operational aspects. So I can forget about automation right? Not so fast…

We typically see demos of cloud services that involve clicking buttons on web pages and it all works and looks great, but it’s not the way we really want to work. We want our infrastructure as code, and you can’t check button presses into your version control. 🙂 Also, if we are promoting self-service in the company, the last thing we want to do is give everyone access to our cloud account.

The cloud providers have got our back here. They allow us to use CLIs, web services and tools like Terraform to define whole chunks of infrastructure based on their services. You can use these tools to create your own self-service portals within your company. But that’s a new bunch of stuff you have to learn to become effective using this platform. It hasn’t freed you up from having to think about automation completely. It’s just altered your focus.

What’s more, a cloud provider will not be able to provide every solution you need, configured exactly the way you want it. They may provide many of the building blocks or platforms, but you are still going to have to do some of the work yourself, whether it’s application configuration or change management. All of this still needs to be automated if you want to live up to the infrastructure as code mantra.

We also have companies at various stages in the cloud journey to consider. Some companies are still not considering cloud. Some are part way through the journey. Some will almost certainly be running in mixed environments, made up of on-prem and multiple cloud providers for a long time, or even forever? Automation allows you to abstract some of the working parts, giving you some consistency in these mixed environments.

I think this all comes down to levels. You may never have to install or patch a database again, but that isn’t the whole story as far as automation is concerned.

Check out the rest of the series here.

Why Automation Matters

Cheers

Tim…

The first rule of Oracle Cloud Apps is: You do not talk about Oracle Cloud Apps

The wife has written a couple of posts recently (here and here) about the inevitable confusion that results when speaking about Oracle applications and the cloud. It’s really hard to speak about this stuff and know everyone is hearing and understanding what is being said, rather than what they think is being said.

Think about it for a minute.

Oracle Cloud Apps – Version 12. You can run them On-Prem, but most people will only ever experience them on the cloud. Not surprisingly, when I say “Oracle Cloud Apps”, this is what I’m talking about. My company is currently moving to Oracle Cloud Apps and we have no EBS.
E-Business Suite on the Cloud. Version 12.x. They’re Oracle applications and they run on the cloud, so they are Oracle Cloud Apps right?
If you are writing extensions to SaaS using the PaaS features, you are writing Oracle apps in the cloud. These are Oracle Cloud Apps right?
E-Business Suite 12.x. They are Oracle Apps and they are at version 12, so they are Oracle Apps 12 right?
Fusion Middleware 12c Release 1 or 2. If I’m writing apps on this stack they are Oracle Apps at version 12 right?
I can put anything on Oracle Public Cloud. Those are then Oracle Cloud Apps right?
All the other applications products and NetSuite etc. They are Oracle Cloud Apps right?

In the above examples I’m being intentionally silly, but I think you get the picture. If you are a little loose with your terminology, description or phrasing it’s really easy to be misunderstood.

What’s more, as individuals we each have a different set of experiences, so we are entering the conversation with some specific context in mind, and kind-of assume everyone understands our context.

Today I had a chat on Twitter with a couple of guys (Andrejs Karpovs‏ and Andrejs Prokopjevs‏) about my “Oracle Cloud Apps DBA” comments in this post. Both those guys are infinitely more qualified to speak about apps than me, but for a time I think we were speaking at cross purposes. I agree with everything that was said in the context it was said, but we were coming at things from quite different angles, so we seemed to be disagreeing at times. 🙂

It just feeds back into what Debra has been saying about how you have to be super careful when you discuss this stuff, and why she’s started to use the “Oracle Fusion Apps” name again in some conversations. I find myself saying things like, “Oracle Cloud Apps, formerly know as Oracle Fusion Apps”, which is a complete pain in the ass and doesn’t work too well on Twitter. 🙂

Cheers

Tim…

Oracle’s Cloud Licensing Change : Be Warned!

Over the last couple of years I’ve been doing talks about running Oracle databases in the cloud. In both my talks and articles I refer to the Licensing Oracle Software in the Cloud Computing Environment document. This morning I was reading a post on a mailing list and someone mentioned the document had been updated on 23-Jan-2017 and contained two rather interesting changes.

The Good

The document now explicitly mentions the difference between how vCPUs are licensed on different cloud providers. On AWS a vCPU is one Intel hyper thread, so you need 2 vCPUs to make a real core. Azure does not use hyper threading on their boxes, so 1 vCPU equals a real core. The previous version of the document did not make this clear, so it read like you were paying per thread on AWS, even though people who used cloud-savvy partners understood this issue and paid correctly (vCPUs/2 on AWS).

The Bad

The document now says,

“When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”

Just digest that for a moment. The intel core factor is 0.5, so an 8 core physical box requires 4 cores of licensing. Now on the cloud, an 8 core VM (16 vCPUs on AWS or 8 vCPUs on Azure) requires 8 cores of licensing.

On the 23-Jan-2017 the intel core factor was removed from the cloud licensing calculation and overnight your cloud licensing costs doubled! WTF! 🙁

Update: For the new AWS bare-metal service, the core factor *should* still apply.

The same person also pointed out that in a MOS Note (Doc ID 2174134.1), last updated on 20-Aug-2016, Oracle pulled support for the Oracle Multitenant option from AWS EC2. WTF on a bike! 🙁 I assume they mean both non-CDB and Single Tennant (Lone-PDB) are still supported.

The Ugly

The reaction to this is going to be really bad! It’s getting really hard to remain an Oracle fanboy these days!

If you have been to one of my cloud talks over the last couple of years and you are basing your opinion on something you’ve heard me say, please remember things change. For those people I presented to at the UKOUG Database SIG on Tuesday, I’m sorry, but I was 2 days out of date on one slide. I’ve updated my slides and articles to reflect this change!

This is all so completely depressing!

Cheers

Tim…

PS. I’m not saying this policy document overrides your contracts. Just saying this is the most recent policy document produced by Oracle!

PPS. You might want to take a look at page 19 and the addendum on page 23 of this copy of the NoCOUG Journal.

Cloud First (again)

cloud During OpenWorld I wrote about my thoughts on Cloud First, an approach Oracle is taking for some of its products now. A discussion on Oracle-L has sparked this post.

One of things I hoped Cloud First would accomplish was to allow Oracle to fix more of the bugs before they dropped the on-premise release. Let’s look at the current 12.2 timeline.

20th September (approx): The first 12.2 product was the Exadata Express, where you get a PDB in a fully managed cloud service, was released at OpenWorld. At least up until a few days ago this service was running was 12.2.0.0.3. That doesn’t sound like an on-premise release number to me.
4-5th November: At the end of last week the Database Cloud Service (DBaaS) on Oracle Public Cloud got an update to allow you to provision 12.2.0.1 instances. That sounds kind-of like the version number of a first on-premise release to me. Also, the DBaaS offering is not automatically patched, so Oracle must have a reasonable level of confidence with this release if they are happy to put production DBaaS customers on it. 🙂 There is no installation media on this service, but there is a zip of the “app/oracle/product/12.2.0/dbhome_1” directory structure in the “/scratch/db/db12201_bits.tar.gz” file.
Currently the Database Cloud Service (Virtual Image), which builds a VM with installation media in the “/scratch” directory, does not allow 12.2.0.1 yet. Either they’ve not had time to finish this yet, or they don’t want to make getting the installation media so easy. 🙂
8th November: There has been some limited 12.2 documentation around since the release of Exadata Express, but the “proper” 12.2 documentation was released yesterday. There are still some missing bits, like the install/upgrade manuals, which is not surprising as they are not necessary for Exadata Express or DBaaS.

So as far as I’m concerned, we have only just got a product that resembles an on-premise release now. The meaning of Cloud First will be judged by how long it takes from *now* for the on-premise release to drop. If it happens soon I will be in the “Cloud First has worked out OK” camp. If there is an extended period between now and the on-premise release, I will be switching my allegiance to the conspiracy theory camp. 🙂

Cheers

Tim…

PS. It’s possible there is still some work to put together conventional installation media. I have no knowledge of the internal processed at Oracle.

Oracle Public Cloud User Experience Issues

For some time I’ve been openly critical of the user experience (UX) of Oracle Public Cloud. Just to be clear what I mean by this…

I am not talking about the quality of the services that are delivered, or the underlying technologies being used. I’m talking about the day-to-day usage of the Oracle Public Cloud (OPC) interface. The web pages you use to administer this stuff.
I’m not talking about the SaaS offerings, like Oracle Fusion Cloud Applications. I have no experience of them, so I am not in a position to comment on them.

With that understood, I have some big issues with the UI/UX of Oracle Public Cloud. I have been providing feedback (briefings, webinars, direct feedback and private forum posts) for some time, but while there are some improvements, the experience of administering your services through the OPC web interface is far behind that provided by Amazon AWS and Microsoft Azure IMHO.

We recently had an ACED webinar and during the questions at the end I had a little rant about the user experience. Once that had ended, I wrote and email apologising to the presenter, but also listing a few of my gripes. I also reached out to the Oracle Applications User Experience team…

Yesterday I had a phone call with Jeremy Ashley about the situation and in the next couple of weeks I will hopefully be engaging with the UX team to discuss and demonstrate the issues I have.

Most of the problems I have are about wanting to follow a natural flow of tasks. Many aspects of the interface look like a developer has tried to expose the underlying tech, rather than asking how a user might want to interact with the service. The interface and the implementation do not have to match!

I was going to start a series of blog posts discussing the various UI/UX issues that annoy me, but I will probably hold back on that. Doing some constructive criticism directly to people that can make a difference is much better than me publicly throwing my toys out of the pram, but it’s not quite as fun. 🙂

Fingers crossed!

Cheers

Tim…

PS. I’ve been getting some stick from the guys at work about my telephone voice at the start of the call with Jeremy. I allegedly sounded like a cross between Hyacinth Bucket and Kenneth Williams. 🙂

A week in the cloud… (Just to clarify)

AWS A comment on yesterday’s post by Andy C makes me think I should clarify a couple of things I mentioned in yesterday’s post.

“Infrastructure as a Service (IaaS), not really what I consider the cloud.”

For *me* the definition of cloud must include some value-add in relation to ease of use. I’ve used IaaS on Azure, AWS and Oracle Cloud. In all cases I’m left to do the same administration stuff I had to when I was on a physical box or a VM on a local virtual machine. For *me* it only becomes cloud when I have Platform as a Service (PaaS) or Software as a Service (SaaS), where the administration is simplified greatly through tooling. IaaS is just another hosting provider. It’s not really cloud in *my* book. That’s not to say it’s not cool or useful. It’s just not cloud to *me*.

Notice the heavy use of *me* and *my*. This is not the law or even some text book definition. It’s just the way I feel about it, having used a number of hosting companies for business and personal use prior to “the cloud”. You are allowed to think differently, and certainly cloud providers do. 🙂

Note. I’m not discounting the ease of use afforded during provisioning and disposing of resources, but if you’ve worked with a proper virtual infrastructure you’ve had that for a long time. Once again, I’m not saying it’s not cool. I’m saying the day-to-day job as a system administrator or DBA is unchanged by IaaS.

“It’s a much lower spec box (memory, CPU, disk capacity), so really it’s more expensive.”

One of the things we notice when moving people from physical to virtual is they want a complete replica of their server, even if that server is mostly idle, using no memory and a fraction of the disk space it is allocated. One of the good points of virtual infrastructure is consolidation, which is not going to happen well if everyone insists on over-allocating resource they don’t use. OK, you’ll probably jump in with comments about memory ballooning, and thin provisioning, but you get where I’m coming from here.

The cloud providers keep their costs down and can make their money because of this consolidation, so it’s obvious you are not getting a “full server” unless you are willing to pay for dedicated resource.

When I got my dedicated server I significantly over-specced it, because I didn’t really known how much resource I needed, having only run the website on shared resource up to that point. In moving to AWS I now have 1/4 of the cores, 1/2 the memory and 1/10 of the disk space, but it costs approximately the same money. I’ve moved from bargain bucket dedicated hosting provider to world dominating cloud provider, so it’s not the fairest comparison, but the cloud is not cheaper for me. If my resource needs grow to the point where I would have maxed out the old dedicated server, the AWS costs would be significantly higher.

As I said yesterday, there are ways I can make the service cheaper once I confirm what resources I need, so maybe the final solution will actually be cheaper, but I don’t know that yet. The point is, there is the automatic assumption that the cloud is always cheaper and it’s just not true all the time. It comes with other benefits of course, but if cost is your prime metric, the cloud is not always the winner.

Conclusion

As I said in yesterday’s post, I’m really happy with the move so far. I like the additional flexibility, potential HA improvements in the case of hardware failure and the architectural options it has opened up. Having said that, I’m not blind to the fact the system administration is no simpler than it was with a dedicated server and it is a similar cost for less resource.

This is not meant to be provocative to either the cloud or anti-cloud zealots. It’s just an opinion. 🙂

Cheers

Tim…