Where's the LCDS Love?

| 6 Comments
Why do you think that many enterprise Flex developers don't use LiveCycle Data Services?

LCDS.jpg
Someone recently asked me why I thought the take-up of LiveCycle Data Services among developers isn't more, um enthusiastic. Unlike almost any other development tool I've used, I don't recall hearing anyone complaining about the level of functionality offered by LCDS. That's certainly to the credit of the product managers and development team at Adobe, but exactly why isn't such a powerful tool more popular in the developer community?

It's certainly a difficult question and I wouldn't dare profess to have a definitive answer. I've therefore decided to share my thoughts while humbly asking for yours. You never know, maybe someone at Adobe will read this and take note.

Keep in mind that all I have to go on are conversations with developers and from reading blogs, so definitely consider these musings "non-scientific" and loaded with lots of hyperbole (the spice that makes blogging fun).

Here's my list:

Cost - a.k.a. "And here I was hoping to retire some day"

Dare I go so far as to say that cost is the number one stated reason that people stay away from LiveCycle Data Services? 

Everybody loves a free ride, but developing a set of tools as complex as LCDS requires a highly-skilled team (i.e. "it's astronomically expensive"). To recoup that cost usually means one of two things: sell a large volume of licenses or charge a lot for a few. Frankly, this question is way outside my realm of expertise: how exactly do you price something with so much undeniable value but that is very costly to create and maintain?

Some well-respected voices in the Flex developer community have gone out of their way to express their unhappiness with the LCDS pricing model. They want to use LCDS but in some cases can't because their customers simply can't afford it. If developers know/assume that their clients can't or won't pay for LCDS, they won't promote it and likely won't even bother learning how to use it (which can contribute to my second point below.)

Ignorance - a.k.a. "L. Seedy Hess... Who dat?"

This is, to me, the number one unstated reason. (Admittedly, that I hold this opinion may just be a symptom of my own prejudices.) Some developers simply don't understand the benefits of using AMF and remoting, etc. (this point can therefore apply to both LCDS and BlazeDS) They understand and trust SOAP and XML and the simplicity of REST-like web services, so they default to WebService and HttpService calls over LCDS. Consequently, their apps end up architected a lot like "standard" web apps, which can be all fine and good, up to a point.

If you're reading this and either a) don't know anything about the benefits of LCDS or b) don't see a benefit to using a binary protocol for streaming data to your Flex client, please check out James Ward's eye-opening Flex data transfer benchmark tool, for starters.

Intimidation - a.k.a. "Fear of the nuclear option"

LCDS has a certain "only the big boys use it" reputation and therefore, some developers nervously back away from any mention of it. I call this visceral and perhaps irrational uneasiness "fear of the nuclear option". 

This point also applies to LiveCycle in general: many people just don't understand what it really is, so in their psyche it remains in the category of things best left to the rarified air of Olympus (i.e. "code of the gods"). Perhaps that perception is something that Adobe could help with.

Habit - a.k.a. "I like wearing what's left of my lucky gym shorts"

Some developers come from a more "static" web development background. They are used to and enjoy writing pages built with HTML forms (or hyperlinks containing URL-encoded parameters) and submitting data to a server that builds and returns more HTML (e.g. JSPs, PERL, ASPs). Some of these people are perfectly happy with the limitations of a synchronous, more "old-school" web application development approach (i.e. build, render, submit, build, render, submit). Others prefer to simulate real-time behaviours using an AJAX framework. Whatever the reason, they see no pressing need for (quasi) real-time data updates and a strongly-typed object model on the client side that mirrors the one on the server side.

It's Overkill - a.k.a. "Bring a nuke to a pillow fight"

In some cases, developers do want the speed of binary data transfer and the convenience of sharing a strongly-typed data model between client and server code but simply don't need the scalability and push capabilities of LCDS. Those developers will often stick to BlazeDS because sometimes, polling is good enough. You really have to analyze what your client's needs are before making these important decisions. I've probably chosen LCDS over BlazeDS (easy call) in certain situations because a customer is using LiveCycle and already has a license for LCDS whereas I might have otherwise settled for using Blaze. As with anything else in life, the decision becomes a little more difficult when there is an additional cost attached to it.

Please Weigh In!

As I said earlier, I have no answers, only vague impressions built on whispers and (sometimes) vicious innuendo. I'd therefore love to hear why you think that many Flex developers don't use LCDS.

If LCDS interests you and you haven't heard, I suggest you check out this session on what's coming next for LCDS, including support for .NET on the back end and HTML/JavaScript, Java (e.g. Android) and iOS on the client-side. It's very exciting stuff, if you're into that kind of thing.

Thanks for dropping by!

6 Comments

Without a doubt cost is the #1 issue. I use BlazeDS everywhere as SOAP is just too slow if you're pushing more data than a weather report IMO. I would love to make better use of the tools available for it and might spend some time "seeing for myself" what it can do but I don't even think they offer the developer version anymore and I certainly don't have the 30K (or whatever they charge for it these days) laying around in my change jar. I've looked at in the past and downloaded the trials etc. but I always ended up saying... Meh.

I don't currently have to much need for messaging so I don't need the NIO channels for that. I would love to get some the Data management stuff but again, it's not worth the price of admission. I can build what I need or already have server-side and get similar functionality. If they won't knock the price down, then they could take some of the functionality and bundle it as a "pay-for" addon to BlazeDS. They might find some middle ground that doesn't choke small businesses and consulting developers out of their market.

Cost, pure and simple. It could be *the bee's knees* for all I care, but it's a half developer-year in cost (or whatever). You could build something much more tailored to your requirements over (say) long polling with the free Railo/BlazeDS stack in much less time than that.

Second though, and maybe created by the huge cost, is the 'nuke' factor - it's only ever used by (for instance) Morgen Stanley who need sub-hundred milliseconds responses and updates to thousands of online users. Hardly anyone ever needs that. Certainly polling every few tens of seconds is good enough for most people, and conflicts can be handled with a simple server-side lock. So why get LCDS ?

Just cost. I would have used it to good effect on the last three projects if only the client could afford the fee. I want to be able to use it so often, just can't.

Shame.

glenn
tinylion uk

cost. hands down.

Thanks for your comment, Chris.

I agree (from painful experience) that using web services to shuttle XML data back and forth to a Flex app doesn't scale well as data size grows. Though the Flex API makes developing such solutions embarrassingly easy, you just can't get around the fundamental nature of your data: the larger your data gets the more sense binary makes.

If price is indeed a big disincentive to using LCDS, I'm curious as to where the pricing "sweet spot" lies where the increased take-up of a less-expensive LCDS would lead to more profit overall. Are we talking about dropping a digit or just a marginal decrease in price?

If they were to do a review of their pricing model, one other thing that Adobe might consider changing or clarifying is the "per core" pricing model that seems to cause some consternation among many people.

Taylor,

I agree that Flex makes the simple XML data solution "embarrassingly easy" but at the same time they still don't support WSDL inheritance etc. which has caused much pain in transfer of data from other network elements that do (you have to flatten the data yourself). I think for those of us who, as Tom pointed out don't need a gazillion messages per second processing perfection, just want the simple AMF data functionality and tooling to simplify paging and basic client-server activity we've become accustomed to in other environments (C, C++, pick your favorite language here ;-) LCDS is way out there from a pricing standpoint.

At the end of the day I've got to produce cost effective solutions that don't shock my employer or our customers. Especially when you throw the "per CPU" nonsense into the mix. I've paid many thousands of dollars to Adobe for the "tools" to produce the product (Creative Suite). They want me to pay tens of thousands of dollars more to deliver it on LCDS??? Shame on them.

Many developers have the skills. Many small companies could benefit from them. However there are no small businesses (or developers) that can afford to pay for the benefits of the product.. thanks to Adobe's pricing. LCDS should be carved up into the MANY arenas that it serves. Make it reasonable for a developer or company to consider it as a viable means to an end rather than an "enterprise solution for those who can afford it". Believe me, everything they have done has been done before in other languages, environments and networks. It's not rocket science as they would have you believe. If I'm not mistaken Farata Systems has written their own NIO channel that does much of the messaging magic that LCDS provides. All of this stuff has been available for decades in other languages.

The price point is in the tooling. Adobe has proven to be leader in that. They have server products that provide value for those who need them. For the little guy, Adobe is prohibitive in it's server products but I have to give them thumbs up for at least open sourcing the Flex framework (due to pressure from folks like Laszlo). Hero shows some promise for the mobile market but as usual, they are WAY behind the rest of the crowd...

Leave a comment



About this Entry

This page contains a blog entry by Taylor Bastien published on November 8, 2010 5:00 PM AD.

Flex, Flash and Spock... What's Not To Love at MAX 2010? was the previous entry in this blog.

Sony Hearts Robots, Boosts Android is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.