I want to continue the theme of how do we move to the cloud. While Amazon remains one of the major providers of elastic computing services, other options are emerging too. If you consider to move your PLM initiatives to the cloud, you might do some analysis about how actually cloud PLM can be made. Few weeks ago I was talking about large manufacturing and public cloud. Public cloud is an interesting option. At the same time, regulated manufacturing and companies with significant security restrictions can question this path. One of the alternatives for these companies can be just announced Azure Cloud System from Microsoft/Dell. It will take time for PLM vendors to support it, but Cloud PLM In Azure Box can become a reality soon.
Today I want to speak more about some trends in cloud computing and how it can be related to you future cloud PLM project. Remember my article What cloud PLM cannot do for you? The biggest achievements of cloud PLM today is removal of IT hassle and complexity. With cloud PLM you don’t need to think about servers, installations and even upgrades. However, here is the thing. The number of cloud applications is growing. Application lifecycle is getting more interesting these days. Large enough company can easy face the situation of management of multiple clouds – public and private at the same time. Complexity of manufacturing organization, supply chain, security or other IT-related reasons can easy bring you to such situation. These are not simple questions and it is very important to create a right strategy for your IT organization managing cloud PLM and other application providers.
You can consider “devops” as a new buzzword. It comes from a combination of “development” and “operations”. Bricks and mortar PLM software vendors were doing development only. They developed, tested and shipped CAD, PDM and PLM software on CDs and you had to hire IT specialists to install, configure and run it. Now, it is different with cloud software. By removing IT hassle from customer, software vendor is taking a role of IT too. It created a new paradigm of development+operations together. Think about engineering and manufacturing. They have to go together to make it work.
InfoWorld article Devops has moved out of the cloud speaks more about devops trend. I like the way it makes demystification of cloud by explaining how the same infrastructure can be used for both cloud and non-cloud development and IT environments. It also helps you to understand the importance of operation to achieve the quality of cloud services. Here is my favorite passage:
Many people attribute the rise of devops directly to the growth of cloud computing. The connection: It’s easy to continuously update cloud applications and infrastructure. For example, a SaaS application typically requires 1,000 lines or more of changed or added code each time you use it. Its functionality is continuously updated, which makes the cloud-delivered application, platform, or infrastructure more valuable to the users. Gone are the days when you received CDs or DVDs in the mail and had to manually update the servers. Although the cloud is certainly a better place for devops, I don’t believe that devops should be used only in cloud deployments. Instead, you should use devops approaches and enabling tools such as Puppet or Chef in most of the development you do these days — both cloud and on-premises.
We need to thank Amazon EC and other IaaS vendors for incredible success of cloud computing we have today. However, technology doesn’t stay still. For the last decade public web companies learned many lessons how to manage infrastructure and software development on demand and on scale.
Kubernetes is an example how web companies can scale using cloud infrastructure. Navigate to ComputerWeekly article – Demystifying Kubernetes: the tool to manage Google-scale workloads in the cloud and spend some time even you will consider it a bit technical. In a nutshell it speaks about new technology of cloud deployment – containers, which comes to replace well-known VMs (Virtual Machines). Here is the most important passage in my view:
Kubernetes and Docker deliver the promise of PaaS through a simplified mechanism. Once the system administrators configure and deploy Kubernetes on a specific infrastructure, developers can start pushing the code into the clusters. This hides the complexity of dealing with the command line tools, APIs and dashboards of specific IaaS providers. Developers can define the application stack in a declarative form and Kubernetes will use that information to provision and manage he pods. If the code, the container or the VM experience disruption, Kubernetes will replace that entity with a healthy one.
While it may sounds too complex, the key issue here is related to the lifecycle of complex cloud PLM environments. At the end of the day, cloud PLM vendors will have to manage updates, introduce new features, maintain data and more. This technical example can show you the gap between new type of cloud infrastructure and opportunity to move an existing PLM server from your server room to the cloud.
What is my conclusion? We should move beyond “cloud PLM” buzzword. Enterprise software vendors are moving from shipping CDs towards selling software services. It simplifies customer experience, but creates new layers of complexity in vendor’s organization. It moves software development to devops and creates technologies that capable to manage application lifecycle easier. It ends up with the quality of PLM cloud service. Keep it in mind when you evaluate you future cloud PLM project. Just my thoughts…