Business, Technology

MLOps: Making Machine Learning Production Work

MLOps Making Machine Learning Production Work
MLOps Making Machine Learning Production Work
September 22, 2022

Read time 5 min

The term “MLOps” started gaining popularity around 2019. 

That’s when you saw Google search results for it really begin to climb (and in our modern world, that’s the true test of popularity and relevance). But in reality, the practice has been developing for years. At Reaktor, we’ve been working in the ML and AI fields for close to a decade, from smaller projects like creating pilots or prototypes, to much larger ones on the enterprise scale. One area where we’re uniquely qualified is bridging the gaps between machine learning and software engineering. And it’s no wonder why — our company was built on pushing the boundaries around software development. By bringing that expertise into the data field, we’ve successfully helped our industry partners use ML components to solve business and development challenges.


The Zeitgeist’s Double-Edged Sword

Desire for machine learning comes from the zeitgeist. For us at Reaktor, that’s thrilling. We love that a whole generation is wrapping itself around these technological developments. And we’re seeing its effects. Every day, we grow in our understanding around our ability to build things that were (nearly or entirely) impossible in the past. Thanks to natural language, computer vision, and/or huge amounts of data, we’re now able to make products more automated, or even create new services that wouldn’t have been able to exist before.

But it can also get tricky. Because machine learning and artificial intelligence are talked about so much, there’s the inclination to want to interject it wherever and whenever you can. That can prove costly and fruitless.

To combat this tendency, strategy is needed. At Reaktor, the decision to use ML components is always a natural one. We don’t utilize machine learning just because we can. We use it because we should. It’s a pragmatic approach that is founded on a very basic principle: only do something if it solves something. Therefore, we only incorporate ML if it’s an answer to a business or development question. Really, if most companies took a step back and looked at machine learning and artificial intelligence from the practical perspective they look at other elements of their organization (R&D or distribution, for example), they probably wouldn’t get swept up in making rash decisions and throw a lot of money and time into vague ML proof-of-concepts. The way Reaktor handles machine learning is gradual—we build and innovate solutions from the beginning, so that each step is thought-out and planned and can be incorporated into the whole seamlessly.

Reaktor & MLOps in Action

Because of our measured approach, we’ve come up with novel ways to help our clients incorporate machine learning and artificial intelligence into their products, as some of our ML/AI experts recount:

Timo Suomela

Software Engineer in ML Projects

Back in 2015, we built a recommendation engine for a large Nordic customer in the retail space. Our team included two data scientists, about five to seven developers, and some designers. The engine was built by gathering data from the existing systems that host the product, purchase, and customer data. We then created workflows that took that data either once a day or in real time to build a system in AWS that merged all of it into a data lake. From that we were able to have multiple tools that processed the data. The recommendation engine itself was a piece of Python software that also ran on AWS. It could create customer-specific lists of items that the engine concluded would be very likely for the customer in question to be interested in purchasing.

Ville Rantanen

Computer Vision Specialist

The whole industry of autonomous machinery is purely enabled by ML & AI. If you want to have a logistics platform, people walking, cars driving, and vision of all of that, you need intelligence that makes it safe. Currently a lot of companies are developing this with passenger cars or trucks, but as far as I know they’re only taking into consideration traffic and safety (with cargo being loaded manually). We wanted to create a new component that would also allow the truck to decide where it needs to go to find the cargo, and then load it itself. Robotics can pick up things in well-defined places, but we wanted this to work in unstructured spaces. This was basically adding one more layer to what computers can see and to teach it something new.

Henrik Aalto

Data Engineer & ML Specialist

In general, I think people get used to their ways of working and tend to make only minor improvements. But what’s exciting about ML solutions is they often allow for big changes, such as entirely dropping certain phases of development. For example, we had a client in the accounting space interested in just re-enhancing some tools. Then our team came up with the idea to inject ML components that allowed us to ditch certain things entirely. It changed everything, and from there we started building the future of accounting.

A Gap That Needs to Be Bridged

As machine learning has become a more and more powerful player, a divide has been created between data scientists and software engineers. The reason for this is clear when you examine their differences. Traditionally, data scientists come from a more research-oriented perspective, whereas software engineers have greater direct experience in industry and product building. That certainly affects how each group goes about their work and what motivates them. 

“It’s taken me a lot of time as a developer to understand what the data scientists really do,” says Timo. “From my experience, data scientists are not typically proficient enough in software development to see how it all adds up into a larger scheme.”

There are also inherent problems with workflows and how things are set up. “The challenges we face are not so much with technology, but with people and organizational aspects,” comments Henrik. “Developers are usually pretty close to everything, but the data specialists are still somehow far away from the operations.”

To scale ML in production, it’s crucial for organizations to create synergy between software developers and data scientists.

If machine learning will be commoditized — as in, more and more developers begin to take in components of machine learning into product development — the devs really need to know something about ML/AI. Of course that doesn’t mean they all need to become specialized ML engineers, but they should understand what these technologies mean for their work and how to efficiently collaborate with data scientists and engineers. The reverse is also true — the data and machine learning folks would benefit from knowing more about software development. If both sides are able to do that, then a shared language is created and harmonious and effective teamwork follows. 

Timo agrees. “It’s up to each of us to get closer to each other, and then to figure out how all of our work can be incorporated into a continuous software development cycle.”


Creating an MLOps Playbook

MLOps is the way to close the gap between the players involved in building ML-powered products, and to do it in a way that’s smooth and sustainable. In fact, at Reaktor we’d venture to say MLOps is closer to DevOps than machine learning itself — just with another layer of complexity. 

“MLOps is more about cross-functional, multi-disciplinary collaboration than it is about tech. Even though the technology is obviously super important, it’s still somehow easier than merging together people from different organizational silos,” comments Henrik.

To help companies get a clearer understanding of how to make MLOps work, we’re involved in ITEA’s Industrial Grade Machine Learning for Enterprises (IML4E) – a European research project working on a framework for the development, operation, and maintenance of AI-based software. Our focus is on looking at how machine learning can be integrated in software development processes. One of the outcomes of Reaktor’s participation in the IML4E project will be to collect all the learnings from the program into something like an MLOps playbook. It will include different practices around ML, information and guidelines on how teams work together to solve these challenges, practices for using specific tools, and perhaps even a curriculum for learning MLOps skills.


The Key to Scalability & Success

MLOps may feel like a Google-searched buzzword, but it’s not going anywhere. It’s vital that organizations start taking it seriously, because MLOps is an important part in figuring out how to make all the pieces of the puzzle (both human and machine) fit into an engineering cycle. That’s the key to scalability — and ultimately, success.


Want to read more about what we’ve done with MLOps and other AI/ML endeavors? Read about our work with partners
Kesko and Elisa.

Sign up for our newsletter

Get the latest from us in tech, business, design – and why not life.