Play-by-Play: The Architecture

May 25, 2010 by Craig

A pay-as-you-go service goes hand-in-hand with a web-based application; it’s much harder to make a viable one-time-purchase web service or a pay-as-you-go desktop application. This choice of architecture has several benefits of its own:

  • Lower (nearly zero) maintenance for the customer. There’s no software to install and no servers to operate.
  • Easier compatibility concerns for the developer. Modern web development is very consistent across platforms (assuming you choose not to support Internet Explorer 6 or less. Even if you target modern Windows exclusively (and that probably means abandoning the huge XP installed base), desktop software has to contend with a huge number of variables for each local installation.
  • Easier distribution of changes, fixes, and enhancements. This is critical for any agile & responsive business.
  • Greater possibility for interaction with the customer. You get a certain amount of feedback automatically, just through usage logs.

Of course, there are some major downsides:

  • The customer must have a useful Internet connection at their place of work. My domain expert says that this isn’t much of an obstacle; most bakeries have them anyway for things like email. Still, it will be useful to keep offline / non-browser modes in mind: I’m thinking of printed sheets and smartphone apps as future directions.
  • The application won’t be able to take advantage of some features on the local computer. This has been getting less important over the years, but there’s still a few technologies that simply won’t work through a browser. Scanner support is probably the biggest one I can think of. However, that’s probably not important for this particular product.

One of the biggest advantages though is that my own personal strengths lie with web-based application development. This is a big factor on a small, speculative project like this. However, it should not be the deciding factor; if the product and market do not fit the developer, then you need to either change developers or change products.

I’ll be using a cloud-based hosting service to start out with. Cloud-based services offer the greatest scalability. In the early days of an application, this means scaling down rather than up; there won’t necessarily be enough traffic to warrant a full-size server (even a virtual server). A cloud service will also scale up nicely through the first phase of growth. After a certain level of traffic, a full server will become more cost effective — but that’s quite a ways off (and getting further away by the year). Since traffic effectively means revenue, migrating to a new server platform will be one of those “good problems to have”.

In my next post, I put some real numbers against the architecture.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.