This is a topic I’ve been meaning to cover for some time. It concerns a transition we’re seeing overall in the software industry, and is certainly one that the ADN team broached in depth during the last two DevDays tours.
I don’t think anyone is in real doubt, at this stage, that software is increasingly being delivered “as a service”, rather than via locally-installed desktop applications. Some readers may understandably be skeptical about the near-term likelihood of powerful design tools working in the cloud… I personally believe it’s an inevitable shift (whether we’re talking about a timeframe of 2 years or 10 is the real the question, in my mind), but I won’t try to convince anyone of the correctness of these opinions.
What I want to talk about today are the benefits of moving parts of your product functionality to the cloud, just as Autodesk is increasingly doing. Over a series of following posts I’ll then get into some specific steps you can take to do so.
So why would you move product functionality to the cloud? Here are some reasons:
- Performance
- If you have a problem you can easily chunk up and parallelise – rendering is a great example of this, as we’ve seen with Project Neon (which it seems is now known as Autodesk 360 Rendering) – then the cloud can provide significant value. Renting 1 CPU for 10,000 seconds is (more or less) the same cost as buying 10,000 CPUs for 1 second.
- Scalability
- With cloud services you pay for what you use, which should scale linearly with your company’s income (or benefits) from hosting functionality in that way. Dynamic provisioning allows companies to spin up servers to manage usage spikes, too, which allows infrastructure to be made available “just in time” rather than “just in case”.
- Reliability
- You often hear about measurements such as “five nines” uptime, which means 99.999% availability (or about 5 minutes of downtime per year). Some providers are no doubt proving better than others at meeting their availability SLAs, but the fact remains: having a local system or server die generally creates more significant downtime than those suffered by the outages suffered by cloud providers. And that should only get better, over time.
- Low cost
- As cloud services get increasingly commoditised – and Microsoft, Google and Amazon are competing fiercely in the cloud space, driving costs down further – using the cloud is becoming increasingly cost-effective.
That’s a bit about the “why”, here’s the “when”…
- Computation intensive
- If you have serious number crunching going on locally in your desktop apps – which either ties up resources that could be used differently or stops your apps running on lower-spec hardware – then the cloud is likely to look attractive. I mentioned we use make the cloud available for rendering, but we’re doing the same with simulation and analysis, too.
- Collaboration
- Imagine implementing the collaboration features of AutoCAD WS without the cloud…
- Frequent change
- If you have applications that go through rapid release cycles, then update deployment/patching is likely to be a challenge for you. Hosting capabilities on the cloud – appropriately versioned when you make breaking interface changes, of course – can certainly help address this.
- Large data sets
- The ideal scenario is clearly that data is co-located with the processing capability that needs to access it. Much of this data is currently stored on local systems – which makes harnessing the cloud a challenge – but as data shifts to be hosted there (for lots of very good reasons), this starts to become more compelling.
- Another example: let’s say you have an application that relies on a local database of pricing information. Making sure this database is up-to-date can be a royal pain: it’s little surprise, then, that a number of the early adopters of cloud technology in the design space relate to pricing applications.
These were the main benefits presented to ADN members during DevDays. There are few additional benefits that I’d like to add…
- Customer intimacy
- Delivering software as a service can increase the intimacy you have with customers – and with partners, if you’re providing a platform. You have very good knowledge of how your technology is being used – and this has a “Big Brother” flip-side that people often struggle with, as you clearly have to trust your technology provider – which can allow you to provide better service and even anticipate customer needs.
- Technology abstraction
- You may have some atypical code that you’d like the user to not have to worry about: let’s say you have some legacy product functionality implemented using Fortran or COBOL that you’d rather not have to provide a local runtime to support. Hiding it behind a web service reduces the complexity in deploying the application and can provide a much cleaner installation/deployment/usage capability.
- Device support
- This is probably obvious (as many of the preceding points will have been to some of you, I expect), but web services are accessible from all modern programming languages on any internet-enabled device. Web services are a great way to more quickly support a variety of usages of your application’s capabilities on a variety of devices.
OK, that’s the end of my pitch. ;-) I’d be very interested to hear comments – both for and against this trend, and also listing any areas I’ve missed – so please go ahead and add them to this post.
Over the coming weeks I’m going to take some real application functionality and move it to the cloud, to see – in a very simple use-case – what’s involved. I expect posts to include:
- Using ASP.NET MVC 4 Web API to expose a RESTful web service for use inside AutoCAD
- Consuming a REST web service inside AutoCAD
- Deploying an ASP.NET web service on Windows Azure
- Deploying an ASP.NET web service on Amazon Web Services
I’m sure this list will morph, over time, but I expect it to be a fun journey, either way.
To give you a further hint, my aim is to take functionality shown in these previous posts, to make it cloud-resident.
photo credit: seyed mostafa zamani via photopin cc
