WISP Manifesto

We talked about ”Web applIcation Service Provider” (WISP) in the past days. So what are the specification for a Service Provder wanting to be a WISP?

Let’try to sketch them together:

WISP Hypothesis

  • A WISP must offer a set of XML-RPC API (WISP API) to configure the services. They must be simpler than SOAP, and must support at least two languages picked from  Python,Ruby,Java,PHP, Perl.
  • WISP API should be provided always in SSL way.
  • WISP API specification will be provided on subsequent articles
  • WISP must provide a minimal set of LAMP applications, like WebMail, CMS (i.e. WordPress). Also WISP must provide at least one “dashboard” web interface to set up a dashboard for the WISP API
  • For simplicity, the web application are deployed as  two tiered: database tier and web tier. Anyway you can build complex system connecting a lot of 2-tier application
  • On the database tier, WISP must give at least one Relational Database (like MySQL or PostgresSQL) and one NoSQL solution, altrought NoSQL forest is a bit tricky.
  • About email, at least an IMAP server and SMTP server must be provided
  • It should be possible to define “logical user” to segregate email mailboxes and web application
  • The amount of RAM allowed to be consumed by application should be considered only on the application tier. Database and webmail will be offered on a “best effort” base, with clear defined limits.
    For special needs, a “private” database instance could be installed
  • The Service Level Agreement (SLA) should be at least 99.99%
  • WISP has the freedom to choose the underling Operating System. By the way, the web application should try to be agnostic (even if Linux is always the first choice for a LAMP stack)
  • WISP must provide bandwidth and disk space in a very cheap way. For this reason, the “usage meter” should be easy to compute and very liberal on disk space, while very strong on single application memory usage