Could 2013 be the year that RIM recovers and BlackBerry becomes an important mobile platform again? January 30th is the key day, when the new BlackBerry 10 smartphone platform is launched.
We have seen a kind of preview of BlackBerry 10 in the unsuccessful PlayBook tablet, released in April 2011. This is the first RIM product based on the QNX operating system. QNX Software Systems was acquired by RIM a year earlier, in April 2010. That said, the PlayBook runs the PlayBook OS, not (yet) BlackBerry 10. BlackBerry 10 SmartPhones will have a new user interface and many new features.
I spoke to William Vablais, Head of Developer Relations EMEA for RIM. "We've been very successful in changing the sentiment of developers," he claims. "The interest level has been rising significantly."
One would expect him to say nothing less. But what is distinctive about the BlackBerry 10 platform; what does the it give you that couldn't easily be done on iOS, Android or something else?
Vablais points first to the diversity of development approaches it supports.
"We have SDKs for C/C++, we have entry points for designers and developers for HTML and CSS, we have entry points for Adobe AIR," he says.
There is also an Android runtime which makes it possible to repackage Android apps. Vablais observes that it can pay to offer your app on a minority platform.
"There's a community out there that developed for Android who don't have any exposure or visibility in that world because it's such an overcrowded market," he says. "They can take their application, port it to our platform, and suddenly they get visibility, generating revenue."
Fair enough, but what does the BlackBerry 10 platform give you that cannot easily be done on some other platform?
Vablais points to two key BlackBerry 10 features that he believes will draw users to the platform. One is social netwok integration. "We have the social network capabilities built into the OS," he says, referring to BlackBerry Flow and BlackBerry Hub:
BlackBerry® Flow is a new user experience that allows seamless navigation across open applications and the BlackBerry® Hub. All messages, notifications, feeds, and calendar events come into the BlackBerry Hub and no matter what the user is doing with the device, with a simple gesture, they can peek into the Hub at any time.
says the press release,
More important to business users though is security. "What no-one else has is that the OS and the framework has been based on security. The user interface and some of the components allow you to split out work related data from your personal related data."
This is the feature called BlackBerry Balance. Again, here is the official description:
BlackBerry® Balance™ offers the most elegant way to satisfy both customer and corporate needs without compromising on either. With BlackBerry Balance, personal apps and information are kept separate from work data, and the customer can switch from their personal to work profile with a simple gesture. The work profile is fully encrypted and secure, enabling organizations to protect their content and applications, while at the same time letting customers get the most out of their smartphone for their personal use.
In the era of BYOD (Bring Your Own Device), this does sound like a great feature. The industry is only just coming to terms with the idea that smart devices are personal; they do not live in the office and they will be used as home as well as at work. If BlackBerry 10 makes sense of maintaining work and personal data on a single device without compromising security or the user experience, then it could indeed be a game changer.
The success of the original BlackBerry phones was primarily based on its appeal to business users, and RIM already has tools for deploying internal apps in a managed and secure manner.
Even an excellent platform counts for nothing if you cannot market it successfully in a world now dominated by iOS and Android, as Microsoft has discovered with Windows Phone. Whether RIM has enough resources to establish yet another mobile ecosystem must be an open question.
At the same time, there is a lot to like. QNX has long been an excellent embedded operating system, and if the devices are excellent and the security lives up to its promise, BlackBerry 10 could be a significant platform for mobile buisiness apps.
Mark January 30th in your diaries and watch with interest.
Windows 8 has been released to manufacturing, along with Windows Server 2012 and Visual Studio 2012. There is also a major new version of Office, Microsoft's other mainstay, due for completion around November this year.
These releases are more than just the usual round of updates. On its tablet-friendly Metro side, Windows 8 has a new runtime and user interface which is almost a platform within a platform. Microsoft consciously reformed the Windows API, with much of it unavailable from the Metro side, applications sandboxed, and asynchronous programming enforced.
If you do development in Microsoft Office, you will find a new application model there as well. Called Apps for Office, this is a way of embedding web applications either in a document (only supported in Excel at the moment) or in a task pane alongside a document (supported in Excel, Word and Project). Outlook 2013 does not have a task pane, but uses a similar approach for new-style Mail apps, a separate pane that displays alongside an email.
The significance of Apps for Office is that being web-based, they also work in Office Web Apps. This means that an application developed for the new model will run on platforms where the Office 2013 client is not available, including tablets and Macs.
There is a lot of sense in Microsoft's approach, whether or not you like the blocky Windows 8 Start screen, or the washed-out user interface in Office 2013. That said, it is a big ask for developers. The problem is not only the amount that developers will have to learn, but also what they need to throw away.
When Visual Studio 2010 was released, frameworks including Silverlight, Windows Presentation Foundation and XNA (for games) were positioned as strategic APIs in which developers could invest their time and effort with confidence. A few years later, and all those frameworks look like legacy.
If Windows RT (that is the ARM version) takes off, developers have to come to terms with a wave of Windows devices that do not run their desktop applications at all.
On the mobile side, loyal Microsoft-platform developers have endured a rollercoaster ride trying to keep up with how the company says you should develop today. Windows Mobile 6: C/C++ is in. Windows Phone 7: C/C++ is out. Windows Phone 8: C/C++ is in again.
The question developers will be asking as Windows 8 and Office 2013 roll out is this: how can we be sure that innovations like the Windows Runtime or Apps for Office will still be worth developing for by the time Visual Studio 2014 comes around?
I am inclined to agree that the Windows platform needed reform, and despite a few jarring changes there is a lot to like in the 2012 wave. But what the company now needs is a period of consistency and consolidation, otherwise its developer community will simply lose faith.
I have been spending some time with the recently released Sencha Architect 2. This is a development environment with three core components:
Ext JS 4.0 Framework: an HTML5 application framework for desktop browsers
Sencha Touch 2.0: an HTML5 application framework for mobile browsers
Sencha Architect IDE: a visual development tool for both Ext JS and Sencha Touch
Architech is a commercial product, but there are free and open source versions of Ext JS and Touch with various licensing and support permutations available.
I installed Sencha Architect on Windows, which works though I cannot quite describe it as Windows-friendly; there is a Mac flavour to the documentation and nothing quite works in Internet Explorer, Chrome or Safari is recommended.
What you get though is an elegant IDE which is focused 100% on applications, rather than general HTML design. It is not Eclipse-based, which I found interesting having recently also tried the latest Titanium IDE from Appcelerator, which is built on Eclipse. Although Eclipse is a wonderful thing, it does add complexity and overhead compared to a lightweight, dedicated IDE like Sencha Architect.
The frameworks are also interesting. Both Ext JS and Sencha Touch (which are similar in many respects) are based on a Model-View-Controller design, and this is neatly expressed in the IDE which shows Controllers, Views, Stores, Models and Resources in its Project Inspector. A store is essentially a collection of model instances, and might for example be an Ajax proxy retrieving JSON data from a remote URL. The image below uses this technique to show bars in London. The app is designed for a smartphone, though I am displaying it in Google Chrome to test.
A great feature of the latest Sencha toolkit is that you can package apps as native apps for Android or iOS. Support for RIM Playbook is also planned. You can even package for iOS on a Windows machine, though of course without the benefit of the iOS simulator. Sencha's approach to native packaging is similar to Phonegap/Cordova, in that it uses the embedded browser on the device. However Sencha is not using Phonegap, but as far as I can tell, draws on technology acquired from Nimblekit, a small company specialising in native apps for iOS with HTML and Javascript acquired by Sencha.
These frameworks are not the easiest to pick up quickly, but I was struck by the clean design of both the code and the IDE. Further, Sencha apps generally look good and in many cases the visual components come close to what you can achieve with native code.
From what I can tell, the pressure on developers to create apps that play nicely with a variety of devices, from Windows desktops and laptops through to iPads and Android smartphones, will only increase. Sencha is worth a look.
It is a little early for a review of the year, but not too early to state that 2011 has brought profound changes to the software development world. Although I am thinking mainly of the client, I would also argue that client and server are so intertwined that both are affected. As an example, I have heard developers moving away from SOAP web services not because of any conviction that REST is a better approach, but because the move away from Windows and towards HTML clients makes SOAP web services more difficult to consume.
So what's changed? Simply put, three platforms which once seemed strategic are now in obvious decline. Getting the nuance right for these platforms is tricky. Lots of software still runs and is still widely used long after it has ceased to be strategic for the company which supports it. All the platforms mentioned negatively below are still in active development; they are not going away and will still be running ten years and more from today. They come with health warnings though: depending on these platforms means that your software will gradually become more difficult for users to run and will be left behind by new technologies.
In the run up to the launch of Microsoft's Visual Studio 2010 I spoke to a number of Microsoft platform developers. The consensus then was that Silverlight was very important and possibly the future of Microsoft's client. The view was supported by the company's energetic development efforts for Silverlight. It also made a lot of sense: a lightweight, secure, cloud-centric client that escaped the GUI limitations of Win32, worked in the browser or as a desktop application, and as a bonus run on Mac as well as Windows. Silverlight, as I noted in several articles, is client-side .NET done right.
This is not the place to write a long screed about why Silverlight failed, but rather to note that at the end of 2010 it became obvious that Microsoft was changing direction. At the Professional Developers Conference, October 28-29 2010, it was hardly mentioned, and the company focused instead on HTML and Internet Explorer 9. The full extent of its new strategy was not shown until this year, at the BUILD conference in September.
It is not only external developers that were surprised by what seemed a sudden change of direction. The same seems to be true of many within Microsoft itself. Nor am I sure exactly when someone decided that Silverlight was no longer strategic, though there are clues in the Silverlight release schedule. When Silverlight 4 was unveiled in November 2009 it was still ascendant. Silverlight 5, due out shortly, suggests that it was still considered important in early 2010. Visual Studio LightSwitch released this year was likely planned in part as a way of boosting Silverlight, since it builds Silverlight applications. But nobody is talking about Silverlight 6.
Silverlight is still the development platform for Windows Phone 7, but many observers, myself included, believe this will give way to a variant of the new Windows Runtime (see below) in a future version.
This has been a costly experiment for Microsoft. If the company had done the Windows Runtime, rather than Silverlight, back in 2007, imagine how much stronger would be its position now. That said, it is not all wasted. XAML, the presentation language in Silverlight and in Windows Presentation Foundation, continues in the Windows Runtime, and so does the essence of the cloud-centric, client-secure development model.
Back in 2007 Silverlight seemed to be in part a competitive response to the increasing popularity of Adobe Flash. This month though, Adobe went though wrenching changes of its own, announcing the end of Flash on mobile browsers and a fundamental shift in business strategy away from enterprise development and towards content creation and distribution.
There are plenty of parallels with the Microsoft case. One is that the changes also came as a surprise to many within the company, who just a few weeks before, at the MAX conference in Los Angeles, were talking confidently about the future of Flash and of Flex, the application-centric SDK for Flash. Here is Doug Winnie, a casualty of the inevitable layoffs:
The product managers, evangelists, community managers, and developer relations team members found out the news and the way it was communicated at almost the same exact time you did. They are wrestling with the news and your reaction in real time--so please be supportive of them as they dig through everything.
While on the 3rd day of my vacation in Mexico, I got the call with the explanation that Adobe is doing a major refocus and as part of that, many of us "enterprise" types are no longer required. "Überflussig" I guess is the correct German word for the situation. Keep in mind that I now speak as an individual, not as an Adobe employee. I missed most of the official story due to the timing of my vacation but caught up with a few news outlets to get the rationale.
But isn't Flash still going strong on desktop browsers, and the Flex SDK heading for great new things as an open source project at the Apache Foundation? Well, maybe. Adobe is not betting on that though; it is betting on design tools for content, HTML5, and packaging and distributing publications and apps. Its Flash technology is still critical to how that is done under the covers, but Flash itself will be invisible.
Adobe also says that its LiveCycle middleware will continue to evolve in two specific niches:
We will continue to sell and support our LiveCycle products in the government and financial services markets, two areas where the LiveCycle value proposition remains especially strong.
Again, maybe. This sounds more like Adobe keeping faith with some important customers, than a strong future for LiveCycle.
Microsoft announced another profound change in direction at its BUILD conference in September. Although related to the decline of Silverlight, this one deserves its own heading. What we saw was that the Win32 platform on which Microsoft has built its prosperity for the last twenty-one years or so (Windows 3.0 came out in 1990) is now being shunted aside. "Shunted aside" is the right term because it is still there in the forthcoming Windows 8, but it is side by side with the new Windows Runtime (WinRT) and a touch-friendly user interface called Metro. The company's goal is to create a platform that will succeed against Apple's iOS. It runs on ARM as well as Intel x86 and has its own Windows Marketplace, similar in concept to Apple's App Store.
Leaving aside the merits of WinRT, the big news here is that Microsoft is finally moving away from the Windows desktop on which most of us have done our work day to day for the last two decades. The reasons are obvious: mainly the rise of iOS and the iPad, but also the success of the Mac among developers and at the premium end of the laptop market. Windows was already in decline.
Your Win32 applications will work forever, but Microsoft's energy is now going elsewhere.
What about the .NET Framework on the client? It is still there, and thanks to the excellence of the C# language I expect it will be the most popular approach for coding for Metro. Parts of the Framework will no longer work in Metro though, and it may even be that HTML5 and JavaScript, which is equally well supported, will gradually supplant it. Nor do I take the success of Windows 8 for granted; Microsoft may find the tablet market already largely absorbed by iOS and Android.
That is speculation; but the long-term decline of Win32 is not.
If these platforms are in decline, what the ones that are rising fast? That is simple to answer. Apple iOS, Google Android, and HTML5 in general. Are these good for the next two decades as in Win32, or will be on the deprecated list in a few years? That is hard to say; if I had to rate them in order of likely longevity I would guess this:
1. HTML, JavaScript and CSS
2. Apple iOS
3. Google Android
Predictions though are a dangerous game, and I would be interested in other opinions.
I have posted before about Delphi, a rapid development tool forgotten by some, but still the best option for Windows native code development combined with a productive visual component library. That was over two years ago though, shortly after I met with Embarcadero CEO Wayne Williams who promised a version of Delphi that would compile for the Mac as well as Windows.
I had nearly given up waiting; but a couple of months back Embarcadero released a new Delphi with features which, on the surface at least, exceeded my expectations. Here are the highlights:
It is an amazing list of features, particularly considering the rather disappointing first version of Delphi XE. Embarcadero seemed to have done everything promised and more, in one release.
I was keen to try cross-compiling for the Mac, and set it up in what seems to be the most popular way, using a virtual machine on a Mac to run Windows, and running Delphi in the VM. When you install Delphi, or the full RAD Studio which includes C++ Builder and other features, it installs several components that you then run on the Mac side, including the FireMonkey libraries and a server calls the Platform Assistant. You then create a remote profile in Delphi that connects to the Platform Assistant, password protected for security.
Everything worked first try. I added an OS X target to my Windows FireMonkey app, clicked to run, and my simple app opened like magic as an OS X application on the Mac desktop.
Coding for iOS was more work, since you end up exporting the project to Xcode and compiling with the Free Pascal compiler rather than simply using Delphi on Windows, but it did run successfully, and I was able to use my simple test application on an iPhone.
Embarcadero is promising to add Android support at some future date, making this an interesting tool for those who need to support multiple platforms.
Is this the Delphi we have been waiting for? There are a few things that spoil the product. It does seem to have been rushed, which is hardly suprising when you realise that Embarcardero acquired VGScene and DXScene, products for Delphi that form the basis of FireMonkey, from a company called KSDev only around 6 months before RAD Studio XE2 was released. I am not sure what plans Embarcadero had for a cross-platform framework when I spoke to Williams in 2009, but does look like the KSDev deal solved a number of problems.
This rush shows itself in the immaturity of the FireMonkey framework. There are some performance issues as well as limited features compared to what was available with the VCL (Visual Component Library) for Windows. The VCL may be wedded to Windows, but it is hard to leave behind sixteen years of VCL evolution in favour of the first release of a new framework. Existing applications will not necessarily port easily. It is not only a matter of porting from the VCL to FireMonkey. Delphi developers are used to calling the Windows API when necessary, creating code that will not run cross-platform.
It is also worth noting that all FireMonkey controls are custom drawn. There are always compromises in cross-platform development, and in the case of FireMonkey you are giving up the advantages of using native controls on Windows or Mac.
As a cross-platform development tool, Delphi is now up against Adobe Flash Builder, Appcelerator Titanium, PhoneGap, and others. I have been impressed with Adobe AIR in this context, and PhoneGap also has lots of momentum and is ideal for web developers who now need to create mobile apps.
There is every sign though that Embarcadero is serious about FireMonkey and investing in its future. Existing Delphi developers now have a way to move beyond Windows while still using their preferred tool; and the product looks likely to attract new users thanks to its cross-platform capabilities.
Finally I should add that while it is the cross-platform aspect that is most eye-catching, the VCL is not dead and with 64-bit support Delphi is better than ever as a Windows development tool.
Microsoft's BUILD conference last week was a fascinating event. Of course the headline news was about Windows 8, for which we got the full technical details, or at least most of them, for the first time. There is also a public preview, and I tried out Windows 8 on a high-end Samsung tablet loaned for a few days, then again on a VirtualBox virtual machine after my return to the UK.
Windows 8 will no doubt arrive in a year or so, and we can debate whether it will be a storming success, a dismal failure, or something in between. I think it makes a great tablet operating system, but purely considered as a tablet, it will not be easy for Microsoft to break into the market dominated by Apple's iPad and with Android mopping up most of what remains. The purpose of BUILD was to encourage developers to build apps for the new Metro-style user interface, and if Microsoft can build up a decent range of apps with which to populate its new store, the early Windows 8 tablets will have more chance of success.
It is tempting though to think that this is mainly aimed at consumers, and the fact that the sample Metro apps are mostly games or other trivialities reinforces that impression. Does that mean Windows 8 is insignificant for businesses, or for business software developers?
I do not think so. In fact, the more I reflect on BUILD the more it seems to me a pivotal event not just for Microsoft, but for the IT industry. Here is my reasoning.
First, at BUILD Microsoft made it clear that Windows now has two personalities, built on different programming models and in fact different APIs. The old Windows, now referred to as "desktop", trundles on as before. There are few changes from Windows 7 in the preview build, other than that the Start menu switches you to the new Metro-style user interface, a controversial decision that may become user-configurable in the final release. Yes, Explorer now has a ribbon, the file copy dialog is improved, and I am sure that there will be more small and cosmetic changes to desktop Windows before final release, but they will be minor.
It seems to me that Microsoft itself has now re-positioned desktop Windows as a kind of legacy environment, even though it is the one that most of us are likely to use most of the time. Irrespective of whether Metro-style Windows is a success, the implications of this are huge. After all, Windows still dominates business computing. Yes, Microsoft will still invest in desktop Windows; but the strategy is focused on Metro-style and it is plausible that Microsoft will never now make radical changes or advances on the desktop side.
Second, Metro-style Windows 8 is not just a touch-friendly user interface. It is designed as a client for cloud services. This is most obvious when you realise that Microsoft has not included data providers for local network database servers like SQL Server; you are meant to interact with data via web services. Metro-style apps are isolated from one another, and can only communicate with the file system, outside their own isolated storage, via specified, user-controlled mechanisms called Contracts. Windows 8 shows that Microsoft really is embracing cloud computing, and that may be more significant than the fact that it runs nicely on tablets.
Third, and related, is that Microsoft is locking down Windows, especially in the version for ARM which we did not hear much about at BUILD. If Microsoft gets it right, Windows on an ARM tablet will be equally as secure as an Apple iPad. It is hard to be definitive about this, because the role of desktop Windows in the ARM build has yet to be clarified, but from what I can tell Microsoft plans Windows 8 on ARM as essentially a Metro-style platform, with apps available only through the new Windows Store. If users can only install Metro apps, the entry points for malware are greatly reduced. I suspect that Microsoft also has its eye on Apple-like control and profits from being the only source for Windows 8 apps, with interesting implications for software freedom, at least in the consumer market.
If there is a moment in history when desktop computing became legacy, I suspect BUILD 2011 will be a good candidate.
Finally, note that Microsoft's new Windows Runtime, within its locked-down constraints, looks to me exceptionally well done. Microsoft has achieved security, performance, and support for multiple programming languages including .NET, JavaScript and C/C++. One of its best decisions was to make every API call that might take more then 50ms into an asychronous call, and then to modify the programming languages to make asynchronous programming easier than it has ever been before, via new statements including the "await" keyword in C#.
The Windows desktop will be around forever, and in fact the stability of the platform in terms of forward compatibility has if anything improved, now that we know major changes are unlikely at least until Windows 9 in say 2015, and probably never.
More significant though is that the cloud computing model now has the backing of all the major industry players, even the one with what looks like the most to lose.
CEO Steve Ballmer called Windows 8 Microsoft's "riskiest product bet" and I am inclined to agree.
I have been looking at Microsoft's forthcoming SQL Server 2011, code-named Denali, for which the third preview has recently been released. There is plenty to say about Denali, which has many new business intelligence features as well as the intriguing ability to publish a table as a network share accessible from the file system, but I am particularly interested in the new developer tools, known as Project Juneau.
What is Project Juneau? Well, the old SQL Server Management Studio is being redone using the Visual Studio shell, but what is more interesting is the new SQL Server Database Project in the full Visual Studio, along with some new tools for working with databases.
Now at this point I have a confession to make. I have never given Visual Studio Database Projects the attention they deserve. Visual Studio 2008 instroduced a specific database edition, with a specific database project type. In Visual Studio 2010 this became a feature of the Premium and Ultimate editions. Juneau includes the next version of the database project type, now called a SQL Server Database Project.
Just in case others have also paid little attention to Visual Studio database projects, the core feature is the ability to treat databases as code.
How is a database code? It helps to break down what we typically mean by a "database":
1. The data itself.
2. The structure of the database: tables, column types, indexes.
3. Code embedded with the database structure and executed by the database manager, included stored procedures, triggers, user-defined functions.
Of these, it is only the third category that I had previously considered to be code. I was wrong though. The database schema is also code. Further, since the schema can be instantiated by running SQL create statements, you can conveniently represent a schema with that code. Execute the code, and you instantiate the database schema.
Once you start treating the database schema as code, new things become possible. You can do all the things that you usually do with code: put it under version control, refactor it, compare it with other versions, and so on.
This is what Juneau does. When you import a database into Junueau, it becomes a set of SQL create scripts.
This is also what the old Database Project does, so the concept is not new. Microsoft describes the Juneau tools as:
an evolution of the existing Visual Studio Database project type
which can be interpreted to mean that this is a new product which will eventually encompass everything the old product did and more, but that initially there are compromises: while there are new features, there are some other features mssing. Since Juneau is currently in preview it is impossible to be definitive about this yet.
Still, there is plenty of good stuff in Juneau. They follow through on another implication of treating the database as code, which is that you can debug it, by building a local version of the database. The Juneau tools do this, using a new local instance of SQL Server. When you publish the database to production, you have a bunch of options concerning how you want to handle the operation, given that there may be an existing database already present. There is always an option to generate script, rather than executing the operation immediately. The same is true if you change the schema of a connected database in Visual Studio's server explorer. The Juneau tools show all the implications of any change, including warning about data loss when necessary, and offer to generate a script rather than immediately applying the change.
Schema Compare is another useful feature. Imagine that you import am existing database into Visual Studio for application development. This takes three months; but in the meantime the admins have made some changes to the production database, maybe for security or performance reasons. If you have also added some tables and rows for the new application in your development version of the database, this can be awkward to reconcile. Schema Compare lets you see the differences easily.
A goal of the Juneau tools is to make it easy to migrate a database from one platform to another. Microsoft has in mind that some developers will be moving databases from on-premise servers to SQL Server Azure; but irrespective of whether you have cloud hosting in mind, this is a useful feature.
One of the reasons the old Database Projects are perhaps not as well known as they should be is that they are reserved for the high-end Visual Studio editions. I hope Microsoft makes the Juneau tools more widely available, because treating the database as code is a powerful idea, with benefits that should please the operations folk as well as developers.
There is intense interest in cloud computing today. But what about take up? I am interested here in the cloud as an application platform, not how many people are using Google Mail.
There is so much noise from vendors about cloud - noting that this is a nebulous and abused term - that it is easy to get the impression that most of us are busy migrating applications to shiny new cloud platforms, and that new projects will almost inevitably be cloud-based.
I spoke recently to Nick Hines, CTO of innovation at global software developer and consultancy ThoughtWorks. This is a company that has embraced Agile methodology and has always struck me as thoughtful and watchful in its approach to software development. It publishes a regular Technology Radar examining technical trends and assessing which are ready for mainstream adoption and which are in decline.
When I spoke to Hines I was researching application development on cloud platforms, and trying to discover how Microsoft's Azure effort was perceived in the real world. I suppose I expected that the company would have many cloud projects on the go and be well placed to assess the strengths and weaknesses of rival platforms.
The most revealing comment came at the end. After chatting about cloud and Azure for half an hour, I asked: could he put a figure on the proportion of ThoughtWorks projects that involve cloud hosting, not just for development, but for production deployment?
That would be relatively small. One to two percent at this point.
he told me. No more than two out of a hundred projects deployed to the cloud. Considering the level of vendor hype around not only Azure but also Amazon web services, Force.com from Salesforce.com, Google App Engine and so on, that is remarkably small.
I must be careful not to mis-represent Hines. He is of the view that not only is cloud significant as a platform, but that it will take over:
This is the way the world is going. We all know it. You can imagine that in 20 years time the idea that companies have their own datacentres is going to be quite anachronistic. How quickly we get there is yet to be seen.
We are then at an interesting point in terms of technology, where we think we can see the future in some respects, but there is a near-consensus in the enterprise development world that it is not yet ready.
Why is it not ready? This of course is a point of debate; but enterprises dislike uncertainty, and there is still uncertainty around cloud platforms. When you ask vendors about the big issues, security and resilience, the best they can do is to point to past performance or give you a speech about the efforts they have made in those areas. CIOs may worry about a nightmare scenario where the system is down and they have no direct control over how it will be fixed. This is responsibility without power; and no, being able to say "we have a service level agreement" is not a solution.
This is also why approaches to the cloud that allow flexibility are popular. Not all risks are equal. For example, you can use a cloud platform as a means of scaling an application at times of peak demand, while keeping the data and code on your own servers. This kind of approach does not yield all the benefits of multi-tenancy or platform as a service, but it means that in case of calamity you can easily deploy to a different platform. The idea of deploying virtual machines to the cloud, while keeping hold of the master image, is popular for the same reason. Hines told me:
People have a greater level of comfort with infrastructure as a service. Whilst it may not have all the advantages that platform as a service offers in terms of reduced administration and so forth, people are more comfortable feeling that they are closer to the tin.
This is the enterprise perspective of course. If you are a start-up or independent developer already accustomed to depending on third-party internet services, then cloud deployment feels less risky.
The consumer perspective is also relevant, despite what I said above concerning Google Mail. If as individuals we learn to trust cloud providers because of our experience with email or personal documents and pictures, then when we step into the business world we will be more inclined to approve a cloud deployment.
Concerning Microsoft Azure, Hines believes that Microsoft needs to prove its ability as a cloud provider, and that a success with the recently launched Office 365 could give Azure a boost, even though it is a different kind of service. It is the same kind of logic: if Microsoft can run Office 365 successfully, the comfort factor over Azure will increase. The reverse is also true.
There is always reason for caution; but it also seems to me that this is a moment of opportunity for those who take well-judged risks with cloud platforms. I would be interested to hear from both developers and CIOs about your perspective on this. Do you trust the cloud yet, and if not now, then when?
