To begin with, some background Units of Sound is a online port of an existing windows native program, and currently has an install base of around 5000 users all in the UK. To allow expansion to other countries and other platforms as well as to out run limitations with the old program (written in a non longer supported language) I am helping move this program to a Flex application which will be capable of running entirely in browser.
Architecture in my mind is what drives the majority of high level decisions including ‘do we even need our own server?’ this sounds like an obvious question but after some thought about the operation of the program i found that 95% of it was statically served and run entirely in the client.
The KISS principle is something I think about a lot when undertaking tasks of this nature. The UOS team is made up of two developers and in all likelihood will never be made up of any more, once written the program will change very little, there will be the bare minimum of documentation and the scale will most likely never top 30-40K users. Bearing this in mind its more important that bugs can be found easily, code can be stopped and stepped through and that what each function and section is trying to achieve is obvious.
My latest conundrum comes the previously mentioned question ‘Do we even need our own server?’ Flex is a very powerful language, it allows us to make http calls and use other third party SaaS type API’s E.G Amazon Web Services S3 or Rackspace Cloudfiles, why not just use these to do the small amount of storing required? we could even find a company to host our database, server our static content from storage providers and we are 100% ‘serverless’ (serverless as in we dont have to write any server side code). But this architectural decision does have downsides, first and most obviously is we loose control of that area of our program and therefore User Experience. With a realitively small number of users its important to provide an excellent user experience. We would loose a few other things:
- custom request hooks
- analytics becomes harder
- unforseen functionality might be limited
- caching not under out control
- easy of access to our ‘own’ data
My decision was not a light one, the simple approach of no server to deal with is very aluring, but in the end the unknows and out-of-our-control’s are too many so we will stick with a traditional approach and run our own server. Next post, Technology