Apps or Sites?

image

Part of me chuckled at the so called hack that affected Twitter today, not that something like this couldn’t affect any site (although given the simple and well known nature of the attack, it really shouldn’t have hit a site like Twitter) but it did remind me of the days in the early 00’s when this sort of thing was common place and the sort of problems we all had to face when coding sites in that era.

What did strike me was whilst I did notice it (whilst random JavaScript tweets are always fun doing the same one over and over again is sort of labouring any joke) I wasn’t affected by it. Why because I wasn’t accessing the Twitter website only consuming the feed from within an app, in my case TweetDeck.

Saved by TweetDeck

I was sort of surprised this week when I heard that 70% of people still use the Twitter website to send and read Tweets. I mean, Wired this month had a whole article bemoaning the death of the web, hasn’t Twitter read that and immediately shut down the home page. Hmm, no, in fact they just released a whole bunch of new functionality (which I can’t yet use, damn them) that can only be accessed via the website, just in time for the hack to emerge.image

Wired do have a point though, more and more people are buying applications for their phones, as smart phones become cheaper and cheaper more and more people will buy apps, just as more and more people will get access to the internet for web browsing. Applications will use the old ‘internet’ for services for the applications on their phone and the ‘web’ will go back to being one of the protocols used on it, that being HTML over HTTP. 

The thing about apps is that they don’t suffer the same attack profile as a web site, when information is mainly entered using an HTML form then that’s where people will look to attack. It’s harder to attack a series of apps that use a data feed, unless you can corrupt the feed in some way, as they usually will display the data in its own way, usually not using direct HTML or even in a browser.

Of course you could be using a compromised application, either downloaded onto a PC from an untrustworthy source or side loaded onto an Android or jail-broken iPhone in that case don’t say I haven’t imagewarned you. In fact the careful cultivation of the App Store under iTunes and to a slightly lesser degree the Android Market place adds that little bit more protection to users than the wilful installation abandon people have on their home (and sometimes work) PC’s (and Mac’s and Ubuntu boxes, but as I said who’s bothering to write a virus for those relatively paltry level of users /jk!).

Patched Apps

image The fact that Twitter patched the XSS issue in relatively short order is one of the main areas where the web works well. The ability to roll out a patch to millions of users at once be it a patch or new features, after thorough testing of course, is only really possible with application that leave no trace on the local machine. Cloud based applications not only protect your data from hardware failures but they can also be patched or upgraded without you having to do anything. Now I know some people will not like this, the same sort of people who still use OS/2 because they don’t understand these new fangled operating systems.

Desktop and mobile applications require an upgrade cycle because they rely on you installing something on a machine. On a mobile application this can be more arduous as they rely first on the developer getting the new application checked by the store it’s being delivered by, and then you have to be notified by the store that a new version is available, finally you have to actually install it.

On the web once it’s passed the requisite tests, it’s just there. Updated lazily in the background or when you next log into the website.

Apps or Sites, your call as long as it’s the cloud.

I read a comment the other day, every time I open an on premise application or use an on premise server to create data, I take a risk with my data. Every time I use cloud services for all sorts of tasks I know it’s not quite as whizzy as on premise applications or servers, but I know if my machine or server dies it’s still there. All I need is another browser and I’m up and running again. No need to install an app, no need to worry about the operating system either mostly these days.

image It works for me, I for one am happily replacing my offline apps for online ones when I can. Sure I still use some installed applications, I still love Live Writer for blogging for instance, Picasa for managing my photos and Google Earth for well just looking at my house from space, but those are my last few on premise applications I use at home (that aren’t games) and Google Earth and Live Writer are conduits for an online services.

I could do the same with my photos if I ever got the time, and there is the crux, as it becomes easier and easier to move data and information to the cloud, or if it has only ever resided there for many digital natives, then more people will and hopefully will be better off because of it.

The Lure of Easy

imageThe other day I built a computer almost from scratch. I can admit it, I can nerd it with the best of them when pressed, ok I don’t even need to be pressed. I had a bunch of components lying around, a not too old processor, a bunch of fast RAM and a laptop hard drive all I needed was a case. That was easy to rectify as I’ve always fancied building a little PC and Shuttle do some excellent barebones machines. Now the premise of this post is not the coolness of my new computer (although it is quite nice) but the ease at which it took to build.

When I was Young.

the internet in the 1970's When I was young and the ‘internet was all fields’ I remember building many a machine, both in and out of work, I remember saving my cash for the components, carefully making sure I didn’t bend anything when I slotted processors into motherboards and affixed strange looking fans to the top. I remember screaming when one of the components didn’t work and whole machine failed to boot. I remember returning complete orders and vowing never to build another computer again. But, the lure is too much for something’s and time can heal all wounds, even those inflicted by bad memory modules.

I Haz PowrToolNow whilst I was away from the field of home brew machines a number of things have happened, component prices have reduced, hardware is much more modular and available, I have an electric screwdriver (my only power tool I might add) and I can buy ready small machines with integrated motherboards at every online store. Now what does this add up too? An ability to assemble a machine in under 30 minutes, from start to end. I was shocked, surely it must be harder than this and after a brief moment of screeching from the machine as I had forgotten to plug-in the graphics card power supply, I was up and running installing Ubuntu (it’s free damn you and until I know it’s stable I’m not putting Windows on it!) and hooking it up to the ‘interwebs’.

Now the question arises, why if it’s so easy, would I not recommend building all the machines I own, or use at work? I’d be able to save money and tinker with hardware, what’s not to like?

imageSo easy is good right?

If pushed I could probably build a wall, but would I want it to support my house, probably not until I’d had  a lot of time building walls, maybe not even until 10000 hours to become an expert has passed. It’s the same with my new PC, would I use it to store my families photos, no I use a RAID disk set for that and the cloud (hmm I do trust them right?) as I’m unsure that the machine I threw together would be able to stay working for a long time.  I find this to be the same in designing and developing applications.

Components and development tools and platforms have come a long way since the internet fields were paved over and with that have come rapid prototyping, development and easy deployment. It’s now possible with the use of wizards and samples to throw a demo together in a very short period of time, like the construction of one imageof these modern barebones PC’s. Lots of development is easy, but because you can throw something together it does not mean it will be robust and stable, because I was able to build one machine quickly it doesn’t mean I will have the same luck again, or that my machine, which it’s mismatch components will not let me down when I need it most, like watching Snog, Marry, Avoid on the iPlayer!.

It’s the same with code developed quickly, technical debit will often lead to decisions being made that could impact the delivery of a system down the line, be those due to difficulties in refactoring or failure to run performance tests on software during development. For demo purposes technical debit might not be important, the code might not need to ever see the light of day beyond the demo, although the consequences of showing functionality that might be hard to implement reliably might live to haunt any project in the future. Lobbing technology bombs between pre-sales and professional services is always something that should be avoided, for good profitability reasons.

The Cloud Lure.

The cloud is another case of easy, it sells itself as a way to remove yourself from the burden of machines, your application can scale so long as you have the money to pay for it. Again, like the 30 minute machine build or the quick copy and paste development job, nothing is as easy as it seems and even though the imagelure is there, careful planning still needs to be done in architecting any system especially for those cloud platforms server to emulate a real system. In a world where your application isn’t tied to a specific machine you need to be careful what you can trust, are you getting data from a machine that knows about your updates, or another machine that is just handling your request at that point in time? As your application scales to multiple worker or web processes in an environment like Azure or App Engine, how do make sure everything is tied together?

Understanding how applications run in the cloud will still be needed, in order to utilise existing or still eme
rging patterns of development, such as those in the O’Reilly Cloud Application Architectures book or being developed by Microsoft on their patterns and practices site for Azure. There is no magic going on here, fundamentally thread must be mapped to processors somewhere, hardware has to do some work and then notify other machines about what has gone on. How you handle this in any deployment and its efficiency will impact the performance of any system and solution.

image Deploying applications into the cloud will be as complex as deploying applications into any set of machines, the complexity might be more software focussed and rely less on the understanding of processor specs and more on the understanding of the best practices for writing scalable applications, such as these provided by Google for App Engine.

Easy come Easy Go.

imageWhen I heard David Chappell (the IT speaker and not the comedian) say the phrase ‘there is no lock in like cloud lock in’ I realised that whilst there is much promise of Cloud computing it still needs treated like any other system. Badly written and architected solutions will not magically perform in the cloud and will always cost you more in the end than those that are optimised for performance and tested for scalability.

The cloud allows us to abstract ourselves from some aspects of deployment, but at a cost of making the software we are to deploy possibly more complex. As tooling and patterns become set we will be able to benefit from the power offered to us by a service we can build and deploy within 30 minutes, just don’t bet your mortgage that it will be up in the morning just because it’s in the cloud.