Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Cloud upgrade schedule...
I have an interesting question. The question was about the impact of automatic cloud upgrades on a production schedule.
In the aerospace industry I personally have experienced situations where our normally scheduled upgrades we put on hold because of schedule requirements. The program either had aggressive dates or had situation where they were making a final focused push to hit deadlines and were worried that any upgrade issues or even just changes to the software or infrastructure could cause them to miss the deadline.
Also we usually plan in advance the roll-out date and give the users training on changes or new functionality. With cloud upgrades it seems like there in no forewarning about a coming upgrade and no prior exposure to what is going to change. Coming in on Monday morning expecting to hit a Tuesday morning deadline and finding out your CAD system is different is an interesting concept for those managing schedule.
Anyone else been asked this? How did you respond?
In the aerospace industry I personally have experienced situations where our normally scheduled upgrades we put on hold because of schedule requirements. The program either had aggressive dates or had situation where they were making a final focused push to hit deadlines and were worried that any upgrade issues or even just changes to the software or infrastructure could cause them to miss the deadline.
Also we usually plan in advance the roll-out date and give the users training on changes or new functionality. With cloud upgrades it seems like there in no forewarning about a coming upgrade and no prior exposure to what is going to change. Coming in on Monday morning expecting to hit a Tuesday morning deadline and finding out your CAD system is different is an interesting concept for those managing schedule.
Anyone else been asked this? How did you respond?
1
Comments
Our engineering team invests a huge amount of time and effort making sure that we don't break existing functionality, but we definitely do make changes to the way things work. We think this is vastly preferable to waiting 12+ months for new features, bug fixes and improvements. Providing "CAD as a Service" also gives us the ability to squash a software bug out of existence in a matter of hours. Try that with installed software.
Are you mostly concerned about behavior changing with existing documents or all documents in general? Would it be useful to have specific existing docs not change behavior for some number of days after a software upgrade until your schedule allowed it?
I've been using OS for over a year and it's never broken, it's just getting better.
John Rousseau-
-If I find a critical error, how fast can you deploy a new quality certified stack (minutes, hours, days)?
-You could make an old stack addressable so people can stagnate around it. Maybe larger companies might like this. I hope you charge a ton of money for this option hoping it never becomes desirable or necessary.
Its obvious that there are HUGE benefits to CAD as a service...with support, with enhancements, and with bug fixes. I think these question are coming from folks that have their legacy enterprise support hats on.
It would be interesting to have some sort of "freeze updates" toggle on a document for a smaller shop that may have something seriously important to get out the door. A document toggle would buy them a week or two.
A followup question was asked .... Will Onshape plan on making entire private environments as a service to larger companies. Still as a service. Still in the cloud. But with only the companies data in the tables. And dedicated hardware/virtual hardware reserved for that company .... also allowing the company the decision point on when to migrate to the next level.
To date, the functionailty and complexity of use of Onshape is relatively basic compared to established systems like SolidWorks. Sure, you get some users who have switched but I would suggest most Onshape users are on the free system and playing rather than doing heavy duty tasks.
In such an environment, you can do live updates and most users will thank you as they gain functionality. However, when a platform matures and the incremental changes become more workflow based rather than functional, you simply cannot go changing how a platform works overnight. Literally.
let us look back to CAD history, to a time when the Onshape team ran SolidWorks. 2008 and the infamous interface change. Now I actually liked that change, but most did not. That change was tweaked after several months of beta testing, yet it still released to ridicule and a chock full of bugs that took several service packs to stabilise.
Now move forward a few years, to a time when Onshape has a few hundred thousand paying users, using it for serious, life critical applications. So design team at Acme have a big presentation to XYZ. They go in, and overnight find Onshape has been updated. Something in the update has screwed up something in their files that was not picked up by the in house testing team and bots. Worse, all their files are on the Onshape cloud database. They are, screwed.
back in traditional CAD land, users choose when to update, so they tailor the process around workload. Makes sense, right? Back in traditional CAD land, if the update reveals a hitherto unseen bug they can choose to revert to the previous version and continue to work. Back in traditional CAD land, they have access to their files, so worse case, they can open their (SolidWorks) files in (Inventor/SolidEdge/Creo etc) and use them.
these are all real issues faced by users every single day. I see the benefits of cloud systems. I use cloud systems in my business every day. But do not underestimate the damage an update can do if the users are not expecting it. Onshape is a history based modeller. That brings lots of benefits but it also makes upgrading harder and harder as time goes on as you need to ensure your files work and rebuild properly.
as Onshape starts to be used for the types of applications people rely on mainstream 3D CAD for, these issues will come to the fore, and the Onshape team knows this. They did, after all, run SolidWorks for years. SolidWorks is a fantastic system. I know, I have a couple of licenses. But here's the thing. I pay to stay on subs, but I dont move to the new version mid projects. Even in our little business I test things then we move.
anyone who thinks Onshape has some magical solution to this is naive. As Onshape develops they will hit the exact same issues SolidWorks does, but the users will have no back up plan. This is probably an uncomfortable post to read for some, and no doubt will get lots of responses, but unless Onshape instigates some form of upgrade delay this issues is a very real and very serious one for those users who need 3D data to be reliable.
Just ask Boeing or Airbus.
Thanks
_Ðave_
I think with a critical bug fix and a couple of hours turn around, this cloud based system will be able to keep most engineers happy. I'm not worried. My goal is to use a system that just works, I don't want to maintain it, time it, fiddle with it, install/uninstall it.
I was thinking last night that OS should charge for hosting older versions so larger companies can keep their stabilized concepts and controls in place. This could be an additional revenue stream for OS to charge more as the code gets older and maintaining versions of old build stacks. The irony comes from paying for old code vs. buying new code. This would flip the industry upside down.
I do worry about the existing software distribution model. After working with SW2016 and realizing the issues in the code, I wish I could go back to a previous version. It takes weeks/months to figure out if a new release is stable and deciding if switching was a good idea. This has always been hit/miss. You just learn to adapt, like learning what all the black/white icons look like. Kevin, I don't think your world is any better. I live your life too, I'm hoping for something better. How many versions of SW do you have on your computers? I get it, this is the solution we know.
I guess I'm hoping for a better solution and haven't committed to damning progress.