Cloud = Cloud?

How is it possible to differentiate #cloudnative from cloud-enabled #CAD, #PDM and #PLM solutions?

I look at this questions with a PLM and a CAD view. Classical PLM vendors often omit the CAD focus, as they regard sometimes CAD authoring systems as tail of the PLM dog. In fact, the CAD authoring system delivers the value of a physical product. Eighty percent of the costs and advantages of a product are determined in early CAD design phases. CAD & PDM shapes the product, PLM & ERP brings it to life, to the customer, to the market. PLM and CAD & PDM are equal sisters/brothers.

If the vendor ports his old architecture to cloud services, you run with some restrictions the old C++ monolith(s) on the cloud. If a total new system is designed in the cloud, you first, as vendor, must invest much. You do not use too much code from your +30/40 years heritage software. Second, as user and consumer, you profit much from an unrestrained real cloud app, a cloud-native solution. Pictorial said: You cannot reach the moon with a horse coach. For ambitious goals you need fresh and innovative technologies.

Hereby an overview table and below some details of my thoughts about the table items.

Cloud-enabled systems are those, which are ported from their On Premise world with some cloudification into the ?Cloud world". Their historical, often 30-40 years foundations are not changed significantly. Cloud-native systems are new and have their foundations 100% in new cloud architectures.

Points for differentiation in detail

?? Cloud Hosted

User access to services is device-independent through the browser. This can be an On Premise system virtualized in the cloud or a cloud-native system.

?? Built into the cloud

It is hard to differentiate cloud-enabled from built into the cloud systems.

Have a look at the architectural descriptions of the "cloud-native" systems, you are considering. If there is none, be suspicious. Here three examples of public descriptions of cloud-native systems: e.g. OpenBOM, Onshape and Arena PLM.

Some hints helping to identify cloud-native architecture.

1. Cloud-native Architecture

Cloud Architecture versus monolith programming architecture: ?Cloud-native software architecture is a design approach where applications are built and deployed to leverage the advantages of cloud computing. It typically involves using containerized applications, microservices, and dynamically orchestrated infrastructure. This architecture allows for scalability, flexibility, and efficient utilization of cloud resources, enabling rapid development, deployment, and scaling of applications. Key components include containerization platforms like Docker, orchestration tools like Kubernetes, and a focus on principles such as resilience, scalability, and continuous delivery. “ (Explanation ChatGPT of cloud-native architecture)

2. Multi Tenant Database

Another feature is that the basis is a multi-tenant database. This means that the cloud service provider can provide its service to many companies at the same time via one cloud instance. He only has to manage one instance and not many. The effort and costs are therefore significantly lower.

3. Multi Tenant Database Scheme

This is a capability to share data in real time between one company to another company. Like you can share a Google Doc between multiple company accounts, you can share cloud-native CAD documents (Onshape) between multiple company accounts, and you can share data in real time with a cloud-native PLM solution between multiple companies. This is not possible with a multi-tenant architecture that doesn't have multi-tenant data schema.

The multi-tenant architecture and scheme is very well described in some articles in the #BeyondPLM blog of Oleg Shilotkovsky: https://beyondplm.com/2023/10/22/cloud-technology-and-plm-in-2023-navigating-the-future/

3. A simple indicator is….

If a system is built into the cloud, there is no On Premise version available. If a system is available as On Premise or Client/Server and a cloud version or it has a predecessor from the old world, it is highly likely not of cloud-native architecture.

Advantages of cloud-native

Cloud-native Architecture can lead to the advantages, described in the next points. Cloud-native is either the prerequisite or an advantage to reach these goals easier, cheaper, quicker.

?? Any device

The new paradigm of design is written on the Cloud wall: Access to data any time, from any place with any device. Device independence is the key.

With this independence you can create a platform for teamwork, with iterative inclusion of all stakeholders, e. g. customer, supplier, or colleague in any phase of product development.

A modern cloud architecture frees me from the prison of operating systems, service packs, hardware restrictions and in case of CAD and FEA, provision of huge local computing power. Simply connect - through the WEB in your browser or app on your mobile device.

?Any device“ can work also with cloud-enabled solutions. The CAD client or the former PLM Thick Client can run as On Premise app virtualized in the cloud. A certain hardware independency is there, but not fully. There is possibly no adaption to mobile and touch devices. The application remains, what it is, an On Premise instance without cloud-native characteristic like crash resilience, scalability, continuous, unnoticed update etc.. An example: I have tested recently a virtualized On Premise instance streaming on my Notebook. It crashed during a load test with a Windows error message from the cloud server.

?? Fast start & openness, API, Integrations

A contemporary foundation has great advantages. Modern architecture makes it easier to create out-of-the-box and easily customizable solutions. Fast start - start the new application immediately, without any startup efforts. Openness means an open system (not closed to own apps like for instance in the 3DEXPERIENCE platform), a good API connection, e.g., REST-API. Integrations are easier to create. It means inside a cloud-native architecture an easy connection to other loosely coupled cloud-native entities (see architecture paragraph before).

A cloud-enabled system based on old architecture can also be ?out-of-the-box"-able and easily customizable. The efforts to reach this is for traditional monolith software vendors higher than in a modern cloud-native environment.

?? Minimal maintenance and continuous release without downtime

There are some hybrid cloud offerings with virtualized On Premise apps on the cloud and connected also to desktop solutions. They have downtimes, when delivering major releases or service packs. This costs time, needs more efforts from vendor and customer side and is therefore more expensive.

A true, well designed cloud app processes all updates in the background while you are working. There is no downtime. An update is no longer a nightmare. Everyone always uses the same compatible, latest version.

All this is due to restrictions of the old architecture not possible with cloud-enabled, into the cloud lifted traditional systems.

?? Highly scalable

The cloud-native architecture makes it easy to scale computing capacity. As more users request more services and computing power, servers are added. A traditional monolith cannot scale like that. This scaling is more cost-effective than constantly maintaining high computing power. The advantage for the user is higher performance and high computing power when it is needed.

Traditional, cloud-enabled systems can only be scaled with the help of your wallet. If you need high performance due to heavy CFD calculations once a month, you must run a compromise between your daily lower CAD needs and the seldom high CFD need. Or you decide to open your pocket wider and buy hardware, which runs from computing power perspective mostly idle.

?? No crashes

Cloud-native software can better handle failures by healing itself or jumping onto another resource. Every process has running one in the background. It takes over in the case of failure. To the user the software never crashes. That is not completely correct. He just doesn't notice the problem, loses maximum the last record sent and therefore doesn't suffer from data loss. Cloud native solutions have better parachutes.

Monolith C++ architectures, cloud-enabled solutions are not crash resilient. When they rush against the wall of an error the whole program crashes. The program part, which has some trouble, pulls the rest into the crash hole.

?? High Security

Servers from reliable cloud providers are more secure than on-premise servers. In a purely cloud-native environment, only commands are sent back and forth. In opposite to client/server architectures or hybrid cloud architectures storing data on a client: Nothing is stored or saved locally. With Onshape CAD for instance, all geometry and metadata are in the database. There are no files. The intellectual property never leaves the “Fort Knox” of the multi-tenant database.

Cloud-enabled solutions are from cloud server side secure as cloud-native. They use the same infrastructure at AWS, Microsoft or elsewhere. They loose this security level, when acting with local cache, local copies for supported On Premise solutions.

?? Support, services, and educational resources

It is easy for a cloud app vendor to analyze crashes and inconsistencies. He has direct access to the IT process and (with permission) to the data (e.g. CAD). The vendor of an On Premise solution must get Logfiles and/or access to the customer files or database, which can be very cumbersome. Service can be integral part of a cloud-native offering, leveraging the customer experience very much. For the cloud-native provider it is easier because he hosts all user activities. Cloud-enabled solutions rely in their service often also on local, far away computer resources.

Cloud-enabled PDM or PLM solutions support On Premise CAD with above described challenges. The problem remains the same.

Educational Resources for self-learning and leveraging productivity with on demand tutorials are easier to handle with cloud solutions. You can provide as a vendor tutorial material as it is available, ad hoc. On Premise solutions can provide same level of material, but they rely on the version and service pack cycle. Many customers leave out versions and service packs and therefore get not the advantage of the new versions and educational resources in time.

?? Leveraging agile teams to more and effective collaboration

Often the view on agile teamwork is reduced to the ?one source of truth" story. This is only half of the story. A consistent view on released or in work design data, like CAD files, current bill of material etc. works already a long, long time... with PDM and PLM tools. So, it is nothing new to bring this functionality into the ?new" cloud app. New is to connect teams with agile collaboration concepts better in evolving design periods beyond any formal version or revision driven rules. Here three aspects from authoring system level, which illustrate the potential power of real cloud, Cloud-native. And these close the circle: This works in total only in a cloud-native architecture with Multi-Tenant Database and Database Scheme.

.

Easy and safe sharing design data

Running only on the cloud and having all data, geometry, and metadata, at one place, you can share much more easily data for collaboration. No copies of files are sent into unsecure ?nowhere". No cumbersome check-in and check-out procedures and IT and security system burdens make cooperation harder. Only write, annotate, read based WEB links make the collaboration life very smart. This works smarter with a platform relying only on databases and no files anymore.

Cloud-enabled CAD systems can work, when storage is a WEB based PDM, with the link option. But anyway, due to file architecture the disease of local copies remains.

Parallel multiuser access to a common dataset

CAD systems are running since decades on files. Files are not good for teamwork. They make sharing hard and dangerous (data security) and parallel working with write access on one CAD design object with a few stakeholders is impossible. CAD and metadata (PDM) should reside together in one modern database. Modern ones are not RDB (Relational Database). A non-SQL database like MongoDB is the better foundation.

This is not possible with the underlying traditional architecture of cloud-enabled systems. A file system cannot have a Multi Tenant Database Scheme.

Easily test design alternatives

Like in software development splitting a design into different options (branches), to test different ideas, leverages an agile process. If running in a multiuser database, this can be done in an agile team for instance in a sprint of a Design Thinking session. Easy merge of best solutions in the main branch results in a better design result.

Principally this can be realized in a file based CAD system, too. I am only aware of one such implementation. It is Creo+ from PTC, branching & merging in a cloud-enabled environment with multi user real time access in assembly mode, based on Onshape technology.

Wrap Up

Every technical decision should rely on trying to find a solution covering most of your needs. You are often not aware about all your current needs and not the future ones. Therefore, considering the architecture of the anticipated solution is important, too. A solution built on a new, agile foundation has highly likely more potential for covering unknown and hidden needs and has very sure a longer lifespan than the IT dinosaurs from the past.

Cloud-native beats cloud-enabled.

.

.

Thanks…

…to Oleg Shilovitsky from #BeyondPLM and OpenBOM and George Lewis from Arena by PTC . I used some valuable thoughts from them, have a look here:

https://beyondplm.com/2023/12/29/2024-plm-technology-selection-deconstructed-a-guide-for-plm-tech-architects-and-decision-makers/

https://www.ptc.com/en/blogs/plm/how-cloud-native-solutions-transform-product-development

Good resources…..

….can be found easily. Very competent and reliable informations can be expected from providers of cloud services. Here a good article from Amazon Web Services (AWS): https://aws.amazon.com/what-is/cloud-native/?nc1=h_ls

Good quote from this article: ?A cloud-enabled application doesn't have the flexibility, resiliency, or scalability of its cloud-native counterpart. This is because cloud-enabled applications retain their monolithic structure even though they have moved to the cloud.“