The Failure Free Void
The Failure Free Void
Join the DZone community and get the full member experience.Join For Free
Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.
One of the great things about open source is that, since there is no deadline, and there is no one to run out of money, you can never really call anything a failure. Right? I mean, like the Axis team, who spent a decade trying to make it possible to wrap access to a web service in XML, you can just keep doing the phoenix by adding another number to your project name. Surely, the age of distributed computing that was sought first with the rigid, nerdy nonsense of CORBA, and then promised when EJB was trotted out, must be called for time now, and finally be given, not so much a toe tag, as a drooling bib for excessive development failing to result in advancement past infantilism. The idea that Java was going to finally make weight with 5 and then 6 is starting to look, even by the current (absurd) measures of hype, laughably improbable.
I was reading some documentation the other day about installing Atlassian products. It goes to some pains to explain that you cannot deploy more than one Atlassian product from the same container. Oh, and if you were planning to use a Mac, better not since the Mac JDK is not supported. Finally, to get the issue tracking system JIRA installed, you ought put aside a day or so. You know, to make users, setup a database, get all your launch scripts working, etc. No wonder people do get kind of delirious when they hear about the cloud.
But seriously, do we need to have data centers running 24×7 just because software deploy and config utterly refuses to grow up?? I upgraded tomcat on my mac mini server 2 days ago. From bloody 7.0.24 to 7.0.32. It was so stupid. Usually, that would be a really quick operation, but on the mini, you have to have a plist file to get launchctl to load tomcat. You are probably going to keep that in the tomcat dir. So once you symlink the new version, that‘s gone. Oh, and my JENKINS_HOME was being set in catalina.sh. Then there was the port mapping in server.xml (to 8081) and the connection pool. Finally, there‘s the mysql driver I left lying around in lib. Wait, I forgot, the .sh files had to be chmod‘ed. And the dir and symlink had to be chown‘ed.
Wow, I think maybe IT has to draft and train special therapists. I definitely think my aversion to nerds has developed into a full-blown, knee-jerk autoimmune response at this point. I mean, when things like this upgrade happen, I just start thinking ‘wait, these nerdy little thumbsuckers wean themselves on repeat viewings of life in make believe worlds where technology has mastered everything, and then they watch a few decades go by and think it makes perfect sense for someone climbing a few builds up a release chain, to run around fetching stuff for hours.‘
Here are a few ideas:
- so much open source is apache, couldn‘t the apache community get projects to adopt a configuration spec that would guarantee something where as each customization is wrought, the system knows it has been changed and subsequent upgrades could easily coalesce prior changes?
- of course, in the spirit of the original impulse of this post, haven‘t we proved with messes like this that distribution requires modularization? why is it not the case that when the server is installed, its coconspirators are installed as well (e.g. the connection pool) and each thing can have its code refreshed without blowing some uninventoried agents to smithereens?
- maybe it‘s time for declarative configuration, e.g. the combination of a DSL on the write side and a simple output language that can be run on any instance of something that would show all the things that are required and what was provided
An adage that has been around programming for a long time is ‘frameworks promise to do something, given answers to a few required questions.‘ This is the ‘hollywood principle‘ that Spring reduced to warm spit (promised rant coming on why DI is bad). Yet we don‘t apply the same thinking to one of the most basic aspects of computing; configuration.
Of course, along this path, we can find our way back to the core conundrum of open: we have to have the power to customize everything, but we can‘t be bothered to make it possible to reach basic operation without mass tinkering. There is less config in the Apple world because you aren‘t standing up empty boxes on one of 50 supported OS distros, serving your content into one of a bevy of bug ridden browsers. It would be great if someone were ready to offer the best of both worlds. Meantime, I think it‘s clear you‘re never going to be able to install JIRA (one of the most successful ticketing systems) without hours of tinkering, yet a teen can get an app into the app store that people all over the world can download and use.
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.