Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Enterprise Perl

by punkish (Priest)
on Aug 04, 2005 at 16:00 UTC ( #480895=perlmeditation: print w/ replies, xml ) Need Help??

Monks,

Yesterday I spent an incredibly frustrating day at work uninstalling and installing WebSphere. I am already shuddering at the thought of having to work with it further.

I do not understand specifically what Java/WebSphere and their ilk bring to my table that I can't do with Perl/CPAN/Catalyst/Apache/Perlmonks and for about $10000 and several Maalox less?

Then, a colleague tried to explain why I got that more than 1 GB worth of software installed through WebSphere. He said that as a "framework," it is supposed to give me all these components, all standardized, that I can call on to do all the little tasks that I would need to do in building a large application. Need security... use the security applet or EJB or whatever, need sessions, there you have it, need loggin, there you go, etc. (He didn't necessarily advocate all that, but he explained it)

Well, that makes sense, but I can still achieve the same thing via a standardized, single, authoritative copy of CPAN that everyone in my development team uses... kinda like (is it?) Morgan Stanley uses -- I remember a talk from OSCON 2003 titled something like "One Perl to Rule Them All" -- Morgan Stanley worldwide uses a single, canonical copy of CPAN available to everyone... that way everyone is using the same version of the same software everywhere.

Well, we can, however, marketing types are sold on "enterprise applications" backed by big, anonymous companies. They must be good because they cost a lot of money, and every other marketing type is talking about them.

Then, it strikes me (well, truthfully, I've always be aware of this, but it makes good storytelling) that Perl doesn't have marketing types. It has evangelists, and users, and support communities, but it doesn't have advertisements in Business 2.0, FastCompany, and Fortune, it doesn't have websites with Flash intros and no skip buttons, etc.

I was aware of P5EE, but that doesn't seem to be going anywhere. Searching on this site reveals two to three years old threads (P5EE - Perl 5 Enterprise Environment and P5EE ... get involved!) and even a post by the venerable tilly on why at least he doesn't want to get involved.

So, what am I asking here?

I guess, I am musing about other monks' thoughts about "Perl (5|6) Enterprise Environment (P5EE)", "Enterprise Perl Pods (EPP)", and "Perl Struts" or "Perl on Rails" or "Perl on Rollerblades." Do we need one? Why don't we have one? Maybe we have one but it is disguised like the proletariat!

I'll take your answers off the air.

--

when small people start casting long shadows, it is time to go to bed

Comment on Enterprise Perl
Re: Enterprise Perl
by coreolyn (Parson) on Aug 04, 2005 at 17:22 UTC

    I feel your pain! And have felt it for the last four years or so as I'm in a Websphere shop. I refuse to defend WebSphere as I think its a mockery of J2EE. However, when you have to scale applications that will run upwards of 5000 transactions/minute and share code and applications accross a hundred departments you quickly see where Perl just isn't the best tool for the job.

    I've always stuck my nose into every enterprise Perl discussion hoping to either think or discover an angle that would make it more palatable to large corporations beyond that of a batch/scripting language. At this point I'm realizing Perl does what it does. Inspires inovation, solves crises, and gives me an edge over other developers when the heat is on. I find I'm not looking to make Perl into what it isn't, but constantly looking for where I can take advantage of it as it is.

      However, when you have to scale applications that will run upwards of 5000 transactions/minute and share code and applications accross a hundred departments you quickly see where Perl just isn't the best tool for the job.

      Yes, "scalability" is the popular buzzword brought in to defend Java/WebSphere kinda stuff, but I don't buy it. First, I don't quickly see that Perl isn't the best tool for 5000 tpm. Application design, memory, hardware, network, CPU, etc. are all very important factors.

      If that is not the case, I say, show me what it is exactly unique about J2EE that allows 5k tpm that is missing from Perl. I say, show me why such an application can't be programmed in Perl.

      If it is a web-app, use Perl/mod_perl/fastcgi/persistent perl, whatever, buy 4 CPU Xeon processors or Sun Ultrasparc Surefire 6-cylinder servers, fill them up with 20 Gb ram each, put them on a fiber network, take away all other latencies, and then compare.

      But then, the talk has moved to hardware, and I am not interested in that. I am interested in Perl. What is it about Perl that makes inherently unsuitable for the kinds of things for which J2EE is suitable?

      For the life of me, I can't think of one thing!

      Maybe it is the marketing. Maybe it is the fragmented nature of P5EE frameworks. There is CGI::App, CGI::Prototype, Catalyst, Mason, etc. God knows how many I don't know of.

      However, when it comes to Ruby, everyone has only one word -- "Ruby on Rails." When talking about Python, every says "Zope." Now, perhaps us monktypes know better. But, perhaps we need to have others know better as well. Or, perhaps we need to tune our message so it can be carried on their waves... talk about things they can understand.

      Perhaps saying that TMTOWTDI is counter-productive. Perhaps saying TOOWTDI (..only one..) is better.

      Which is the point of my OP... perhaps, providing a single install with canonical, pristine, standardized, and sanitized version of most all the components one would use to create web-based or non-web-based applcations would be the way to go.

      --

      when small people start casting long shadows, it is time to go to bed

        Scaling to the demands of my work enviornment is far more than code performance. It's providing consitent interfaces, supporting ( consistent ) documentation, and a stable code base in spite of a high turn over of developers. ( Let's not forget buzzwords for sales and managers to throw around *sigh* ) While Perl can do all these things I have found very few Perl programmers that aren't out just to make something work. Their variable usage is generally that which only they can interpolate, and documentation a waste of time. Perl could be enterprise class but - oh I hate to say it - the hubris of the Perl users I have had to work with is the very thing that keeps it from general acceptance and distribution.

        ( I'm not even going to touch the lack of simple things like use strict and warnings outside the monestary.)

        But after several years thinking on this subject I wouldn't want to change Perl folk at all. (Which is what it would take to get perl in the enterprise - moreso than any changes to its codebase or delivery platform.) I think that the culture, more than the code, is the real appeal.

        update: Forgot support issues

        When push comes to shove in this enviornment the status of several hundred banks and who knows how many thousands of ATM's count on our production floor. A senior executive having to count on perlmonks.org or some obscure Perl consulting firm compared to knowing they can calling on someone like IBM or Oracle is an impossible perception to overcome. Even if IBM support is horrendous the fact is our exec can tell a concerned bank president - We've got IBM working on it. Let's face it saying, "Well we've put a post on Perlmonks" just isn't going to hack it in that situation.

        Damn.. got me out of my dark lurkers corner.. must get back the lights to bright! :)
        I vaguely remember a time when CGI.pm was thought to be "the way". Not sure if the word 'only' should be in the middle of that quote, but that's a pointless digression. Python and Ruby are quite new compared to Perl. In 5 years, I would bet that they too will have MTOWTDI.

        -Scott

        If it is a web-app, use Perl/mod_perl/fastcgi/persistent perl, whatever, buy 4 CPU Xeon processors or Sun Ultrasparc Surefire 6-cylinder servers, fill them up with 20 Gb ram each, put them on a fiber network, take away all other latencies, and then compare.
        Well, after such an investment in hardware, the $10000 you quote for Websphere isn't so bad.

        I've worked with Websphere, and, it being expensive software, it sucked. It sucked a lot. But buying a licence was a lot cheaper than developing something from Perl and CPAN. (CPAN standardized? Come again? If you throw out the crap modules, the joke modules, and the proof-of-concept modules, you're left with a bunch of decent modules, most of which were either not written with each other in mind, or are not thread-safe, don't deal with Unicode well, or make assumptions on the underlaying filesystem. Mind you, there are a lot of goodies on CPAN - but almost all modules on CPAN were written to do a specific task, and weren't written to be part of a large framework).

        What is it about Perl that makes inherently unsuitable for the kinds of things for which J2EE is suitable?
        Nothing, but you are comparing apples and oranges. Perl is a language. Websphere is an application providing a framework. And quite a different framework than a language plus a collection of modules random programmers uploaded on an archive site the past decade.

        But it's easy to proof Perl is suitable to do what Websphere and J2EE are providing: just write it, and upload it on CPAN.

      I am right now in the final stages of building a large distributed peice of software in perl for enterprise use. It will be issuing an estimated 24/7 average of about 200 transactions per second to a relational database, with peaks up to double that for short periods. It will be receiving data updates from 5,000+ machines in multiple datacenters to drive these transactions. The relational database itself will be holding 1-2 TB of data, a good third of which is constantly being recycled in a matter of days. Every last little peice of code (on the 5,000+ machines, and the central server, and the midlayer between them) involved is written in perl, with the exception of some small peices of code in database trigger functions that's written in sql. So far, it's working great. In some ways, perl is no different than C - it can do whatever you want, as long as you code it correctly to do so.
Re: Enterprise Perl
by spiritway (Vicar) on Aug 05, 2005 at 00:15 UTC

    I don't know, but it seems to me that "enterprise" anything is just asking for problems, as far as Open Source is concerned. Corporations have to look at their bottom lines, and this goes contrary to the spirit of Open Source. I don't see any good way around it.

    I've noticed, like you, that managers and others often avoid "Free" software. I think it's a result of a couple of factors. One is simply perceived value. If you don't charge for it, people don't think it's worth anything. The other factor seems to be accountability. If you've paid big bucks for something, you (theoretically) have some sort of claim in case things don't work. Of course with software, most of the time get nothing of the sort, but you don't find that out until you try to collect...

      I've noticed, like you, that managers and others often avoid "Free" software. I think it's a result of a couple of factors. One is simply perceived value. If you don't charge for it, people don't think it's worth anything. The other factor seems to be accountability. If you've paid big bucks for something, you (theoretically) have some sort of claim in case things don't work. Of course with software, most of the time get nothing of the sort, but you don't find that out until you try to collect...

      I have a different theory on this. Its related to how large company "enterprises" function. A manager who is responsible for the WebSphere contract controls a considerable budget and is perceived as being a powerful person. Even better that manager has virtually no responsibility for the delivered product, except if it is a success. If the product sucks then the vendor screwed up and the manager is off the hook (this is especially true if the source code on the vendor product is closed). If the product rocks then the manager is congratulated for a good job done. With free tools the manager has no large contract to manage, reducing their perceived power in the organisation and has no vendor to blame their problems on. Instead they and they alone are responsible for the success or failure of their project. Considering how little time managers tend to stay in their roles, and the potential loss of income for being held responsible for failure it is no wonder that most senior managers avoid technology whose failure can be laid at their door.

      In a lean and hungry company the id guess the rules are different, presiding over a large budget external vendor failure could result in serious problems for the company (such as bankruptcy) and the manager responsible will most likely be held to account for presiding over such a costly failure. Whereas a failure of a project whose only costs have been headcount and development time is most unlikely to result in serious problems for the company and thus the managers in firms like that are much more likely to take advantage of free solutions that provide them with low cost solutions.

      The basic issue is how the company holds those responsible for these decisions to account. In most large companies failure is almost never the responsibility of the senior managers involved (witness CEO's receiving massive payouts for being responsibile for serious losses in their companies), smaller companies without the protection of huge capitalisation and the cover of large organisations have to take a much more realistic approach.

      ---
      $world=~s/war/peace/g

Re: Enterprise Perl
by pg (Canon) on Aug 05, 2005 at 06:18 UTC

    Support is a big concern here. From an enterprise point of view, it is the right decision to buy support and to ensure that it is there when you need it. It is like buying insurance.

    Now change your viewpoint... you asked whether there was anything other languages/frameworks do that Perl cannot do. Let me ask a similar question from a different angle, what Perl does that the other languages/frameworks cannot do? That is simply not the way to prove anything or convience anyone.

    This is really not just a technical issue, thus P5EE as a techincal attempt will not seriously address any of the concerns.

Re: Enterprise Perl
by pernod (Chaplain) on Aug 05, 2005 at 06:34 UTC
    "Perl on Rollerblades."

    What brilliantly quirky name!

    pernod
    --
    Mischief. Mayhem. Soap.

Re: Enterprise Perl
by adrianh (Chancellor) on Aug 05, 2005 at 10:46 UTC
    I do not understand specifically what Java/WebSphere and their ilk bring to my table that I can't do with Perl/CPAN/Catalyst/Apache/Perlmonks and for about $10000 and several Maalox less?

    Support and a single point of contact / responsibility. Have a problem/question about WebSphere you call IBM. Have a problem with a framework built from 40 different CPAN modules you call?

    Of course this doesn't mean that Perl isn't used in the Enterprise. Lots of companies from Amazon to Barclays Bank rely on Perl for their day-to-day operations.

    I guess, I am musing about other monks' thoughts about "Perl (5|6) Enterprise Environment (P5EE)", "Enterprise Perl Pods (EPP)", and "Perl Struts" or "Perl on Rails" or "Perl on Rollerblades." Do we need one? Why don't we have one? Maybe we have one but it is disguised like the proletariat!

    We don't have one because most of us don't need one to get our job done.

    It doesn't get done by somebody else because it would be a heck of a lot of work. To have any affect on the people that prefer WebSphere it would have to be supported by an organisation that looks vaguely reliable. So it would need to be adopted by an IBM, or somebody would need to set up something like JBoss. Neither of them being terribly easy tasks.

      As one who has worked for IBM, yes, you can call, but I doubt they'll fix your problem in the next 3 releases ... or even listen to you if you are too small. Open source developers will. But again, this is a marketing/business issue, with little technical backing ... what can you do. The business types keep their jobs when they spend money. Open source is "too easy" and makes them somewhat obsolete!
        As one who has worked for IBM, yes, you can call, but I doubt they'll fix your problem in the next 3 releases ... or even listen to you if you are too small. Open source developers will

        That depends on the company and the open source developer. I've had some really excellent support responses from Sun and Oracle over the years. I've had open source developers being far too busy to fix the minor problems :-)

      Well Spikesource would like to be that single point of contact.

      Also lots of people outsource development to consulting companies, and then those consultants become that single point of contact.

        Well Spikesource would like to be that single point of contact.

        Yeah, it's an interesting company. There have certainly been situations in the past where something like their made-to-order software stacks would have been useful to me.

Re: Enterprise Perl
by punkish (Priest) on Aug 05, 2005 at 12:53 UTC
    So, the following is my summary of other monks' responses thus far as reasons for both impedance to the development of a P5EE as well as the acceptance of the otherwise pain-in-the-ass commercial frameworks such as WebSphere, BEA Weblogic, and their ilk --
    1. support from a single point of contact
    2. hubris of Perl users
    3. "we don't have one because we don't need one"
    4. scalability and performance
    5. Perl is a language, not a framework

    Nothing really earth-shattering. #2 is not about Perl, the language, at all, so let's leave it at that. #3 seems closely related to #2 -- it may be true that we, the Perl community, have not needed one else we would have created one. However, a lot of us also have noticed how other "communities" have developed such frameworks and we have also acknowledged how they have benefited from this.

    #4 is fairly bogus -- there are enough documented case-studies of Perl being used successfully in very high volume, high tpm, large dataset situations. Besides, if there are problematic applications from the perspective of performance and scalability, they can be solved with better design, and/or better hardware.

    That leaves me with #1 and #5. Yes, single point of contact can be a huge issue. "Now, all those who have successfully and satisfactorily called in BEA/IBM/Microsoft/Adobe/Oracle/<your favorite large software developer> for support, please raise your hands... no one?... I thought so..." I know I have not ever got satisfactory support... and they usually ask for a credit card up-front. On the other hand, most of my technical questions get answered on Perlmonks, and then some, within the hour. Yes, a few anonymonks throw in their quips here and there, a few tell me why using CamelCase is morally wrong, or something like that, but overall, I would rate Perlmonks as a prime example of how stellar technical (as well as philosophical) support should be... do-ers helping other do-ers.

    Now, we know that. How do we let the marketing-heads know that? Or the C-level people? (ever heard that? -- I heard a marketing-type use that term recently, and I was puzzled because I couldn't figure out for the life of me why he was talking about sea-level folks -- how would they be different from the mountain folks -- maybe he had just seen Steve Zissou -- then he told me that it was "C-level" -- CIO, CTO, CEO, etc. Unbelieveable, the crap these guys invent to keep themselves in business.) So, maybe marketing is an issue. Bombastic language, half of which means nothing (container managed persistence! WTF!)

    The last, and perhaps the most important in my view, issue that Perl is a language, not a framework. Well, if we did develop a framework with it, say "Perl on Rollerblades," so that a single click install gave the developer Perl, a bunch of proven, certified (!), helper modules such as DBI and its brethren, HTML::Template or Template and its brethren, Catalyst and/or its brethren, a good, graphical debugger (actually, I believe Catalyst already includes one), loggin, messaging, and session modules and their brethren, etc., that would be great.

    Which brings us back to #3 in reverse. We don't want one because we don't have one. Because, if we did want it badly, we would have had one by now.

    Btw, while Ruby is indeed younger than Perl, Python is of about the same vintage. Even in the realm of opensource, non-commercial, non-officially-supported, high price software, "Zope," "Ruby on Rails," and "JBoss" get more name recognition and mileage than CPAN does, in my knowledge.

    Update: Btw, I do realize that creating a framework is a darn difficult task, partly why it has not yet been done with Perl. That still has nothing to do with the points that: the world of Perl perhaps lacks well-publicized enterprise-ready frameworks; if they are there, they are not advertised well; there is nothing inherently specific to Perl, the language, that prevents creating such frameworks; and, not having such frameworks puts Perl as a language, as a community, as a way of doing things, at a distinct disadvantage to other such frameworks, especially in the "enterprise" (work|mind)space

    --

    when small people start casting long shadows, it is time to go to bed
      ...so that a single click install gave the developer Perl, a bunch of proven, certified (!), helper modules such as DBI and its brethren, HTML::Template or Template and...

      ActiveState already offers this service/product for free, minus the helper modules you list (which are easily added if the ppm repositories for each are known by the installer). They also offer 'premium' cost-model support options. How does the proposition differ more significantly?

      (This post is not an advocation of ActiveState's products or services.)

      --Solo

      --
      You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

        (This post is not an advocation of ActiveState's products or services.)

        No but it is interesting. I just suddenly thought of charging my company to install perl. They would realy look at it differently then, and oddly enough I think they would like it better if they had to pay for it.


        ___________
        Eric Hodges
        Yes, ActiveState does offer this kind of service. And, yes, they also offer a 'premium' cost-model. However, they don't offer a framework a la "Ruby on Rails" or "Zope," or, something that is at least advertised (propogandized) as a framework.

        The framework standardizes the helper modules. If enterprises were intelligent, they would realize that paying for it has nothing to do with its quality... knowing that the tools exist to create it would be enough (as I mentioned in my OP, Morgan Stanley seems to already do this via "one Perl to rule them all.")

        Sadly the enterprises are not intelligent. So, unless we don't mind not occupying in that mindspace, we need to create something that the enterprises think they want.

        --

        when small people start casting long shadows, it is time to go to bed
      Actually frameworks have been created in Perl. Mason, Catalyst and OpenInteract2 are a few that come to mind off of the top of my head.

      Also I have to say that I've seen good help come in emergencies from Oracle. And I know people who've received it from other vendors. The trick, though, is that you need to have paid good money up front to get good support later. And you need to have good technical people on the line to the support who are able to convince the first couple of layers to get someone useful on the line.

      #2 is not about Perl, the language, at all, so let's leave it at that. #3 seems closely related to #2 -- it may be true that we, the Perl community, have not needed one else we would have created one.

      It's not a Perl thing - it's an open source thing. People write code to scratch their particular itches. In the open source world frameworks tend to bubble up from the bottom, rather than be imposed from above.

      However, a lot of us also have noticed how other "communities" have developed such frameworks and we have also acknowledged how they have benefited from this.

      Like? I'm really not sure what kind of frameworks/communities you're talking about. In general anything with the label "enterprise" is something a company, rather than a community, has produced. It's a marketing term, not a technical term.

      If you're talking about things like Rails and Zope then Perl has many similar projects like Maypole, Bricolage, Catalyst, OpenInteract, etc.

      That leaves me with #1 and #5. Yes, single point of contact can be a huge issue. "Now, all those who have successfully and satisfactorily called in BEA/IBM/Microsoft/Adobe/Oracle/<your favorite large software developer> for support, please raise your hands... no one?... I thought so..."

      I've had some really excellent support responses from Oracle and Sun in the past ;-)

      But, as you say, the actual level of support is largely irrelevant. It's all about perception, and having somebody to blame.

      Btw, while Ruby is indeed younger than Perl, Python is of about the same vintage. Even in the realm of opensource, non-commercial, non-officially-supported, high price software, "Zope," "Ruby on Rails," and "JBoss" get more name recognition and mileage than CPAN does, in my knowledge.

      Now that's a much more interesting question. Although a more direct comparison would be why Rails and Zope gets more press than OpenInteract, Bricolage, Maypole, Catalyst, Krang, Bivio, AxKit, Mason, OpenFrame, etc.

      Some reasons of the top of my head:

      • TIMTOWTDI works against us. We have many different frameworks that work in interestingly different ways and so support is split. With Ruby almost everybody looks to Rails. With Python almost everybody looks to Zope.
      • Perl 5 works against us. Lots of people hate it. Sometimes with good reason.
      • Better marketing and presentation. Just compare rubyonrails.org with catalyst.perl.org.
Re: Enterprise Perl
by Anonymous Monk on Aug 05, 2005 at 17:04 UTC
    Over a year ago, I was asking the same thing. Read my question here.

    My team already had a Microsoft-based solution (CRM/e-business tools), but it was the result of incrementalism, and not all the parts were interconnected, and there was no way it could scale out much more without serious changes.

    We eventually dove in head first with Apache2/mod_perl/Linux and never looked back. Sure, we hit a couple bumps along the way, but with CPAN, PerlMonks and sheer PerlHackerism we're now almost ready to launch.

    We had to make use of what was available to us - and that meant Apache::ASP, Class::DBI, Apache::Session, XML::*, DBD::*, etc, etc, etc, - you get the drift. 90% of every Perl application is written already.

    Sure, 15 months ago when we started, the new MVC frameworks (a la Rails) were a novelty so we rolled our own, but it was pretty easy to do since everything else was already handled by other existing modules. I think we would have written our own MVC framework anyway because we needed it to do exactly what we wanted, and nothing else.

    Some things that we really would like to have include

    • distributed transactions (i.e. J2EE's JTA)
    • built-in WSDL-generation (Pod::WSDL is close! (but brand-new))
    • a more robust (and distributed) Publish/Subscribe model (Class::Publisher is close, but not distributed out-of-the-box)
    • a clearer path to system-wide event-handling (maybe with Event::Lib - seems good, needs more examples)
    • A Perl IDE with a built-in FileBrowser and simple check-in/out instead of a hackneyed "Project Manager" (cough-Komodo-cough-EPIC-cough)
    • Commit/Rollback event notifications (a la J2EE's JTA)
    • Robust and well-documented system messaging framework (a la J2EE's JMS)

    Fortunately these nice-to-haves would simply take time and humans thrown at them long enough to make them happen. They could even be fun projects to work on and release into CPAN.

    In the end, our project has succeeded and we're very happy with the way things have turned out. I look forward to maintaining and supporting our new platform because it Just Works.

Re: Enterprise Perl
by Anonymous Monk on Aug 06, 2005 at 14:23 UTC
    I was working with a dynamic/FOSS language/tools shop (won't say which) that is currently being moved to J2EE or .NET or some other heck for business reasons. I would give my left kidney (but not the right one) to be able to use Rails, Django, or mod_perl (anything) instead. Productivity is king... but we live in a world run by business people who don't believe it that! Find side projects I guess and keep your sanity.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://480895]
Approved by ww
Front-paged by Tanalis
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (8)
As of 2014-07-22 07:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (106 votes), past polls