[CentralOH] Python for Developing Enterprise Systems?

[Kenneth Wee]

Thanks to Thomas and Brian for the insightful advice, much appreciated.
Thanks to Jim for the relevant articles on obfuscation too.

I concur with many of the points raised and had deliberated on many of the
points myself too.


In regards to the inter-communication protocol. I've dabbled with libraries
like pysimplesoap and suds, especially the jurko-suds fork. I've used them
as a consumer/client of WSDL/SOAP services, but never as a server. Not sure
whether there is already something out there to be as a server.

I use jurko-suds for the ability to use green threads for "concurrency",
but suds is sometimes unable to parse the WSDL schema properly if it is
extended with `xmlns:s1="http://microsoft.com/wsdl/types/"`. Pysimplesoap
is usable here but I'm not sure how to tear it apart use with grequests yes.

Although I'm not sure about the equivalent in Java's ecosystem, I'm of the
assumption they already have mature libraries supporting it, both as server
and client.


With regards to concurrency, I've been using green threads through
grequests library to consume WSDL/SOAP services. The multiprocessing module
in python has an existing bug (i think it is one) which has not been fixed.
http://bugs.python.org/issue8296 http://bugs.python.org/issue9205
http://bugs.python.org/issue22393
I'm not too good at understanding and using the multiprocessing, so I gave
up on it for one project due to pressing deadlines.
As Thomas has said, "Threads are Java's life". I'm not sure if I were to
pull out python-celery + zeromq/rabbitmq as an alternative, it will
comparable with existing Java offerings.


With regards to my perception of tradeoffs that Thomas pointed out, one of
the concerns is raised by Brian, specifically to hiring and code clarity.
>From my anecdotal experience in hiring, it fits Brian's observation of
getting better quality programmers. If we're going to shift over to Java, I
have a feeling I'm going to have greater difficulties hiring people, and
the signal-to-noise ratio is going to be much lower.

Code maintenance with Python, to me, will be less of an effort with the
conciseness and less mistakes made if there are less code to type. If the
argument boils down to dev tools, code linters, and other conveniences of
differing IDEs, this slippery slope will go to no end.


With regards to obfuscation, I agree with the view about arms race and also
the discussion about the point of it all.
I've searched many sources, and has chanced by this
http://bits.citrusbyte.com/protecting-a-python-codebase/
Unfortunately, Investors are not that hard to convince. In addition, if the
end goal is going to be something autonomous, the fear of ending up like
the piracy rates of windows XP, and being tapped on by competitors, is
clawing on the decision-makers' nerves.
Perhaps the business model would need to be re-examined and Redhat's model
might prove to be a good starting point for consideration?


With regards to customer's expectation, of using a "familiarly safe and
proven" language, I'm not doing the sales, and even if I am, I'm not sure
the success rate of convincing when the other party's stakes are extremely
high on the purchasing decision.


The bigger discussion even before the language choice, is about having
one-language-to-rule-them-all being more efficient when moving developer
resources across different part of the projects (which in itself merits
more arguments about inefficiencies of context-switching of projects). It
is generally acknowledged that it will strain developers who have to pick
up a new language if we have multiple different projects in different
language for the SOA architecture.


The assessment about choices of available frameworks in each language to
fit our requirements is, at best, very fuzzy at the moment due to
insufficient information on the problem-solution fit.


I'm all for "using the best tool for the job", and have a preference
towards language pluralism. If needed, I'll even push for JVM languages
like Clojure and Scala. However, with the arguments above on hiring
talents, to current developer pool skills, to developer resource mobility
between projects, to customer confidence, it looks like a difficult
proposition on my part.

If it is going to be a single-language decision, then you all know my
biased preference. In spite of my bias, I still need to be pragmatic about
the decision to best serve the team in all the aspects of considerations.


Thanks to everyone again for the valuable advice.

On 23 May 2015 at 22:18, Brian Costlow <brian.costlow at gmail.com> wrote:

I'm with Thomas on a lot of these points.
>
> If you need SOAP, with Python, you will probably find yourself doing a lot
> of work on one or more of Python's SOAP libraries. The details are fuzzy as
> it's been 5 years or so, but the last time I did this, we were on a tight
> schedule without time to do that, so ended up using one library to create
> our endpoints and another for connecting to other endpoints to get around
> issues.
>
> The developer tradeoff. You fill find *more* Java developers. As an
> average, the Python pool will be *better* developers.
>
> As far as IP. If a smart programmer knows what your product does, she/he
> can reinvent it without looking at your code. If you are worried about your
> *customers* stealing from you, here's an anecdote:
>
> I used to work on software that was encrypted and hardware key protected
> PHP. In our North & South American, Western European, and Japanese markets,
> nobody would have made an extra copy anyways, because they wanted
> support/upgrades etc. Meanwhile, we did have rampant piracy in Russia and
> parts of Asia. That wasn't individual users, but rogue consulting firms
> that were selling and supporting cracked copies of the software. That only
> happened where the legal system wouldn't let us stop it. The encryption and
> keys were a big waste of time... and given what we were doing, we would
> have been better off using Perl or Python, but management forbid it because
> we could not 'protect the source code'.
>
> One advantage to Python over Java is clarity. You can write bad, hard to
> reason about code in either language. But in general, well written Python
> will be easier to read and reason about than well written Java. Which
> becomes important when someone who didn't write the original has to fix
> bugs or add functions (or even the person who did write it has to look at
> it a year later). But using other languages on the JVM can provide some of
> the same effect.
>
> On Sat, May 23, 2015 at 3:51 AM, Thomas Winningham <winningham at gmail.com>
> wrote:
>
> Having extensively messed with a lot of this, I have a few points but
>> others should chime in too.
>> I might lean towards Java actually, but maybe just barely.
>> - SOAP ... Python has it, but it is an aging set of libraries... Most
>> Python frameworks focus on REST. There are perhaps ways to bridge this gap,
>> like writing SOAP <-> REST adapters in Java only where needed, or some
>> other product that focuses on this very common need.
>> - Performance (maybe) .... Threads are Java's life ... But then again,
>> things like uWSGI can make Python concurrency astounding for web stuff if
>> you let it do the work. JVMs in theory are just "nicer." Pypy is used here
>> and there, experimentally, but uWSGI is indeed very cool. You can always
>> use C.
>> - Language ecosystem... You could for instance use Jython although it is
>> on 2.7 at the moment. Also there's Clojure (my current fav), Scala, JRuby,
>> Groovy and more. Maybe having a choice languages could be a benefit, I'm
>> not sure.
>> A lot of things you mention, however... it is kind of a wash. Python has
>> a nice rapid development with dynamic types, but Java's static types could
>> give you an extra level of assurance.
>> I guess you see a lot of tradeoffs which is perhaps why you're asking :P
>> I think the availability of people is getting to be the same, although
>> there are more Java people. Java people maybe worked with just one kind of
>> large project, whereas Python people may be more varied and wider in their
>> experiences.
>> A lot of corporate industry types may appreciate a Java stack, but then
>> again a Python stack may speak to some sense of agility. Both, like PHP,
>> allow for integration with native code.
>> As far as obfuscation goes, that's all an arms race. You can distribute
>> compiled versions of each language sure, but I've also seen a lot of
>> reverse engineering tools aimed at obfuscation schemes in just about any
>> language... My general political advice would be to focus on other
>> competitive advantages than your specific implementations in providing
>> value. I guess I see that all as a silly game technically, and a huge risk
>> legally and financially, but IANAL. I am too busy innovating than to treat
>> people as suspect ;p
>> Really probably anything other than PHP will be a breath of fresh air,
>> although I do understand PHP to have some neat modern cool things going on
>> these days. A lot of those innovations are copied from concepts in Java,
>> though. So are some of the cool things in Python!
>> Hope this helps! It is probably too opinionated. I do accept money for
>> this advice.
>> -t
>> Hi Pythonistas,
>>
>> TL;DR: For enterprise system development needs, is Python a viable option
>> versus Java? How can I convince a team with dominant number of Java-trained
>> engineers moving away from Php to pick Python over Java?
>>
>>
>> What we do:
>>
>> Our team is transitioning from targeting startup customers within the
>> telecommunications industry, towards enterprise customers with mature
>> custom systems.
>>
>> We currently build our web-based systems in a service-oriented
>> architecture (almost), and will be forsaking Php for either Java or Python
>> for future development. Furthermore, we might possibly be shifting to
>> shrink-wrapped systems as well.
>>
>> We are at a major turning point in deciding on scrapping what we have
>> built and coming up with a new maintainable system fit for enterprise
>> demands.
>>
>>
>> Non-technical Considerations:
>>
>> 1) Industry Bias (sales consideration)
>> Our new customers' (especially decision makers) tend to have preconceived
>> notions regarding the languages used for software development. It's a fight
>> between convincing them or yielding to their preference (which incurs
>> large costs).
>>
>> 2) Protecting I/P by obfuscation (self-preservation consideration)
>> The need for protecting our I/P when customers insist they need to keep
>> things local and secure. Which means they get access to code (source or
>> not) of the system being deployed, i.e. the cloud is not an option.
>>
>> 3) Availability of resource for hiring to build and maintain system
>>
>>
>> Technical-related Considerations:
>>
>> 1) Inter-communicating with existing enterprise systems
>> - WSDL seems to be really needed
>>
>> 2) Speed of report generation
>> - Multi-processing / Multi-threading capabilities
>>
>> 3) Development speed (agility)
>> - Availability and ease of use of libraries
>> - Language features
>> - Types of Frameworks that are capable enough to be used for enterprise
>> requirements
>>    -- e.g. spring, hibernate, J2ee VS Django, Web2py
>>
>> 4) Availability of development tools
>>    - Developer tools which enhance workflow
>>    - Testing frameworks
>>
>> 5) Code maintainability
>>
>> 6) Ease of deployment
>>
>> Given that this is a Python mailing list, I'm expecting more biased
>> responses. However, hopefully folks with experience in both languages could
>> discuss the merits of Java VS Python, specifically towards the well-being
>> (pain) of the team moving forward and consideration for bottom-line
>> (customer segment).
>>
>>
>> Thank you in advance,
>> Kenneth
>>
>> _______________________________________________
>> CentralOH mailing list
>> CentralOH at python.org
>> https://mail.python.org/mailman/listinfo/centraloh
>>
>>
>> _______________________________________________
>>
>>> CentralOH mailing list
>>
>>> CentralOH at python.org
>>
>>> https://mail.python.org/mailman/listinfo/centraloh
>>
>>
> _______________________________________________
>
>> CentralOH mailing list
>
>> CentralOH at python.org
>
>> https://mail.python.org/mailman/listinfo/centraloh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20150525/00c4adce/attachment-0001.html>