Cloud adoption is about discovering the underlying patterns and infrastructure frameworks needed.
In our previous blog, I talked about the essential factors that a company must consider in leveraging cloud resources to accelerate their goals. The objective here is not just about putting some of the workload in the cloud; rather, it is about realizing the transformation adopting cloud technologies will bring about. In particular, it is more important to think of the cloud not only as a set of infinitely scalable services and resources but as the underlying technologies and best practices that can be adopted as a framework for your software architecture in general. While I don’t mean to belabor the point, adopting the cloud in a manner where it can truly unlock operational efficiencies and leverage its advantages is truly an organizational change.
You’re unlikely to see the phrase “we want to use cloud more” in any organization’s strategic plans. However, the cloud can play a strategic role in expediting innovation; optimizing and reducing IT costs; helping a company meet the scalability demands required as new services, products, or markets are launched; and making data accessible and actionable across disciplines in the organization. The cloud can assist with predictive maintenance, supply chain transparency, testing, quality, process automation, and smart manufacturing. The chart from Accenture below captures the broad areas where the cloud can be leveraged easily in support of an organization’s goals (figure 1).
Fig 1: The many ways the semiconductor industry can utilize the cloud.
Given the nature of the semiconductor business and the requirements for how data and IP must be protected — and how and where data is stored and shared — picking the right cloud platform is key. One important aspect to keep in mind: software in the semiconductor manufacturing process has real-time, near-time, and offline needs.
From run-to-run to fault detection, offline defect classification models, and defect review, companies leveraging the cloud have to accommodate edge, fog, and cloud deployment models. There are several options available: public, private, and hybrid. There are even companies that will make hardware available to enable you to build a “cloud” on-site.
Leaving aside non-SaaS business applications, the number of applications supporting manufacturing activities are likely to be numerous. As such, a company’s choice of infrastructure is equally important. If the right choices are made, this infrastructure will enable you to “deploy on a fabric,” as it were, agnostic of the cloud provider you choose. This is a decision you will have to carefully evaluate, given your needs, future demands, and any relationships you might have with cloud providers.
Efforts that are labeled “push to cloud” most often fail to capitalize on the potential that can be realized from the cloud. The main culprits are the usual suspects: underestimating the effort involved, a lack of strategy, a lack of collaboration and coordination, a lack of platform, missing on-ramps, a lack of standardization, etc. For example, deploying a yield analysis system in the cloud without a centrally orchestrated platform will get you just that — a yield analysis system in the cloud and the aggravation of having to repeat this exercise with the next application all over again! A better approach is to work across departments from a technical and end-user perspective, lay out a framework for adoption and upskill people as necessary.
Cloud security is a shared responsibility, and while tools and checks are offered, it is up to the customer to ensure a proper roll-out and ongoing enforcement. Your organization should have a well-articulated security posture as you adopt cloud services and infrastructure. Remember to engage your chief security officer. And start understanding your role and responsibilities. As security practices evolve, you can immediately implement updates consistently and correctly.
Make sure your cloud transformation starts in small, meaningful steps. A cloud adoption is not only about taking applications, e.g., a machine-learning module that predicts tool failures or a dashboard that pulls data from a system and notifies you, it is about discovering the underlying patterns and infrastructure frameworks that are needed and that progress as you take your on-premises workload and migrate it to the cloud. In essence, you are creating a blueprint for other products, applications, and areas to follow.
The concerns that semiconductor industry companies have about cloud costs are similar to the concerns of other industries. The general rule is “use what you pay for” in response to the cloud’s model of “pay for use.” Most cloud providers have transparent billing policies, upfront estimations, alerts and, most importantly, available automation to help you manage resources and resource usage effectively. A simple example: if you are deploying an offline yield analysis system, its deployment footprint and scaling requirements might be known up front. With this in mind, ask yourself if it might be better to use the cloud via reserved instances or on-demand? Another example: while storage costs are very cheap, when you store and transfer petabytes they quickly add up, and so the question becomes how do you use tiered storage effectively to reduce costs?
One of the keys to implementing a successful cloud transition is to think about how your company will use the cloud in the future. Ask yourself, what services will you leverage and what will require standardization? There are too many factors to list them all here, but to meet the use cases, you will want to adopt the right open-source/paid-infrastructure technologies and best known methods. Doing this is critical to how quickly adoption will happen.
Transitioning to the cloud is not the responsibility of a single department. Applications in the cloud benefit the entire organization. While I alluded to the “technical” side of the culture change in my last blog, the end-user side is just as, if not more, important. Deploying a tool failure prediction system to the cloud is not very useful if you have not worked with manufacturing to get them comfortable with data flows. The cloud also will not be of much use if data flow is intermittent or worse, manual, and alerts are not broadcast reliably or at the point where they can be consumed easily. Leave it to developers and end-users to accelerate innovations and create problem-solving applications and let the cloud and cloud technologists worry about the rest!
While you may not have direct say in the architecture of a vendor’s product, you should still be able to ensure that it fits with the cloud framework you have laid out. The goal is not just to get a defect classification or yield management application deployed in the cloud, the goal is to make sure the cloud operates in a way that is understandable and manageable.
There are several factors that come into play in selecting the vendor and the vendor’s software that are different from an on-premises deployment. At the one extreme you can argue that it is just vendor software — does it really matter how they deployed it? I would argue that having a vendor that has experience in either hosting or deploying to the cloud is essential. In addition to this, deployment methods, pipelines to the cloud, security architecture, no drift, resiliency, monitoring, alerting, automation aspects are important.
As more and more companies consider cloud transformations, there is a great deal to consider before that journey begins. I hope that these two blog posts will help make that journey easier for you and your company.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply