in reply to Re: Whither scripting? Will scripting wither?
in thread Whither scripting? Will scripting wither?

I agree with most of your points. I don't have enough experience with large management structures to say anything concrete about it, but it does sound plausible that most decisions in those environments aren't primarily based on technical considerations.

One thing that puzzles me though, is that you say that J2EE is a lot slower, yet more scalable than the perl/apache/mysql solution. I don't understand that at all. Surely the slowness implies that you need more boxes to reach the same level of service?

I find making mod_perl apps scalable a breeze: the standard Apache reverse-proxy setup combined with a replicated/clustered mysql setup means that:

  1. I can have any number of frontend webservers
  2. Those reverse-proxy to any number of mod_perl application servers
  3. Those communicate with any number of database servers
That means there is no single point of failure, and increasing scalability simply means adding another box to one of the tiers. Since mod_perl apparently outperforms J2EE, that means you need less machines for the middle tier.

For me, that says a LAMP setup can be both cheaper to start with, quicker to develop, and easier to scale.

It's entirely possible to set up this 3-tier model on a single machine, and I generally do so for my clients if they anticipate growth. Moving it to a multi-machine setup is a piece of cake, and doesn't require specialised perl skills. In my opinion, this means a LAMP setup is both extremely effective for small or starting businesses, but equally (cost)effective for large businesses.

Unless I miss something blindingly obvious, the only thing in favor of J2EE would be cheaper developers; but you'd need more of them (which means you need more managers), and they have to work harder, with more complex tools, to reach the same level of service.

  • Comment on Re^2: Whither scripting? Will scripting wither?

Replies are listed 'Best First'.
Re^3: Whither scripting? Will scripting wither?
by samizdat (Vicar) on Feb 01, 2006 at 20:27 UTC
    In our case, we have colocated machines in several cities, with DNS switching. It made the replication far more challenging, but we are free of the SPoF of one datacenter's Internet connection. We will eventually get to the point where we are willing to pay for two direct copper T-1's (or future equivalent) from different ATM entry points into one rack, but, until then, spreading servers out around the Net is the way to go.

    I wouldn't say that our development team is larger, although I'll agree that they have to work harder (yes, Java is Awful Damn Wordy!!!). Honestly, market demand hasn't made Java programmers (here) cheaper, but what it has done is made it easier to manage overseas teams.

    Again, I'll state my PoV: a great programmer can make a scripted / lightweight system run rings around a J2EE deployment in 95% of applications. However, the more intricate and interconnected the transaction requirements of the business rules, the more you need a well-defined definition layer that insulates you from your Real World. Yes, said great programmer can write one if needed, but the level of app I'm describing also has to be defended against requirement creep by dozens of stakeholders, and I don't know of many such programmers who will subject themselves to such a challenge willingly.

    Don Wilde
    "There's more than one level to any answer."
[reply]
      I initially started writing a rather rambling reply based on my private experiences, but I reconsidered. I just ran across this Alan Cox quote over on use.perl.org, which I think is pretty relevant: "Free software projects without good input filtering of ideas turn into bloated sludge". I believe that's language independent, and mostly a social/managerial issue.

      Let me just say that I agree with your remarks, even though I believe that many open source projects prove that it's not necessarily Java that makes managing international development teams successful.

      I do concede the point that Perl (or rather, CPAN) does not offer as mature a framework for enterprise apps as Java. I suspect that's an indicator of the general interest of the respective developer communities. I do still wonder whether that means there's really a controversy going on between Java and Perl. Maybe I'm just too far removed from the intersection point between your 95% and the remaining 5%, but apparently nobody on either side debates that 5% area, while the 95% part is (from the bottom up?) overwhelmingly filled by Perl. I generally get the impression that most of those Java vs Perl debates are not much more than turbulence in the 90% region, so to speak. Do you think technology decisions in that area are made mainly on the differences between Perl and Java? I wonder.

      I hope the above hasn't turned out to be a ramble after all...

[reply]
        I think the turbulence is mostly from the other side. What happens is that Java coders see Java as a 'one size fits all' solution (hmmm... 'our' side tends to also) and they make attempts to deploy projects in J2EE that should be done in Perl or PHP. Management goes along, because "nobody ever got fired for suggesting Java", and the project bites a big one. Our side laughs, but the damage is done. Company has a whole bunch of Java coders sitting around burning capital. I guess that's the big problem.

        Don Wilde
        "There's more than one level to any answer."
[reply]

In Section Meditations