Summary
Lessons learned along the bumpy road from Python noob to an open source geophysics web application, with a commercial web service front end.
Description
Software for applied geoscientists in the petroleum industry is usually expensive, hard to use, Windows or Linux only, and slow to evolve. Furthermore, it is almost always stridently proprietary and therefore black-box. Open source software is rare. There are few developers working outside of seismic processing and enterprise database development, and consequently there is very little in the web and mobile domain. Reconciling a commitment to open source with a desire to earn a good living is one of the great conundrums of software engineering. We have chosen a hybrid approach of open core (like OpendTect, which has proprietary add-ons) and software-as-a-service (like WordPress.org vs WordPress.com).
Open source back-end
Our open core is a Python web app for producing synthetic seismic models, in much the same way that the now-deprecated Google Image Charts API used to work: the user provides a URL, which contains all the relevant data, and a JPEG image generated by matplotlib is returned. Along with the image, we return some computed data about the model, such as the elastic properties of the rocks involved. The mode of the tool is described by "scripts", which for now reside on the server, but which we plan to allow users to provide as part of the API. Scripts have various parameters, such as the P-wave and S-wave velocities, and the bulk density of the rocks in the model, and it is these parameters that make up most of the data in the API call. Other parameters include the type and frequency of wavelet to use, and the computation method for the reflectivity (for example the Zoeppritz equations, or the Aki013Richards approximation). The app has no user interface to speak of, only a web API. It is licensed under the Apache 2 license and can be found on GitHub. We are running an instance of our app on a "T1.micro" Amazon EC2 instance running Ubuntu.
Proprietary front-end
The commercial, proprietary front end is a Python web app that lives in the Google App Engine walled garden. This app, which uses the Twitter Bootstrap framework, is serving at modelr.io and provides a user object in which a geoscientist can save rocks and scenarios consisting of a script and all its parameters. We chose App Engine for its strong infrastructure, good track record, and the easy availability of tools like the datastore, memcache, login, and so on. We also host support channels and materials through this front end, which has a very lightweight "demo" mode, and otherwise requires a $9/month subscription to use, handled by Stripe. This necessitated serving both the front and back ends over HTTPS, something we wanted to do anyway, because of industry mistrust of the cloud.
Summary
Some of the things we picked up along the way:
- We started with a strong need of our own, so had clear milestones from day 1.
- We left the project alone for months, but good documentation and GitHub meant this was not a problem.
- Sprinting with a professional developer at the start meant less thrashing later.
- The cloud landscape is exciting, but it's easy to be distracted by all the APIs. Keeping it simple is a constant struggle.
- Pushing through Xeno's paradox to get to a live, public-facing app took stamina and focus.
- There's nothing like having other users to get you to up your coding game.
We hope that by telling this story of the early days of a commercial scientific web application, built by a bunch of consulting scientists in Nova Scotia, not a tech startup in San Francisco, we can speed others along the path to creating a rich ecosystem of new geoscience tools and web APIs.