Scalable Resilient Distribution of Drum Score Editor

AKA getting very cloudy out there! This is the first of a series of posts which will describe the adventures encountered while sticking our heads even further in the clouds.

This instalment is mostly Project Introduction & Background, rapidly followed by (which will be links once written):

Briefly, Drum Score Editor is a GUI app that installs locally on Windows, Mac OS X or Linux. It’s written in Java and pretty much lives the write once run (almost) anywhere dream, ok no tablets or phones as the industry pretty much needed a whole bunch of new challenges in that domain – not.

To get it to it’s users, Drum Score Editor is packaged into native installers for each platform (another process worthy of improvement and an article one day) and those installers are hosted on a bespoke website. So it’s not that simple, as there’s a free version which is very usable imho, and then with the application of a license key, it unlocks a bunch of productivity features.

To deliver this to it’s users a bespoke website has been written, as integrating with Mac, Windows, Ubuntu etc app stores is just a bridge too far, oh and Apple won’t let me host it on theirs as the optional license key is regarded as an in-app purchase and because it’s cross-platform it doesn’t use their technology so they believe I’m avoiding the 30% fees they charge. Oh and the Microsoft one just wanted ridiculous upfront costs. There’s probably another article all about this space waiting to be written.

So this website, on the face of it it’s fairly simply, you connect to it, you download the installer right from the home page, no tracking, no identity capture needed, no email spam afterwards, nada. Nothing complicated there, static installer images hosted on the website accessed from a (sort of) pretty html page.

But then there’s the making a financial contribution in exchange for a license, that’s where it gets not-so-simple. Integrations through oauth2 are needed to register a new account or sign in to an existing one. From there if the users wishes to acquire a new license we’re integrated with PayPal to collect the funds, and then when that’s done, encrypt a new license key by spawning some Java code which does all the complicated bits, returning the keys to stash in the users account. Oh, and just to be sure we’re good, everything’s behind an SSL cert (https FTW), which is also used to help protect the site when talking to the aforementioned authentication and payment sites.

So not quite so simple as bunging it in a simple call to AWS Elastic Beanstalk and hey presto. I didn’t mention AWS before, that’s the target cloudy environment chosen for it’s rich etc etc, it’s the first, biggest and most complete imho. We’re already a bit cloudy but it’s oh so last year and not as comprehensive a solution as offered by AWS, not that I’m sure we really need all those bells and whistles as it’s been going fine as a single web app on a VM I rent from a hosting provider on the internet for a few years now. Yes, single, so no resilience in the case of provider outages, no disaster recovery other than the fact I back up the database and email it’s contents to myself each day. Ahem, yes data protection, some of that too please.

Had a quick look at what it will take, and the first hurdle is my current single git repo containing the web app and the installer images is about 1GB in size. The AWS EBS experts will now be jumping up and down to say it’s too big, fix it! We will, that’s the first step in getting this web app some more professional attention. It’s a shame though as it breaks the model of a single repo for the whole app and it’s data. We’ll move the installer images to S3 and use CloudFront to serve the content more locally to the sites users.

Second phase is to shift the database out of the singe instance web app, so it can be accessed by multiple instances of the app. This is going to be trickier. Currently there’s a very effective Capistrano integration (seems I forget to say the web app is written in Ruby on Rails, talking to a MySQL database), which takes care of pushing updates to either a UAT or the Production website. Both of which are hosted on the same VM, by the same Apache2 instance configured with virtual servers. Yeah, not exactly a lot of separation there either, another thing that’ll be fixed by getting cloudier. I like to call the current config as “just good enough”, and the thinking man’s server consolidation (1990’s style).

Third phase has to be to move the main web app to EBS. There will be plenty challenges with this, hence wanting to separate out the two major changes above and make sure they’re working before this piece of heavy lifting. Just to finish this intro to the project, here’s a picture that tries to show the before and after for the whole shebang at a fairly high level.

Slide1

By the way, just as a footnote, when we’re done with this, we’ll look to see how the many tools and github repos which address the complexity in this space are progressing. Right now, I couldn’t find anything that meets the requirements, without a complete rearchitecture and rewrite of the web app. Feel free to comment away with recommendations, I’ll look at them all, honest!

Oh and p.p.s., continuous integration, there must be answers in there for this whole toolchain! Another future post.

Advertisements

One thought on “Scalable Resilient Distribution of Drum Score Editor

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s