SuperSTAR and Cloud - nutting through the details of Google Apps Engine

I have spent the past week further working through the details of cloud offerings and how it can be used by existing and new SuperSTAR customers. It's still a hot topic, and I'm still sure it's a really good thing and something that we should be offering our customers if they want it.

So far, Space Time Research has put our SuperVIEW software into the Google App Engine cloud and demonstrated that it works just fine. We're confident that we're addressing many of the security concerns associated with clouds because we've chosen to go with a hybrid model, where the core database and SuperSERVER software still resides in the client's own server environment. It's just the application itself that is in the cloud. The data that is passed to the application is aggregated and encrypted already and something that would be passed to the web browser and then to the user regardless of whether the app is hosted in a cloud or not. So most of the security / data location concerns are not an issue with this model. [Aside: it will be for our SuperWEB product so we need to come up with a different way of handling that.]

At the risk of repeating myself, I do see some clear benefits of using this model over an internally hosted web server:

• For clients who already have a SuperSTAR infrastructure, external web hosting can sometimes be difficult to arrange. This is an easy and inexpensive way to get around it.
• Clients can take advantage of the scalability offered and handle peak loads without having to buy massive servers.
• Of course, there's others. They're in last week's blog.

So now we have a viable demonstration to show customers. The next question I had to answer was - if a customer wants it, would it work for them in a production setting? How scalable is it really? Is it true that there is no SLA for the Google App Engine? And how much would it cost and for what? Here's what I found out:

• It's true that there is no SLA for the Google App Engine. I reckon this rules out half of our customers straight away. Especially those who are data providers like the Australian Bureau of Statistics and want to reliably provide access to data and analytical tools to the world 24/7. Other customers, such as those who use our software for internal or researcher use, or those who are just starting out with SuperVIEW, might take this risk on board and try it out.
• It's really difficult to work out what it would actually cost. Everything is costed by usage per day and there's the option of getting a free service that then jumps into a paid service, or a paid service that gets more expensive as your user base grows. What we did work out was that it would be free for most SuperVIEW applications up to 2,000 user sessions per day. After that, it would cost approximately $300 USD per month to add an additional 1,000 users.

Conclusion:

Using the Google App Engine for SuperVIEW is a good way for us to get started with a real cloud offering. We can do this cheaply, and we can pilot and test it over the next 6 months with some of our customers. Space-Time Research needs to provide alternatives for our customers so they can make informed decisions about which method to go with.

We know we have cloud-enabled software and maybe this is enough for now. Our software doesn't work on every cloud (e.g. by definition it won't work on Microsoft Azure because our application is java-based), but it operates in virtual environments and can be hosted securely in some way outside a customer's server environment.

We need to understand more about the potential governmental restrictions - in particular what it means for Australia, the US and the EU which is where most of our customers come from. And what our customers expect us to do for them - do they want us to find the provider, or just provide assurance that our software will work in the cloud of their choosing? There is no point in us going down a path of recommending certain providers and finding out that the government would NEVER choose them.

A whole other topic, and one I will not write about but the gov2.0 thinkers are writing about, is the public servant aversion to risk and change that means that it's possible no-one wants to really do this anytime soon.

Next steps:

• I am preparing a white paper for our sales team and customers on what we offer now and intend to offer in the future. This will have enough technical details to be able to talk to project owners / sponsors, but IT representatives will need more detail.
• I'm finding out as much as I can about what governs our customer decisions now. I'm keen to get help on that because it's really hard to find out.
• I'm talking to Gartner analysts to get their take. Particularly as the article I'm sent most often is one that Gartner wrote about the security concerns of cloud and what to watch out for.
• I'm talking to a real cloud provider - Telstra - who are an Australian provider and who are going to host all of Visy Recycling's applications which is a significant move.
• I'm going to ask questions of the Australian gov2.0 taskforce and see what they think about it.
• I'm going to keep reading the articles I get sent every day.

Reflection:

Even though there is so much information out there, and so many articles and blogs being written about cloud computing at the moment, there is no one-stop answer shop that answers my questions. As I've been searching and figuring things out this week, I've really wished that I could just pick up the phone and call the Google App Engine product manager and talk to a real person. As I write, I realise I could have at least tried. This week's resolution is to ask more questions of real people via whatever means is appropriate.