In Johannes Brodwall’s Blog, he asks “Why does so much enterprise commercial software suck?”. In it, he mentions that his project migrated off of WebSphere and onto Jetty and regrets that his project didn’t migrate soon. The money quote:
But WebSphere is just the most blatant example of software that gives you nothing, gets in the way of a lean process stream, yet costs a lot of dough.
I can hardly agree with this statement. Is WebSphere Application Server expensive? Sure. Does it have a steep learning curve? Yup.
But,
Does it do the job competently and reliably? Yes. Does it actually do everything listed in its marketing slides? Yup. Does it perform? In 6.1 IBM seems to think so. Can you automate the entire deployment process? Yes.
Bad software hurts you in an insidious way: It eats up the time of every developer a little at a time
Agreed. And I believe that the general clunkiness of the Integrated Development Environments that IBM provides is likely what Johannes is referring to. WID/RAD builds still take far too much time than they should, random errors appear and disappear and the UI does freeze needlessly, leading to death by ‘…a thousand pinpricks’. What I don’t quite understand is why his project didn’t evaluate using a better IDE for J2EE development. The WAS server is a reliable workhorse, why throw the baby out with the bath water?
Bad software hurts you in an insidious way: It eats up the time of every developer a little at a time. Instead of testing your changes with a one second unit test, you test your changes with a five minute deployment cycle. Instead of rolling out a new version to a controlled environment with a command in 30 seconds, you schedule a deploy task that the product expert will perform in a few hours.
This experience with a long deployment cycle isn’t really valid. You can script all of this stuff through ant tasks and JUnit cases. There’s no reason (other than the assumed process of the company in question) why an admin would be required to spend hours installing an EAR.
So when managers ask why a project is late, developers feel personally guilty. And it’s a poor craftsman who blames his tool, no?
I’d have to say its the smart craftsman who understands his tool and the time it takes to actually accomplish the task. It’s also the smart developer who comes clean and lets his project manager know when the plan may slip. This seems like more of a process/estimation problem that something caused explicitly by the software. If this was the first project on the WebSphere platform, I would assume a good project manager would build in contingencies for skilling up and learning.
And from the comments:
Hi, Space Monkey.
We either discontinued or replaced all features not included in a web server. Briefly: EJBs we stopped using (thank god for that!); for connection pooling we first used the pool that came with Oracle, and then switched to c3p0; for failover and loadbalancing, we use our expensive switches which already has this build in; for transaction monitoring, we use Spring; we also rolled our own message service implementation (much simpler than JMS, but a drop-in replacement for our use).
Yowza, it looks to me like a ton of work went into reproducing the capabilities that WebSphere provided ‘for free’. Rolling your own message service implementation? Thats not a path I’d want to go down any time soon. Also, what happens to this system two three years down the road? All these multiple components, multiple vendors. They are all going to point the finger at each other when production goes down and Johannes is left holding the ball. I can appreciate the technical marvel that went into replacing WebSphere, but there’s also large questions of support, documentation and skillset that have to be answered.
So. Does Enterprise software suck? I believe like anything in life, its about costs versus benefits. What is most important to the project? Reliability that the vendor will be in business 5 years down the road? Exploiting the latest in Web 2.0 functionality? Fast development cycles? Documentation? Throw-away or 25+ year expected life? Companies need to try to look down the pipeline and find something that will support what they want to do.
Enterprise software tries to be all things to everyone, so it can come up short. Does it necessarily suck? No.
Hi, Dan
It’s interesting to read your take on my post. It seems like I a haven’t done a very good job of conveying my points, though.
“Does it do the job competently and reliably? Yes. Does it actually do everything listed in its marketing slides? Yup. Does it perform? In 6.1 IBM seems to think so.”
My experience is “no”, “no” and “no” to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we’re just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems.
“This experience with a long deployment cycle isn’t really valid. You can script all of this stuff through ant tasks and JUnit cases.”
Again: We tried, used a lot of money, and ultimately found we didn’t archive a satisfying result. And you’re right in that you *can* write JUnit tests that use WebSphere. However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. With Jetty we get 10-30 seconds one-click turn around on tests.
“Rolling your own message service implementation? Thats not a path I’d want to go down any time soon. Also, what happens to this system two three years down the road?”
We have been about five developers actively maintaining this implementation from different parts of the organization. However, I would not recommend the same approach under all circumstances. In our case, we were controlling the process on both ends of the queue, we had a very simple scenario, so we didn’t need the full JMS capabilities, and we found that the transactional model of Java EE didn’t mesh well with our problem.
My real point is this: In 2008, there is nothing that you get from an app server that you can’t get better and cheaper with an open source solution. We rolled our own message service, but you could use ActiveMQ. Connection pooling is provided by c3p0 or dbcp. CTM is provided by Spring. Servlets by Jetty.
In our experience, it took a lot less work to put these tools together (Maven is key here!) than to get WebSphere stable and usable.
When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: “What if you got it for free?”, they just shake their heads. If I say “What if you got free support as well?” they start considering it.
What about you, Dan: If it was your person loss or gain, would you still use WebSphere? Is danzrobok.com running on WebSphere? Why not?
Hi Johannes,
“My experience is “no”, “no” and “no” to all of these questions. We have burned a lot of money on consulting and training services from IBM, and we were never able to master our servers. Maybe we’re just too stupid for WebSphere. Luckily, everybody master the standalone Java server with Jetty with no problems.”
I guess the question that bares asking is what was the background of the developers on the project? If you were trying to skill up people on J2EE for the first time, I can understand the types of problems you are describing. WebSphere can be overwhelming if you don’t have the experience to know what to look for and where it is.
I can also believe that developers who were Java strong took to a non-J2EE solution faster because its what they already knew, thus you leveraged the skill of your resources on a technology they understood. Again, this doesn’t condemn WebSphere.
“However, we never were able to write unit tests that *start up* WebSphere and *deploys* our application into it. ”
Again, I know that these features do exist in WebSphere. A cursory google search turned up some articles on the subject. I don’t know which version of WebSphere you were using so maybe it didn’t exist then.
(http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.etools.wrd.freeform.doc/topics/cwrdrapid.html)
“My real point is this: In 2008, there is nothing that you get from an app server that you can’t get better and cheaper with an open source solution.”
This is a bit tongue-in-cheek but what you can’t get from the open source community are the things that a single vendor solution can provide. Anyway, I can actually partially agree with your statement in the sense that as these open source system mature, they begin to commoditize the markets they are in. What keeps companies like IBM in business is staying ahead of this curve via Business Integration products that build upon a solid base of WebSphere and basically “value-add” the core server.
That being said, I’m not a specialist in OSS servers so you may be right. But I still think that a WebSphere server is at minimum equivalent to them.
“When I ask WebSphere proficient developers in my company whether they would use WebSphere if it was their personal project, they just laugh at me. If I said: “What if you got it for free?”, they just shake their heads.”
Well I think it depends on the context of personal project. If you were asking if they’d go home and code up a few EJB’s to share photos on the internet, thats not the same as trying to integrate a business in a highly available manner. If you wanted me to write up something with five 9’s support, yeah, I’d probably take WebSphere and leverage the clustering capabilities.
“What about you, Dan: If it was your person loss or gain, would you still use WebSphere?”
See, I already make that statement every day by being a WebSphere consultant. I’m accountable to my clients to provide systems that meet their business and technical needs. If I don’t create a system that can live up to the hype, it’s my reputation that gets tarnished, not IBM’s.
“Is danzrobok.com running on WebSphere? Why not?”
Because I’m cheap and this bad boy is share hosted :-).
Anyway Johannes, I do enjoy hearing about the other options in the field and I’m by no means a zealot to IBM software. I think that you found the right solution for your business problem and skill set. I just think that WebSphere could also have been a success for you.
I have the same experience as Johannes. I know most of the ins and outs of WebSphere, and it is more of an obstacle than a tool in _most cases_. It just adds complexity and reduces developer efficiency, and in most cases it’s not necessary. And the words “rapid” and “WebSphere” just don’t fit together. Sure you can automate the building and deployment processes with it, but not _nearly_ as easy and elegant as with for instance Jetty. Believe me, I fought too many battles in that area… Oh, by the way, I’m a WebSphere consultant as well.
Hi Nils-h,
I’m curious if your poor experiences are more focused on the tooling for WebSphere or the runtime itself? I’ve opened tons of problem reports on the tools, but rarely do I encounter an honest WAS PMR.
You’re right, it’s not so much about the “runtime” (although I have had some seriously funny bug encounters there as well, e.g. session values leaking between users, exception swallowing etc). But both you and I know that WebSphere is just as much about the tooling than the app server itself, so you can’t just ignore that fact. And I still believe that in most cases, you would be better off using “lightweight” alternatives.
I don’t understand why the development process suddenly gets all nice and jolly by replacing appserver X with appserver Y – or even homegrown appserverish Z.
Although this Z-variant must have been fun to bring forward and if this open source-tooling based appserver-killer installation is something that has general applicability to the java-world then I am sure everyone would be just as happy and jolly. When the clientbase grows from 1 to a bit more than 1 I might pay attention.
In my organization the appserver choice is not that big a deal – I still don’t see why deployment cycles for several hours can have that much with the choice of appserver to do, as the claim “you schedule a deploy task that the product expert will perform in a few hours” in the original blog states. Don’t understand it.
http://www4.java.no/javazone/2006/show.do%3Fpage=92&articleid=4433.1.html
I’m gonna lean on Eric Schmidt’s wisdom here…Enterprise customers will pay for two critical features: security & quality of service.
With Enterprise software, you vote with your wallet and can sue someone if a guaranteed service doesn’t work per service level agreement or compromises security. Having someone to sue gives enterprise customers a level of security (however misguided, it’s reality) that they do not get with pure open source projects. Also, you can pay for maintenance and extended support. How many great open source projects go the way of the wind because the lead developer decided to move on and no one took up the reins? You rarely see this with code that still has a guaranteed revenue stream. Those are the key differences I’ve noticed: security, QoS, maintenance.
There are great developers out there who do it for the love of code and share their code openly, knowing that sharing will lead to more gains more quickly than proprietary, closed approaches. Thank God for them, without something to read, our state of the art would be even more retarded than it is today. Even traditional closed source shops have learned this and have trusted partners to gain more resource.
Anyway, obviously there are other products that are easier to use out there and more reasons than we can divine about how and why people make the choices they do. Ultimately, my answer is to agree with Dan on this…no, not all Enterprise software sucks…the ones that do go out of business. Are there open source projects that suck? Certainly. But ultimately the hope that keeps us going are the successes: Firefox, Linux, UNIX…in the proprietary arena: zSeries, iPod, and yes, even Windows.
> I’ve opened tons of problem reports on the tools, but rarely do I encounter an honest WAS PMR.
For what it’s worth, we have.