Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of
months of development, by the end of December we released a pilot
version of our pharo based solution.
The solution consists of a native mobile app (Android), with Pharo 2.0
servers, using Seaside for the web UI, Seaside-REST for the mobile app
API and Zinc Websockets to certain "live" features of the web. The
persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it
is a private solution for a multinational consumer goods company
operating in Argentina.
But I can comment on the numbers:
* The pilot will end in ~40 days
* It involves 50 mobile users of the Android app using it daily.
* An nginx frontend for static files and http proxying to the pharo app servers
* Two pharo images as servers, one for the web interface, and one for
the REST API. The image is the same, they work as two separate app
servers to make use of each server and for improved reliability (I
don't want the seaside failures, which has been none yet, to affect
the REST API).
* Everything running in DigitalOcean droplets based in NYC (they add
~180ms of latency from here but their price/value equations is
unmatched).
Some performance numbers:
* The Pharo server uptime has been no less than perfect, the first 10
days with uninterrupted uptime. Only shutdown to upgrade the image
(yesterday night).
* The load is minor, with peaks of ~30 concurrent mobile users during
a few "business" moments of the day, the server never passed 15% of
CPU use. The disk I/O is also small, but the database is small too
(growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000
mobile users. But some water must pass under the bridge before
thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info
I quit my Smalltalk full time job at InfOil (after 9 years of
employment) to dedicate 100% to my new company. So I'm betting big on
this. By now I'm the sole Smalltalk developer (devops?) of the
company. Time has never been more scarce than nowadays.
Why Pharo?
* Because it is the best open source Smalltalk ("inspired") out there.
* Because I have 10+ years of experience with Smalltalk I can't throw
away in the context of rapid prototyping and business domain modelling
(emphasis on this).
* It was a key advantage during the negotiations, we could show a
wireframed live app even before our competition prepared a PowerPoint
presentation.
The development process with Pharo has been rudimentary, only
Monticello packages and a couple of workspace scripts to provision new
images.
I still can't get my head around Metacello. But honestly I haven't
dedicated as much time as it needs to be learnt. Having used VAST
ENVY's ConfigurationMaps successfully in the past is a proof I can
learn Metacello.
During the last years at InfOil we were using git with Dolphin
Smalltalk, with CI after every git push to the main repo. This was
also linked with our issue tracking system, in order to know in which
build a certain issue was fixed. We used Dolphin's PAX's files (CVS
friendly), Gitlab, JetBrain's TeamCity and YouTrack
I'd like to do the same using Monticello's FileTree, BitBucket and
JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this.
My learning of Pharo tooling hasn't been straightforward, but maybe
because I'm old and spoiled with other Smalltalk dialects (VSE, VAST,
Dolphin).
I was managing the Android code (java) with git branching and merging
way before I learnt how to use Monticello. Managing the code (files)
was the only advantage of working with Eclipse/Java. Everything else
was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time
to set it up as I'd like, and by now this email is going to be all I
can share. After the pilot, we can talk about reporting a success
story for Pharo. I felt like this during the last week:
http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-last
Best regards,
Esteban A. Maringolo
CTO (aka DevOps), http://trentosur.com
