SolidWorks As A Service – Part 4

Here are links to Part 1, Part 2 and Part 3.

In this part, I would like to talk about another issue that affects me and my company directly – third party add-ins.

SolidWorks prides itself on its very successful partner program, of which SYCODE has been a part of for many years. I dread the day when SolidWorks as a Service becomes a reality because when it does, I am not sure what will become of the numerous third party add-ins developed by SolidWorks partners as well as those developed in-house by users themselves.

I believe most users are not aware of how add-ins work because they are usually wrapped up in a neat installer. For the benefit of those who are not aware, let me explain what actually happens. A developer creates an add-in (basically a DLL) which is copied to the end user’s computer by the installer. The installer also registers the add-in with the SolidWorks installation on the end user’s computer by adding certain information to the registry. The installer also copies supporting DLLs and other files that the add-in needs at run-time.

When everything is set up the user goes ahead and invokes a command added by the add-in by clicking on a menu item or toolbar icon which was added by the add-in during it own startup. Now in the case of SolidWorks as a Service, SolidWorks is installed on the server, or rather on all the servers on the server farm. The user does  not get to pick the server that he wants to run his SolidWorks off. So this means that exactly the same version of each and every add-in created by each and every developer must be installed and registered on each and every server on the server farm.

While this is logistically idiotic but theoretically possible, it throws the concept of third party add-in licensing into the shit pit. At SYCODE, we tie the license for all our SolidWorks add-ins to the user’s network card or MAC address. Other developers tie their licenses to the hard disk ID or some other fixed parameter or combination of parameters that uniquely identifies a computer. I have absolutely no idea how to control the licensing of my add-ins on a server farm. I guess add-in developers would have to piggy back on the licensing mechanism employed by SolidWorks.

And what about add-ins developed in-house by users? They would need to be installed and registered on each and every server on the farm as well, with SolidWorks somehow making them invisible to everyone else.

One way of solving this problem is by having add-ins installed only on some servers and keeping a track of which servers have which add-ins. Whenever a user invokes a command from an add-in, control can be passed to that server which will then execute the command in the add-in on the user’s data. But this brings up a chicken and egg situation because the user interface to invoke an add-in is added by the add-in itself. However, in reality none of this even matters because the user interface for an add-in would need to be added to the user’s browser window or whatever the hell that the user is using to run SolidWorks off a server. Basically, this whole concept of having add-ins run off SolidWorks installations which in turn run off servers on a server farm gets convoluted to the point of stupidity. And hence I call SolidWorks as a Service an idea which is completely nuts.

And speaking of passing control, here is some more food for thought. When you pass control from the SolidWorks instance on one server to the SolidWorks instance of another server, you need to remember that along with control you also need to pass the data that needs to be worked upon, basically the 3D models and the recipe that is used to cook them up from scratch (the history based feature tree) along with all related information like materials, etc. To get an idea of how much data that is, try loading a large assembly and watch your computer grind to a halt. Passing control between servers is not as easy as flipping a switch on one and flipping it off on another.

Like I said, completely nuts.

  • Matt Lombard

    It’s refreshing to hear common sense real talk about this topic. I’m tired of the dreamers who are instantly enamored with any method so long as it is not available today.

    Some software developers want to push saas because it resolves all future licensing conflicts in their favor. It also eliminates the distribution expenses, and will drastically reduce tech support due to local issues like installation, video card drivers and a million other things. The server farm initial and ongoing expenses have to be significant, but I’d guess worth it from their point of view.

    In the end, there are people at SW who are smart enough to see the obstacles, but they’ve got a business guy out front, not someone passionate about technology, and I don’t think he can answer questions like yours on his own. If he had passed you on to Austin O’Malley or Paul Chasteen or one of a number of other folks, you would have stood a better chance at getting a thought out answer. I’m glad to see I’m not the only one they pass to inappropriate people.

    I believe whether it works or not, SolidWorks is going to try saas. They already use Citrix to allow users to test alpha software without needing to install it. Using Citrix to power an application across the web is not responsive enough for a guy sitting there doing it 8 hours a day. As you point out there is no way (and I would argue no reason) to convert the entire user base to saas, but I think even with all its limitations, it might serve a useful purpose for select users. Some may even pay extra for it. The “scalable” part of the equation may not be as important as it first seems.

    SW has several tools that work in the cloud already, like 3D Content Central, 3D Instant Website, eDrawings, Drawing Tube, Blueprint Now, and Drawings Now. It is possible that they don’t intend to take the core product to the cloud, just several of these ancillary collaboration tools. When it comes down to it, I don’t think SW in the cloud makes much sense for most users. If it has any usefulness at all, it is for a small niche.

  • Matt Lombard

    It’s refreshing to hear common sense real talk about this topic. I’m tired of the dreamers who are instantly enamored with any method so long as it is not available today.

    Some software developers want to push saas because it resolves all future licensing conflicts in their favor. It also eliminates the distribution expenses, and will drastically reduce tech support due to local issues like installation, video card drivers and a million other things. The server farm initial and ongoing expenses have to be significant, but I’d guess worth it from their point of view.

    In the end, there are people at SW who are smart enough to see the obstacles, but they’ve got a business guy out front, not someone passionate about technology, and I don’t think he can answer questions like yours on his own. If he had passed you on to Austin O’Malley or Paul Chasteen or one of a number of other folks, you would have stood a better chance at getting a thought out answer. I’m glad to see I’m not the only one they pass to inappropriate people.

    I believe whether it works or not, SolidWorks is going to try saas. They already use Citrix to allow users to test alpha software without needing to install it. Using Citrix to power an application across the web is not responsive enough for a guy sitting there doing it 8 hours a day. As you point out there is no way (and I would argue no reason) to convert the entire user base to saas, but I think even with all its limitations, it might serve a useful purpose for select users. Some may even pay extra for it. The “scalable” part of the equation may not be as important as it first seems.

    SW has several tools that work in the cloud already, like 3D Content Central, 3D Instant Website, eDrawings, Drawing Tube, Blueprint Now, and Drawings Now. It is possible that they don’t intend to take the core product to the cloud, just several of these ancillary collaboration tools. When it comes down to it, I don’t think SW in the cloud makes much sense for most users. If it has any usefulness at all, it is for a small niche.

  • Matt:

    Though people often use “cloud” in a general sense, “cloud computing” is a bit different than merely having an application run on a web server. Check out Amazon EC2.

  • Matt:

    Though people often use “cloud” in a general sense, “cloud computing” is a bit different than merely having an application run on a web server. Check out Amazon EC2.

  • Guys.. valid points here, but I think you may be getting caught in the details and viewing software as it stands today.

    3rd party add-ins could be handled. The “licensing” would be based off of the the user’s login to the “service” Look at salesforce.com. They do this exact same thing every single day. They have 3rd party applications and customized parts of the code that are turned on/off, instantly. It is actually super convenient as things can be accessed instantly- as opposed to waiting for an installation.

    Sharing of files -step, iges etc could be transferred differently than they are today. Today, we email them back and forth. But, you could easily have a “file sharing” mechanism in the cloud. Bandwidth gets faster and faaster every day. So, I agree, today’s bandwidth may be a drag a bit. But there is absolutely a solution to this problem.

    Deelip mentions “healing” etc and SW being an eng application. Agree- even more reason that a cloud based approach could bea possible solution. Imagine that you have numerous machine, processors and RAM available as you need it. All of the kinks are not worked out completely but HPC in the clouds is coming and will give us more horsepower than we ever dreamed of having on a desktop today. Unfortunately, Amazon EC2 isn’t designed to run in parallel like this, but it isn’t to say someone else could solve this as well.

    I agree with Matt that we aren’t at a point that a guy driving SW 8 hours a day can expect seamless responsiveness. But I don’t think we are that far away from bandwidth, graphics, processor performance to be up to the challenge to make this a reality.

    My point in all this is that there are numerous benefits to SaaS in the CAD world. I don’t believe the technology is quite there yet, but we’re not far away from it.

    derrek

  • Guys.. valid points here, but I think you may be getting caught in the details and viewing software as it stands today.

    3rd party add-ins could be handled. The “licensing” would be based off of the the user’s login to the “service” Look at salesforce.com. They do this exact same thing every single day. They have 3rd party applications and customized parts of the code that are turned on/off, instantly. It is actually super convenient as things can be accessed instantly- as opposed to waiting for an installation.

    Sharing of files -step, iges etc could be transferred differently than they are today. Today, we email them back and forth. But, you could easily have a “file sharing” mechanism in the cloud. Bandwidth gets faster and faaster every day. So, I agree, today’s bandwidth may be a drag a bit. But there is absolutely a solution to this problem.

    Deelip mentions “healing” etc and SW being an eng application. Agree- even more reason that a cloud based approach could bea possible solution. Imagine that you have numerous machine, processors and RAM available as you need it. All of the kinks are not worked out completely but HPC in the clouds is coming and will give us more horsepower than we ever dreamed of having on a desktop today. Unfortunately, Amazon EC2 isn’t designed to run in parallel like this, but it isn’t to say someone else could solve this as well.

    I agree with Matt that we aren’t at a point that a guy driving SW 8 hours a day can expect seamless responsiveness. But I don’t think we are that far away from bandwidth, graphics, processor performance to be up to the challenge to make this a reality.

    My point in all this is that there are numerous benefits to SaaS in the CAD world. I don’t believe the technology is quite there yet, but we’re not far away from it.

    derrek

  • Derek,

    Licensing is not the only issue with add-ins. In fact, licensing is the least of the problems. Third party developers have their IP stored in DLLs which are called by the add-in DLL. Moreover, we also license DLLs from other component developers and pay them royalties. Its way too complicated as compared to something like salesforce.com.

    My point is that for my add-in to work, SolidWorks would need to give access to their servers for me to do my thing. Either that or bundle my add-in along with the SolidWorks application itself. And we know that that is not logistically possible for each and every add-in that has and will be developed.

    Add-ins in the cloud is a huge problem, something that even blazing fast servers and internet connectivity may not be able to solve for a long tiem to come. It is more of a logistical problem and less of the technological problem.

  • Derek,

    Licensing is not the only issue with add-ins. In fact, licensing is the least of the problems. Third party developers have their IP stored in DLLs which are called by the add-in DLL. Moreover, we also license DLLs from other component developers and pay them royalties. Its way too complicated as compared to something like salesforce.com.

    My point is that for my add-in to work, SolidWorks would need to give access to their servers for me to do my thing. Either that or bundle my add-in along with the SolidWorks application itself. And we know that that is not logistically possible for each and every add-in that has and will be developed.

    Add-ins in the cloud is a huge problem, something that even blazing fast servers and internet connectivity may not be able to solve for a long tiem to come. It is more of a logistical problem and less of the technological problem.