"Cloud" is now a household word in today's engineering software landscape. That's both good and bad. Good in that new technology is actively being sought and aggressively adopted for CAD applications, bad in that the term places a whimsically diverse range of development, delivery, infrastructure, and virtualization technologies under one fantastically generic umbrella. So when it comes to cloud CAD, there's naturally quite a bit of consternation over whether your particular flavor of cloud-enabled CAD software might be pure, true, or perhaps even fluffy enough.
via XKCD
You see, cloud CAD isn't necessarily limited to one specific approach; it's many. Not all Cloud CAD is the same.
Free range broccoli
But it's getting hard to tell clouds apart. Which type of cloud infrastructure is right for your particular CAD application? How do you know if your organic broccoli was free range, hand cultivated by blind Zen monks in a politically agnostic valley or if said broccoli just happens to be partially composed of carbon molecules with a few delicious pesticides sprinkled in for good measure and fell off the back of Steve's jeep?
Yes, cloud in some ways is the organic produce of the CAD world. Sounds so darn healthy, but no one for the life of them can agree on exactly what it is or what qualifies. Don't even get me started with broccolini.
We could just leave you here, more depressed and confused than ever before about what the different flavors of cloud CAD really are about, but then this would be less of a blog post and more of just a cruel taunt. So of course we're going to help sort things out.
My cloud is your cloud, your cloud is my cloud
From California to the New York island, where your CAD data resides matters. And when your data is "in the cloud," that can mean many different things. Cloud infrastructure can be broadly categorized with four primary flavors. None is necessarily more true than the others, they are differing solutions for differing requirements:
| What it's called | What it is | Why you would want it | Why you might not |
| Public | Data and computing resources are available over the internet. A common misconception however, is that public implies accessible by the public. You can and should have secure logons and encryption. | You maximize the accessibility of your data and environments, while managing the computational infrastructure is someone else's problem. | If the cloud resources go down (i.e. someone trips on the cord, it's someone else's fault. Unless you haven't paid the bill then it's yours. |
| Private | Private cloud generally means data and computing resources are not available by the internet, they might be on-premise, or they might be offsite but with dedicated connection that bypasses the internet entirely. Dedicated hardware, even when it's managed by someone else, will be much more costly. | When you're Liam Neeson Taken-style serious about security to the point that you need to have physical separation and outright control, such as might be the case with export controlled or classified data. Or if you happen to be Batman. | You're fiscally responsible and aren't involved in a government contract. You're a lesser superhero on a small retainer, say Green Lantern. |
| Hybrid | Hybrid clouds are just that, a mix of public and private clouds to balance cost with mixed data requirements. A hybrid cloud can add resiliency between offline and online, but also involves additional complexity. | You like fences and insurance policies. Especially sitting on them. Hence, most larger corporate structures end up hybrid simply because of the large diversity of data and application requirements. | Your requirements fall wholly into one of the other types, and you have no desire to overcomplicate your life. |
| Open | Public cloud where data is openly shared without limitation, great for open source or other communal projects. | You're a tightwad and don't want to pay for your clouds, this is one way to get it for free. | You own or are developing any sort of IP (No your Harry Potter fan fiction doesn't count). |
Living in the cloud: tenancy
A discussion of cloud architecture, however, isn't complete without some mention of tenancy. This is not about rent control in the Bronx. It's about how clouds are partitioned between multiple companies, specifically with respect to software delivered by the cloud, i.e. Software as a Service (SaaS). There are two major tenancy architectures: single and multi-tenant.
Single-Tenant
Single tenant means just that, one cloud instance per company/customer (tenant) where data is (theoretically) more secure, isolated from other instances of the same cloud software used by another tenant. From a hardware perspective, single tenancy is significantly more expensive in that resources have to be individually sized for peak conditions for the single tenant, much like you would have to size on-premise hardware. In addition overall performance of the instance is more predictable - for intensive computing processes like CAE for example - since the instance will be unaffected by the performance of other instances.
Another chief advantage is in customization. If the software has to be modified in specific ways for only that one company/tenant, all of those customizations can be contained within the company's instance. However, each single instance has to be maintained and backed up separately which is why most cloud software goes the multi-tenant route.
Multi-Tenant
Multiple companies/customers share a cloud instance. Multi-tenancy is favored because it's generally far more cost efficient and security can be comparable to the single tenant model depending on how multi-tenancy is implemented. Multi tenant systems can be instantaneously upgraded and easily maintained across all instances, and redundant backups are greatly simplified. Granted this helps the software provider more than the customer, but it allows them to stack 'em deep, sell 'em cheap and pass the savings down (in theory).
Protip: if you're security conscious, the question to ask a cloud CAD vendor is how they implement multi-tenancy. If they enable tenancy by separate databases and/or virtualized instances, then you can give them a thumbs up, though they may empty your wallet to support such architecture. If they say tenants are sharing a database or even schema, and hand wave the rest with assurances keep in mind your data is only one application layer software bug from interacting with the next guy's data. Maybe that's OK with you, if you're saving a bunch of money on your car insurance. This is a direct tradeoff between security and cost. It all depends on your particular needs. Yes, cloud land is full of metric boatloads of "It depends..."
Taking your first step in a larger world
So now you have the basic knowledge on how to talk basic cloud infrastructure, so you can tell your multi-tenant public cloud with tenancy implemented at the database level from your single tenant hybrid cloud. Listen to old Ben, they'll both be advertised as "cloud" more than likely.
Keep in mind all of this is independent of how the cloud CAD application is realized, whether it's a connected desktop application with platform specific optimizations or something delivered entirely within a browser or even streamed from the ether. And you thought this was going to be so easy. We'll talk more about the application delivery side of things on the next exciting episode of the amazing, fantabulous, bewildering world of cloud CAD.
