Buy or Build? MLOps Adoption in Corporations and Startups
As we continue to engage with industry we’re noticing different approaches to establishing Machine Learning Operations (MLOps) programs between larger corporations and smaller start-ups. This article discusses the key factors at play as companies of all sizes try to decide how to apply MLOps to their unique situations.
Naturally, larger corporations tend to be older so they started thinking about MLOps at an earlier date than most startups. The attitudes and industry understanding of MLOps is very different now than it was 5 years ago, which in turn was also very different than it was 10 years ago. In the early days, there was little distinction between a prototype and ML in production. A handful of Data Scientists might handle the entire process and there probably wasn’t much consideration for scalability, efficiency or operations in general. Essentially these early pioneers of putting ML into actual products didn’t have history to learn from - they were creating it. Figuring things out on their own is part of their corporate DNA and therefore they continue to look inwards for solutions as opposed to outwards.
In contrast, new startups have access to MLOps best practices since inception. Right out of the gate they may have founders or engineers with previous MLOps experience who ingrain these practices into the company DNA. They also have the luxury of deciding whether to build the infrastructure themselves or buy it as a 3rd party solution. This gives new companies the advantage of planning for an MLOps strategy that they can grow into, reducing their future technical debt. The flip side to this is that although they may be preparing for MLOps, they may not require it yet. The business case for a robust MLOps program is more compelling with growth and product maturity. Young ML companies may be in the model experimentation stage for a couple of years before deploying to production, and during this time MLOps can easily fall to the bottom of the priority list.
In large organizations, for example banks, the Data Science division is a single department of many and it often isn’t critical to the business operations. Banks have existed long before ML was invented, and the fundamental business model of a bank (taking in funds and loaning funds) has not changed significantly with the dawn of ML. Have financial institutions benefited from the predictive capabilities of ML models? Yes, absolutely, but if all the ML models in the world suddenly ceased to exist, banks would still carry on. This means the Data Science division of a large organization may be viewed as a “nice to have”, which could influence the attitudes from upper management. Making significant investments into non-business critical infrastructure like MLOps tools, may not be a priority for these organizations.
With the mass adoption of ML across many different verticals, we are seeing a new age of ML specialists. These specialists are companies have built a product or service that simply could not exist without ML. An example would be a company that develops robots that can visually detect items in an assembly line. Without the use of computer vision algorithms, these robots would not be able to do their job effectively and the company would not have a viable product. Since the success of these companies depends on having reliable and scalable ML, all levels of company management can appreciate the importance of a proper MLOps program leading to full organizational buy-in.
Economics of Build vs. Buy
Company economics can have an impact on how a company decides to invest in MLOps. Any team deploying ML to production will be grappling with the challenges of doing so, and they will likely be mulling over the “build vs. buy” question. There are many factors that can impact the decision to build one’s infrastructure internally vs. outsourcing it through 3rd party vendors. Some important questions teams should be considering include:
1. What is my budget for implementing MLOps?
For companies with limited budgets, it might make sense to bootstrap their MLOps implementation by leaning on open-source tools and the ingenuity of their teams. As the company grows or the ML program becomes more established, adopting enterprise-grade MLOps platforms starts to make economic sense. While you pay more for these platforms, they will shoulder the burden of your increasingly complex ML production process and provide the state-of-the-art in MLOps practices.
2. How quickly do I need to be deploying models?
If a company needs to get ML models into production quickly, sourcing 3rd party MLOps tools is the best option. These tools will be built, tested and proven, and typically require minimal energy to adopt. A Data Science team being pulled away from model development and tasked with building MLOps tools - which is not something they are typically trained in - is not good for business. However, if a company is planning for ML deployments that will be happening a year or more in the future, they may have the luxury of time to recruit the necessary team and piece together their ideal MLOps pipeline. This might be a completely custom, built inhouse solution, or a combination of inhouse tools and 3rd party integrations.
3. What type of skills and experience does my team have?
The choice to build MLOps in house becomes much more viable when a company already has software engineers with previous MLOps experience. Oftentimes we see Data Science teams being tasked with setting up MLOps pipelines, which is a flawed approach by management. There is a common misconception that since Data Scientists are developing the models, they should also be responsible for deploying the models at scale. In fact these jobs require very different skills, much like the engineers tasked with designing a new car are different from the engineers responsible for manufacturing the car. Hiring and training a team solely to build MLOps in house from scratch is likely not an economical path forward.
4. Will prebuilt options meet my requirements?
From a business economics standpoint, the “build vs. buy” scale tends to lean in favor of buying. This isn’t surprising because outsourcing non-strategic efforts is a common business practice across all industries. The one exception is when prebuilt MLOps tools simply do not meet some unique requirements of a company. This could be the result of the company developing some type of proprietary ML algorithm that isn’t compatible with standard processes and therefore requires bespoke infrastructure. The onus here is on the MLOps vendors to keep expanding the feature coverage of their platforms to ensure edge cases are accounted for.