CAD in the Cloud: How it might work

I'm a bit amazed by the recent hype over cloud computing. Google Docs, Salesforce, Amazon EC3, the list goes on: the tech blogs are falling over themselves to keep up with the latest software-as-a-service and cloud offerings. Listening to Google's PR team, one might think that we're about to give up on stand-alone computers altogether. Of course, there's a long way to go before such a model will work for any more than the most basic computing tasks, and I'll address here the particular case of CAD and engineering software.

Cloud computing, for those unfamiliar with the term, is essentially a 21st-century throwback to the mainframe-and-terminals computing model of forty years ago. Back then, computers were large and horrendously expensive, so a single big mainframe would run all the important code while separate (and cheaper) user terminals only handled input/output.

Today, computing power is cheap; so cheap, in fact, that most of us have far more of it than we really need. Meanwhile, synchronizing files among multiple users and locations has become a royal pain for all but the simplest organizations. In the cloud model, the files and most of the application code is moved to a central server farm- thus, the end terminal can be smaller, simpler and cheaper, as it only needs to run a Web browser while the server farm does the real grunt work. And that data can be worked on by multiple end users, it never gets out of sync, and updates become automatic and seamless.

This is all well and good for basic office tasks such as word processing and simple spreadsheets. But the cloud model quickly breaks down when you start throwing engineers and designers at it. We want our Rhino3D, we want our AutoCAD, we want our Photoshop, our InDesign and our Catia. This sort of sophisticated software needs serious local graphics processing power, and serious bandwidth to handle enormous files and data streams. At the same time, being able to leverage the enormous computing power of a cloud (not to mention its collaboration and synchronization capabilities) is very tempting. So, how might it be done?

The current cloud model, in which everything runs server-side and I/O is handled by a browser, is not going to cut it. As anyone who's tried to do CAD via Remote Desktop or LogMeIn can testify, there just isn't enough bandwidth available in most networks to handle the traffic that real-time 3D rendering at 2400x1600 would create. Your ISP would cut you off by the sixth day of the month, while your mobile provider would quietly let you rack up a four-figure bandwidth bill. And, of course, driving the multiple large monitors of a CAD workstation requires some fairly serious graphics hardware that would be wasted in an all-in-the-cloud system. So it would make sense that some components of the software- the rendering and geometry processing, at least- should be done locally, at least to the extent the hardware will allow.

At the same time, engineers hoping to do CAD in the cloud will want to access their work from whatever device is handy. It might be a killer desktop PC, it might be a next-gen slate computer, so the system has to adapt with an appropriate balance of local/server processing for each client. And each designer will want to work on her section of the project without causing problems for her colleagues playing with other parts of the model. So we're looking at a cloud-based CAD core that will maintain a master copy of each model (and associated drawing sets) and can, in near real time, integrate users' changes into the master model and echo those changes to other clients working on related sections of the project. That won't be an easy task, especially if several engineers are working on the same section of the model, but it should be possible.

Engineers, of course, do not trust networks, and will want a seamless fail-over to a local solution if they leave the network or something crashes (with a similarly seamless re-integration when the network comes back). A successful CAD cloud, then, will have to pass each user a copy of the section of the project on which he is working, keep track of who's working on what and how it's all related, and tie it all back together in the server farm.

To make this work will of course require a local client program of some kind, something more task-specific than a browser (although, for ubiquity, it would probably have to launch from within one). This client program could be quite compact, containing little more than a modelling kernel, rendering engine and user interface, and to be efficient, it would have to run locally at the same low level as current CAD software- no Flash or Silverlight allowed. Current CAD software tends to be horrifically bloated with specialized components that most users need only once in a while, and these components would reside on the server farm in our hypothetical CAD cloud. The appropriate bits of code would be sent to each client as needed.

What we're left with, then, is a master CAD core in a server farm, maintaining master copies of all the modelling and calculation software as well as a master copy of each model being created. A client, then, would fetch from the server a small, locally executed program to handle the modelling and rendering of whatever piece of the model that client terminal's user is working on. Anything too computationally intense for the client terminal to handle on its own would be run by the server farm, the results returned to the client, and the changes integrated into the master model. Only the geometry data, and the results of any calculations run on the server, would traverse the network link. If a client goes offline, that engineer would be able to continue working with her local copy of her part of the model, with access to whatever add-ons she loaded before going offline. When she returns to the network, her client computer would synchronize its model data with the cloud's master copy.

This is all very hypothetical at this point, but it does have one more thing going for it: CAD software companies have been trying for years to steer us in the direction of subscription-based software licences, charging exorbitant annual upgrade fees for what often amount to minor cosmetic and file-format changes. A truly effective CAD cloud could work without too much of a change to the business model they're already trying to hook us with.

I won't hold my breath. AutoCAD, after all, has changed very little in ten years or so, apart from file format tweaks, a new UI, and (just last year) some modelling modes that used to be sold as part of a different program. High-end packages such as Catia, Pro/E and NX are now quite dependent on high per-seat licence fees and intrusive licence management software, a business model that would be hard to change- a CAD cloud would have to get away from per-seat licences, perhaps in favour of a per-user or per-server-load model. But I think it's quite likely that, within ten years or so, at least one comprehensive 3D CAD system will form in, or migrate to, the cloud. It will be interesting to see how it works out.




3D rendering supports

One of the new cloud buzzwords is the acronym SaaS. The idea is that you'll no longer actually purchase and install software, but will instead subscribe to a software service, paying a company that continues the CAD software on the cloud. Of course the SaaS/cloud concept increases all sorts of queries about who owns what data, how renews to the software will be handled, and what would happen to its clients if a software service provider goes out of business.

3D animations

SaaS reliability

Matthew's picture

That, Racks, is the SaaS problem in a nutshell: You have to entrust mission-critical infrastructure and data to a third party. Evidently, some organizations think that's OK for some of their workers, but it adds a large and hard-to-calculate element to your risk analysis if your own firm is thinking of outsourcing these processes.

Add new comment