Does anyone care about enterprise application servers anymore?

A few years ago it seemed like everywhere you turned there was a vendor extolling the virtues of their enterprise application server. The message was very much “big is beautiful”. The more complicated the better. The more features the better. Fast forward to present time and is that message still the same?

In a recent conversation I was asked about my thoughts on this and my response was I don’t think these “do it all” application servers matter anymore. This post outlines my feelings on the matter.

Full disclosure

Because of my job I was forced to learn WebLogic, and I’ve always disliked it. I think it’s over-complicated, a pig to manage, and every quarter the list of vulnerabilities look like a horror show. Keep this in mind when reading the rest of this post. Basically, I’m saying this is my biased opinion and you don’t have to agree with me. I’m not throwing shade at any particular company. In my opinion, the mindset at the time was different to now, which resulted in similar products from multiple companies.

Also, it’s worth saying I’m not an application server guru, so that probably affects my views on the subject.

Third-party application vendors

The company I work for at the moment uses a lot of third party apps. From what I can see, the 3rd party application vendors that were previously looking to offer solutions on products like Websphere and WebLogic are quite happily getting rid of them in favour of more streamlined solutions. They are quite happy to forgo the additional features, or implement them with additional libraries in their code.

Maybe that’s just the application vendors I come into contact with. Maybe your experience is different. I would be interested to know, in case I’m totally off the mark here.

Containers

With the rise of containers we’ve become accustomed to small and lightweight pieces of infrastructure that focus on doing one thing well, rather than trying to be all things to all people.

I know you can run these enterprise application servers in containers and on Kubernetes, but it just feels like trying to force monoliths into containers. That’s not my idea of progress.

When I talk about lightweight, I’m not just thinking about the size of the footprint, but the complexity of it also.

Administration

The administration of the monoliths is too complicated. Given the choice of training up a new person on WebLogic or Tomcat, I know which I would pick.

Even after all these years, when we get an issue on a WebLogic server a piece of me dies because I know I’ll be rooting around for ages to get the answers. In comparison, Tomcat is so much simpler.

We go back to my definition of the size of the footprint again. The complexity of some of these products comes at a cost.

But what about product X?

I realise that some products still need these enterprise application servers. If you use a product that needs them, that’s fine. Continue doing so. I just wouldn’t be looking to buy new products that require that much investment in time and money. It’s just my opinion though.

Moving to the cloud

One of the things I’ve mentioned several times is the move to the cloud changes things significantly. To a certain extent, I don’t care about the underlying technology used by a cloud service. I just care that it meets my requirements. Does it perform well enough? Does it have the required availability? Does it come at a reasonable price? Is it really easy to administer, or preferably need no real administration? Does it support the programming language/framework I care about? At no point am I really thinking about the underlying tech.

If a cloud provider builds out there service using an enterprise application server, that’s fine. I just don’t want to pay those licensing fees, and I don’t want to see any of the management. I want the most streamlined experience I can get.

What do you think?

I’m really interested to know what you think. I come to this conversation with a lot of bias, so I understand if a lot of people don’t agree with me. Are you looking to simplify this layer of your infrastructure, or do you still lean on the side of “big is beautiful”?

Cheers

Tim…

Enterprise Linux Upgrade : It’s a Sorry State!

It’s 2017 and it’s still not possible to reliably upgrade an Enterprise Linux distribution between major versions!

At this point you are scrolling down to the comments to “educate me” about the redhat-upgrade-tool, because you read about it somewhere and you once heard someone successfully upgraded an installation on a lab machine. Unless you have an ultra vanilla starting point, you are going to end up with a mess that probably won’t boot. By the time you come to upgrade a “real server”, there have been years of changes and it is unlikely to resemble some pristine minimal installation.

I know your next comment is going to be something about the architectural changes brought in by project X and version Y in RHEL7, which is why it is all so hard. Stop now! You are boring me already! Is it an enterprise distribution or isn’t it? If it is, you should be able to upgrade it reliably!

Next up comes, “But you have to reinstall when you get new hardware!” I present to you virtual machines. Physical hardware upgrades with no need to reinstall the OS on the VM.

I can’t believe I’ve been using Linux for about 19 years and this is where we are at.

Cheers

Tim…

Cloud Control : 12.1.0.7 Plugin Patch

I applied some of the 12.1.0.7 plugin patches to our Cloud Control installation today. We already have Cloud Control 12.1.0.4 installed, so this was just a case of updating the plugins.

Here’s a quick overview of what I did.

  • Backup up everything! Database and file system.
  • Setup > Extensibility > Self Update
  • Download the latest versions of the plugins. The minimum you can really get away with is “Oracle Database 12.1.0.7”,  “Oracle Cloud Framework 12.1.0.2” and “Oracle Fusion Middleware 12.1.0.7”. The Cloud Framework plugin is a dependency for the FWM plugin. Obviously, grab the extra plugins if you need them…
  • Setup > Extensibility > Plugins
  • Do a “Deploy On > Management Server” for the plugins you’ve downloaded. These require OMS downtime, so you will be monitoring progress using “./emctl status oms -details” from the “$OMS_HOME/bin” directory.
  • Wait until it is all running again.
  • Do a “Deploy On > Management Agent” for the DB and FMW plugins on just the cloud control server. I wanted to know it was all fine on this server before pushing out the updates to the agents on the monitored hosts.
  • Convince yourself nothing weird is happening.
  • Do a “Deploy On > Management Agent” for the DB plugin on any monitored database severs. Where possible I did Dev environments in one pass. Test environments in a second pass, then Prod environments.
  • Do a “Deploy On > Management Agent” for the FMW plugin on any monitored WebLogic severs. Once again, Dev, Test, Prod.

The plugin deploys to the OMS are a bit slow, but the deploys to the agents are pretty quick. Numbers will vary depending on your kit.

I much prefer the plugin patches to the main Cloud Control OMS and Agent patches as we (the DBAs) don’t have root or sudo access on the servers, so when we do the full-on patches we end up swamping the sysadmins with requests to run “root.sh” scripts. We don’t have to do that for the plugin patches.

Cheers

Tim…

Enterprise Manager Cloud Control 12cR4 Production Upgrade

I’ve already written about the 12cR3 to 12cR4 upgrade here. I did a few run through’s at home to practice it and it all seemed good.

Setting The Scene

Just to set the scene, for our production environment we run Cloud Control in a VMware virtual machine, using Oracle Linux 6.5 as the guest OS. With that setup, we can use a simple installation (DB and OMS on the same VM) and use VMware to provide our failover, rather than having to worry about multiple OMS installations and any DB failover technology etc. If there’s one thing I’ve learned about Cloud Control, it’s Keep It Simple Stupid (KISS)! As far as our managed servers go, most of our databases and all our middle tier stuff runs on VMware and Oracle Linux too. We have a handful of things still hanging around on HP-UX and Solaris, which will hopefully be migrated soon…

Upgrade Attempt 1 : Non-Starter

Yesterday I started the upgrade of our production system. Pretty much straight out of the blocks I hit a road block. It didn’t like the agents running on our HP-UX servers. The upgrades of the HP-UX agents are so painful. Every time so far I’ve had to reinstall them. As a result, I didn’t bother to upgrade them last time and kept running with the previous version of the agents. The upgrade wouldn’t have anything to do with that, so I forgot about the Cloud Control upgrade and I spent yesterday attempting to upgrade the HP-UX agents to 12cR3, before I could attempt the 12cR4 Cloud Control upgrade.

As usual, the upgrade of the agents on HP-UX involved me uninstalling, removing all the targets, installing, discovering all the targets and setting up the backups etc. Not all of it is scripted yet, so it is an annoying and painful process. I’m not sure if other HP-UX users suffer this, but it seems pretty consistently bad for us. The sooner we get rid of these straggling HP-UX servers the better!

So this wasn’t so much a failure of the upgrade. It was really down to me being lazy and not bothering to upgrade some agents.

Fast forward to this morning and I was actually ready to start the upgrade. 🙂

Upgrade Attempt 2 : Success

With the 12cR3 agents in place on HP-UX, the upgrade ran past that step with no problems and on to the main body of the installation. The install and upgrade were textbook.

I’ve upgraded the agent on the cloud control server, but I’m not going to upgrade any of the other agents until I know things are working fine.

Happy days!

Cheers

Tim…