Real-Time Data with Apache Flink: How Ververica and Steadforce Drive IIoT Success

Your machines, sensors, and industrial IoT devices generate endless data streams. The potential is huge—but in certain critical use cases, you need to act in real time. Otherwise, you risk missing the moment.

So let’s ask the key questions: Which use cases truly require real-time decisions?
Which technologies can handle the scale and speed? Why is everyone suddenly talking about Apache Flink?

And what should you watch out for when implementing it in your own projects?
In this episode, we’ll get straight to the point—with real-world examples and insights that go beyond the buzzwords.

Joining me are Ben Gamble, Field CTO at Ververica, creators of Apache Flink, and Stephan Schiffner, CTO at Steadforce and expert in implementing Kafka and Flink in industrial environments. We’ll explore why many projects get stuck—and how to avoid the same traps. You’ll learn what it really takes to act on data in real time, and how to get started without overengineering your architecture. 

Let’s dive in. Full details as always at iotusecase.com. Let’s go.

Hi Stephan, hi Ben. It’s nice to have you on the podcast today. How are you both? Ben, I’ll start with you.

Ben

It’s a wonderful day today. There’s been a surprising heatwave in the UK, so the weather is suddenly really nice. It’s been a busy few weeks with conferences, as conference season is now in full swing.

Yeah, I can imagine. By the way, where exactly are you based regionally?

Ben

I’m currently based in the UK, near Cambridge. Like most of America, we work remotely from around the world. My team is spread out between Athens, Oregon, and London right now.

I see. Nice to have you here today. And Stephan, how are you and how’s your day going?

Stephan

Thanks, Madeleine. It’s a pleasure to be back. I’m based in Munich. It’s a bit cloudy outside, so not as nice as in London today. I’ve been busy with lots of meetings and tasks.

Right, I appreciate your time. I’m really looking forward to this session. Ben, let’s start right away. Ververica is known as the original creator of Apache Flink. Can you explain the founding story behind the company and how its mission has evolved over time? I’d love to learn more about that.

Ben

Okay, so Ververica originally came about in Berlin from the Technical University. There was a project called the Stratosphere Project, which was designed around the simple idea that data was getting bigger. If you remember the big data boom that came out of the early 2000s, late 90s, technologies like Hadoop characterized this era. Now, the Stratosphere Project became the foundation for the idea of computing that is larger than memory and machines. How do you act upon all this data we’ve now gathered? That project rapidly evolved into something that was then donated to the Apache Foundation and became known as Flink. It’s a play on words because it’s quick, and as I’ve learned recently, “flink” is a German word for a cheeky kind of quick. So yeah, Ververica means squirrel, and the logo for Apache Flink is a squirrel. The squirrel represents the messenger on the Norse world tree, which carried messages quickly between the different realms. Apache Flink slowly became the de facto real-time stream processing engine. It originated from the idea that batches and streams were not two separate things, but really one. Any time you process data larger than cache, memory, or disk, you end up streaming your data anyway. So nearly all modern databases stream. Heck, if you go to the DuckDB website, it clearly mentions streaming. But Flink came from the idea that streaming was the more important thing to do, even if you were doing a batch process. From there, it spread. It’s been behind the scenes for a while, and we celebrated the 10th anniversary last year in Berlin at Flink Forward. It’s become that “overnight success” that’s been 10 years in the making, as they sometimes say. It’s been powering the largest digital companies in the world, from Uber to Amazon to Walmart, for many years. Now, particularly with providers like us, it has become mainstream, as the need for real-time processing has come down the stack from the largest companies to pretty much everybody. Because tell me, when was the last time a customer asked for something to be slower? I can’t remember when that happened.

Yeah, right, especially when we talk about IoT data and real-time use cases. It’s a critical factor. I’d love to learn more about your best practices for setting up these projects and then dive into that in a moment. But maybe, Stephan, could you give us a quick introduction? I know you’re based in Munich, but for those who don’t know Steadforce, can you give us an overview of what you do and how Steadforce applies streaming technologies like Flink and Kafka in industrial use cases? By the way, we’ll talk about Kafka in a bit.

Stephan

Sure. So, Steadforce is a tech company that has been building digital solutions for our customers for 40 years. We’re celebrating our 40th anniversary this year. We focus on three main technical areas: first, cloud solutions, which also includes system migrations and application modernization; second, platform engineering; and third, data and AI solutions. And this is where Ververica, Flink, and all that come in. We also work with leading companies from sectors like automotive, manufacturing, chemicals, and medical devices, which I would consider our core sectors.

Great, thanks. I was wondering what the difference is between Flink and Apache Kafka, because I see both as streaming technologies. So, could you help clarify where to place Apache Flink as a technology and maybe share a practical example to explain it?

Ben

Yes, the advantage of having recently given a talk on some of this is that it’s fresh in my mind. So, if we roll back to when Flink was created, it actually appeared around the same time as Apache Spark, the technology behind the company Databricks, which many people have probably heard of by now. Both came from the idea that data processing was the challenge. Apache Kafka, which came out of LinkedIn a bit earlier, was born out of the idea that storing streaming data was the challenge. Apache Kafka is a storage engine for data. It doesn’t care what you put in it; it’s optimized for writing large quantities of data to a place where you can read it from almost anywhere. Even the name Kafka was chosen because it’s optimized for writing data.
Kafka gives you a durable, distributed log. It’s an append-only data structure where you can keep adding to it without worrying about throughput. It guarantees that the data will survive almost any outage, as long as it’s set up properly. It can then be distributed via a publish-and-subscribe model to almost any number of readers. It’s a very powerful primitive in distributed computing, particularly when dealing with microservices or needing to distribute big data across other data systems. Flink works very well with Kafka, but there is no dependency; it’s just a nice pairing. A lot of IoT data specifically ends up in Kafka because of how IoT data appears unpredictably. And when you need to read it, you need somewhere convenient to access it from. So, Kafka fits very well with the IoT side of what Flink does, though outside of that, it’s more of a convenient pairing rather than a dependency.

I see. Do you have an example you could share? I don’t know if we can name customers, but I guess many OT experts are listening now.

Ben

Sure, I can name the customer and talk about a use case. In this case, they are separate, but we work heavily with companies like Toyota and BMW on their factories. Now, inside a factory, this is not specific to the use case. A classic example would be that I have pieces being made. Most modern factories are essentially supply chains in themselves. For example, one line might be making doors, another making wheel assemblies, and another making brakes. As these sub-assemblies come together, they need to be timed correctly. You can’t keep making cars if you’re low on wheels, and you can’t keep making wheels if you’re low on tires. Similarly, you can’t keep making hubs if you’re low on bolts. Managing these various rates of manufacture is mission-critical these days to reduce what’s known as work in progress.
Work in progress is one of the big theories of constraint in modern factories. You don’t want spare parts lying around because they take up space. Certain types of manufacturing pieces are also quite perishable—like raw rubber, which is unstable. You don’t want bolts to rust before you use them, and you don’t want oil to sit around and spill. You only want to have these things when you need them. An oversupply can clog up your warehouse, and an undersupply can slow you down. So, monitoring all these things in real-time and knowing when to order more, when to slow down an upstream process, and when to speed up a downstream process requires real-time data. A lot of what we do with manufacturing clients is not just monitoring in real time but acting on that data as well.

Okay, cool. Do you have another example where it’s necessary to act on real-time data? I know that a lot of OT experts are familiar with edge computing and technologies like that, where you can process high-frequency data at the edge. But in this case, you’re doing it in the cloud. Why is it necessary to do this in the cloud? Can you explain that?

Ben

Yes, let’s take the most common example. Yesterday, I was in London, and these days, I don’t use cash. Increasingly, no cash is allowed at various payment locations. There are cashless stores everywhere, and the transportation network is all done by credit card tap. For example, if I tap my credit card on the gates to a train platform, I need that to be processed immediately so the gate opens in front of me and there’s no jam. But once I’ve tapped to pay, that information needs to be sent to the cloud. The system must first verify that I can afford the purchase, that I am indeed who I claim to be, and that the shop is actually the merchant it says it is. Let’s say I tap a payment and it gets routed strangely into the Mastercard network, Visa network, or Amex network. They need to verify who actually made that tap. If I’m normally in London but this tap happens in Cape Town, that might be a problem—especially if the previous tap happened in Lagos. These things could be an issue, and that mandates the ability to take real-time action, which is nearly always in the cloud.

I see. So, I’m wondering if we have some examples from the industry. I’m just thinking about cases where you detect unusual patterns, like current peaks or something, where you really have to act on real-time data. Do you see similar use cases in the industry?

Stephan

One example could be anomaly detection. Let’s say you have sensor readings, like temperature. You could monitor if, at a certain point in time, the temperature hits a threshold or exceeds it. But what’s important here is that it’s not only about monitoring and identifying these conditions—it’s about getting real value from them. You should perform a stateful analysis over the stream of data. Maybe it’s not just about one peak, but about whether the temperature has changed its average over the last five minutes, for example. To relate this to your credit card example, Ben, if someone uses your credit card in Munich, that’s not a problem, because you could be here on holiday. But if, in a five-minute period, the same happens in London, then we have a problem. That means the context and the state of the entire process are very important.

Ben

To elaborate on this, stateful computing is a key feature that Apache Flink brings to IoT. It’s always been relatively straightforward to just listen to a sensor—that’s quite commonplace. For example, in circuit board manufacturing, I’ve worked in this field before, where you have a wave solder machine. It has a crest of molten metal, and the boards go past it as they get soldered together.
Now, the wave has to be at a specific height and temperature. If it goes too low, it won’t solder the boards properly, and you’ll waste a lot of money. If it goes too high, you could damage components. It’s easy to have a simple trigger for when it’s above or below the threshold. But if, over time, the temperature starts to trend downward over the last few minutes, it might indicate you’re losing solder somewhere in the system. This suggests a systemic fault, and just topping it up once won’t be enough.
This is where you need more than just recognizing an event—you need to recognize a pattern and have the ability to maintain the context of that pattern. For example, if every day at 3 p.m., we have to top up the solder, it could mean there’s a leak, and we’re losing a certain number of milliliters per hour. In that case, we might want to fix it, or we may just decide to top it up every day at 3 p.m.

Yeah, I see. Okay, so maybe let’s talk a bit about the problem behind this. I understand now why real-time data processing is necessary and what kind of use cases there are, but why do you think many companies are struggling to move data or transition from traditional data architectures? You mentioned Toyota, BMW, and other big companies, but there are also smaller companies trying to do this. Why do you think many companies still struggle with it?

Stephan

I think one point is that existing infrastructures have grown over time. You have many legacy systems, or at least systems that are static, and it’s not easy to extract events from these systems. Flink provides a good solution here with the Flink CDC sub-project, which allows you to connect these legacy systems and move the data wherever you need it. So, it’s really about extracting, preprocessing, and moving the data.
The second point is that the data often isn’t in the right quality for a specific use case. Even if you have good-quality data, it might not be suitable for the use case you want to achieve. This is something you have to address before using Flink for processing.

Ben

To elaborate on this, the curse of legacy software is that legacy software is often making too much money to be safely deleted. The problem is, most of these companies have been around for a while. Manufacturing and most IoT setups take time to implement. Therefore, the combination of sensors themselves might not return data in real time. The linkages between them and where the data is stored have been built over many years and are probably doing a good job today. They could be doing better, which is where we come in, but if it’s already working, you can’t just rip it out safely, especially on a 24/7 production line that doesn’t turn off.
Even for traffic-type sensors, those systems aren’t allowed to turn off. If you suddenly shut down the system that controls the traffic lights for a city, you might have a problem. I’ve seen this happen, particularly with ticket-buying systems for national rail systems.
To elaborate further, change data capture—the ability to pull streams from existing systems—is the right way to advance things. Stephan and I have used a term quite a few times now: “evolution, not revolution.” When someone comes to us saying, “Hey, we need to go real-time,” our first answer is, “Well done, you’ve reached the point where real-time matters.”
Real-time processing is often required to stay competitive these days, but ten years ago, it was just a nice-to-have. To compete back then, you just needed things to work, to actually report. Now, to compete, it has to work in real-time because there are so many more efficiencies to gain, so many more things to save, and so many more advantages to take.

Yeah. I mean, you as a partner and I have worked together on different projects, and you also see the whole market for these projects. Do you see that everyone is working on this, or is it just a specific percentage of companies? Or do you see that only larger companies are working with this? Do you have a personal opinion on that or how the market has grown over the last few years?

Ben

I’ll take a stab at the bigger market, and I think Stephan can speak more to the specifics. The general trend on the bigger side is that you used to be able to pay for MES systems, like the whole electronic, single-panel glass systems. I held my first jobs 15 years ago, and we were exactly in the same area. We were building panes of glass on top of these PLCs. It was really advanced at the time, but honestly, only the biggest companies in the world could afford these. They made significant improvements to their production lines or monitoring systems with these kinds of benefits. But when you went down the scale a bit, it didn’t matter.
These days, we’ve democratized access. You know, Uber and Netflix use Flink. I’ve been using Flink for many years, but it used to require five to ten very skilled people to maintain and operate these clusters. Now, it’s available at the click of a button. Suddenly, it’s something that’s actually accessible. It’s no longer something you couldn’t afford or had to build in from day one—it’s something you can now add.

Stephan

Yeah, and I think we see this in several sectors. There’s no business where this wouldn’t make sense. But sometimes the responsible people still need to understand the technology and see what capabilities come with processing data in real time and which use cases and business value they can extract from it. For example, it’s pretty obvious for the insurance or finance industries, like we discussed with the credit card fraud example. It’s also very clear with anomaly detection, predictive maintenance, and things like that. But it could also be interesting for public sector organizations to deliver new services to their members, clients, or customers.

Ben

To elaborate on that exact point, think about Google Maps, for example. I use it to get around cities and places I’ve never been. In London, at least, the only reason it works is because what was once the London Tourist Board became London and Partners. They basically opened all the APIs for the entire transportation network in London to the public. You can just listen to these live feeds. That meant you could put predictive train times on various routes. In Helsinki, there’s literally an open MQTT feed for public transportation data. You can track where your bus is in real time. Most of my demos with Apache Flink are based on one of these feeds because it’s so powerful to see where the vehicle is now, where it was ten minutes ago, and its current state.
I have a background in logistics, and a lot of what we had to track was the movement of vehicles—whether it was a boat, a lorry, or a truck. The key difference was what was inside it, what came off, what came on, who owned it. It’s about continuous state updates. The challenge is not just having a continuous stream, but needing to know the answer when you need it. Asynchronicity mandates real-time processing. For example, I don’t need to check what’s in my vehicle until I absolutely need it, such as during a customs check. But at that point, I must have no uncertainty. I can’t afford to wait.
So the only way to do that is to gather data in real time and then read it asynchronously.

Yeah, okay. And maybe to add one more question, because in the end, it’s also an investment in technology. Companies could think about doing this themselves with their internal teams, or they could see the benefit of setting it up with partners, like you, for example. So, what do you think makes Apache Flink, and your collaboration, special? Are there pitfalls companies should be aware of? What are some best practices? Why should I choose Apache Flink, and why is your partnership interesting in this context? Can you talk a bit about that?

Stephan

As Ben mentioned earlier, Apache Flink is the de facto standard right now when it comes to stream processing. What I think is important when starting such a project is to have both perspectives. On one side, you need domain expertise—like in manufacturing, for example—understanding how the processes work, what kind of parameters and sensors are involved, and what exactly you want to achieve. On the other side, there’s the technical aspect: how do I create an architecture that is scalable and delivers the performance we need? Latency can be a big issue. For instance, if I detect an event—sticking with the credit card example—just a few minutes later, it might be too late. Or, in the case of a machine that could break if the temperature exceeds a threshold, it’s critical to act immediately.
So, you need both sides. What we at Steadforce can provide is the consulting and collaboration with the customer to build the jobs.
On the other hand, Flink is a very powerful technology, but it can also be complex when it comes to operations—specifically, day-two operations and running it. Security concerns and maintenance are key. And that’s where it’s beneficial to have a platform that’s really production-grade. And for that, you have Ververica and Ben.

Okay, yeah. Ben, many companies are aware that Apache Flink is an open-source technology, but there’s also a commercial solution. What do you think are the key factors for companies to choose to work with you? Maybe you could point out some aspects here.

Ben

Sure. Ververica is probably one of the main maintainers of the open-source project. We’re built on that firm foundation of open, distributed technology, which allows everyone to get started. Now, getting started with Apache Flink has become a lot easier in the last few years. You can simply roll out the open-source version, and it will work. But it’s not just about getting started. There’s a huge difference between a prototype or a proof of concept (POC) and an actual production system, especially with most IoT projects. The cost of failure isn’t just about the system being down or not being able to sell something. It could mean losing a few million in inventory and being down for weeks if something, like in a glass manufacturing plant, cools too far, or anything involving large robots.
What really matters is reliability. You need to know that the system will be up tomorrow, that security vulnerabilities will get patched, and that the people maintaining and running the system are experts. All software requires maintenance; these are complicated systems, and you can’t run them without experts. You also need to know that the service level agreements (SLAs) will meet your expectations. If not, the alternative is very expensive. This is the same reason why we all use the cloud today—data centers were never easy to manage. Machines, hard drives, and all that are abstractions we don’t need. What we really want is results, and buying results is almost always cheaper than buying the infrastructure that delivers those results.

I’m not sure if you have a return on investment (ROI) calculation for this—but is the investment in this streaming technology, like what you’re mentioning now, mainly about focusing on time-to-market? Do you have insights into ROI? Because I could imagine a lot of companies are considering that.

Ben

So, I’ll give you two perspectives on this. The first perspective is the cost of real-time processing. There’s a famous, perhaps apocryphal, quote from Bezos about the idea that going five milliseconds slower on the Amazon homepage cost $100,000 a month. This was about ten years ago, but eBay found similar results with even higher numbers when their website slowed down. The point is, humans notice perceptual changes very easily. And that’s just from a human perspective. When you get to machines and tolerances, especially in more precise manufacturing processes, even a single degree difference can be significant. The ability to control a system with finer precision means you can run it closer to the tolerances and operate faster because you know you’ll catch problems sooner.
We don’t operate at the maximum tolerance because we don’t want to be in a situation where a problem might slip by unnoticed. It’s the same reason we don’t use as much titanium as people think we do in airplanes. A crack in titanium is harder to detect, whereas a crack in aluminum is noticeable. If a crack forms in titanium, the plane is already gone, but with aluminum, you’ll see it early. The idea is that real-time monitoring allows you to get closer to a problem before it becomes a critical issue.
Now, the flip side—looking at the cost of ownership rather than the cost of the advantage—is also very clear. Let’s say, for example, you’re in Germany and a senior engineer costs €100,000 a year. If you need ten engineers to run and maintain the platform, that’s a million euros a year. If you’re paying less than a million euros for it to be hosted, it’s easy to see that you’re getting a return on investment.
That’s the simplest metric, but it only shows one side of the costs. What we do is optimize Flink. Our version runs twice as fast, or even faster, than the open-source version. It takes more to catch up, but what really matters is the outcome, not the inputs. The inputs can change, but at large scale, those differences get lost in the wash. What’s important is that with better technology, you can move faster and catch more errors. The cost of failure often far exceeds the cost of upgrading the system. So, if you can prevent just one industrial failure in a factory that shuts down for three days, that’s a huge saving.

Right, then you have the answer. Okay.

Stephan

I think not all use cases are directly measurable in terms of money. For example, if I can improve my production process and get a higher quality end product, this will help me retain customers. But it’s really hard to measure that in financial terms.

Ben

Yes. Think about how many people you need on the shop floor if you can’t check things in real time on a single pane of glass. Otherwise, you have to walk up to a machine and read a gauge. I’ve seen that, and I’ve done it. It takes a lot of time, and it’s a bit soul-destroying.

Yeah, exactly. And do you have any best practices for setting up these projects the right way? I mean, you’ve seen a lot of different projects with customers, but also individually. What would be your best practice? What should I be aware of if I want to set up a project like this? We’ve had some examples, but do you have any advice on that?

Ben

The number one thing to always remember with Flink is that you can do so many things. There’s always more you can do. I often joke that my job is to say “yes,” and I can say yes to almost anything that Flink can do. But the real first thing you should focus on is what you’re trying to achieve. More often than not, it starts with some quality goal, monitoring goal, or responsiveness speed goal. All of that still comes back to data.
So, the first thing you should always do is model your data. Essentially, you’re building a data mesh, whether or not you wanted to. And these days, Apache Flink gives you some of the best tools out there to do this. So, model your data, be sure of what’s actually real-time, know where the data is coming from, and then just start by wiring it all up. Connect all the data sources you can, and then go from there. Build your downstream data products once you have data in the system. Don’t try to just build one thing and then see what else you can build. Connect everything first. Once you have it connected, it’s much easier to build on what you have rather than running out of something and having to recreate things downstream.

Stephan

I fully agree with that. For example, with our customers, we conduct so-called starter kit workshops. We have these for AI, cloud, and of course for stream processing. In these workshops, our consultants work with the customer to review the existing infrastructure, data sources, and so on, to establish a good starting point for setting up the architecture or defining the objectives we want to achieve. I think this is true for almost all types of software projects: you start small, demonstrate some value, and build from there. You can definitely start with the open-source version of Apache Flink in the first steps. But you should keep in mind that scaling and production will come, and for that, it would be ideal to have a platform like the Ververica platform for production.

Right. And when we talk about the platform, Ben, do you have a link where people could click to get more insights about that? I assume you have different solutions around it, so maybe I could add it to the show notes for more information afterward. I think there might be people interested in checking out your website to see what you’re offering.

Ben

Sure. The best place to get started is actually our cloud. Our cloud is very similar to our platform. It’s called the Ververica Cloud, or VVC as we often call it. It’s a fully managed, serverless version of Apache Flink with some upgrades, as it runs on what we call the VERA Engine. The reason I suggest this is because it comes with $400 of credit to get started, allowing you to connect sources, model out SQL statements, and run Java and Python code on top of your data with relative ease.
If you’re getting started, this is probably the best place to begin because it requires nothing from you. The machines are running, the Kubernetes clusters are managed, and you just bring your code and run it.
Getting started with the open-source version is still an option, and you would develop your app on a standard Java, Python, or SQL editor. With SQL, you can just dump your queries into the online console and go from there. You can link any source you want—it comes with connectors, and you can add additional connectors as needed.
Even if you end up needing to run on-premises, we do provide an on-prem version. But getting started there doesn’t make as much sense; it’s always better to start with something managed, so you have fewer questions.

Okay, that’s cool. I’ll add it to the show notes. By the way, I just want to ask about the on-premise topic because it’s always something customers ask: Is it available on-premise? You mentioned that you do provide this, right?

Ben

Yes. Actually, this is where Stephan and I work together the most. We deploy a lot on-premises because of the highly intensive data and privacy requirements. The challenge with machines is that they have long lifespans, and many of them were designed before cybersecurity was even something people considered. So, they need to run on air-gapped networks, and the systems often have to be physically located in the factories. We actively support most of our clients with on-prem solutions. We power some of the biggest banks in the world and also some large manufacturers, specifically because we can run on-premises with them.

I see. So, Stephan, are these your industry customers, or are these other customers who want to deploy their solutions on-premises?

Stephan

It’s mostly in the industrial sector.

Yeah, I see. Thanks a lot. I have so many more questions in mind, but I also want to pitch the story a bit and give an overview of what Apache Flink is doing, what kind of use cases it addresses, and why it’s important to act on real-time data. That was pretty clear, so thanks for that. And maybe the last question for today: I’m also looking into the future. We’re talking about use cases that are deployed now and what customers are working on right now. What do you see as the next big transformation in industrial IoT data processing?

Ben

For me, it’s going beyond just yourself. I think one of the biggest changes we’ll see going forward is the idea of everything being real-time across the entire supply chain. Right now, real-time is like little islands inside companies where it takes a while. You might have real-time in one factory or maybe two or three, but it’s very rare to have real-time across organizations. The big thing I can see happening is having a real-time feed from the factory that produces the parts upstream of my factory. Or, in the logistics space, it could be the port authority providing a real-time feed of which ships are landing at which berths and which customer inspection warehouses are operating at what speeds. This means everything can be made real-time, not just the middle part. It’s about sharing the data.

Stephan

I’d come from a slightly more technical perspective. I think stream processing will become more accessible. We didn’t talk today about Flink SQL, but that’s the ability to create a Flink job using standard SQL. This is, of course, much easier than programming it in Java or something like that. This can even be done by people who aren’t explicitly software engineers but have, let’s say, knowledge of databases. I think this trend will continue and expand.

Cool. Do you also see AI entering these architectures—for example, to simplify processing or data mapping?

Ben

Short answer: yes. I didn’t mention AI earlier because it’s often the first thing people reach for. But AI still follows the basic principle of “garbage in, garbage out.” Unless you feed it with meaningful data at the right speed and with a clear purpose, it won’t provide value. That’s something Stephan and I have explored a lot recently. The ability to ask natural-language questions across your entire IoT setup is powerful—but we’re not quite there yet. The IoT world wasn’t born in the cloud, and API design in this industry is far from standardized.

Got it. I was wondering how AI fits into the tech stack—can it be used within Apache Flink to simplify things?

Ben

Yes, absolutely. Copilot tools exist now. They help you write Flink code using various assistants—we’ve actively supported this. Some tools let you ask a question and automatically generate the SQL statement for it. We’re working with partners who are doing exactly that. Beyond that, managing and scaling clusters can also be handled by AI. Flink is very compatible with AI; it was actually designed with machine learning as a core use case. The ML libraries are built-in. In fact, TikTok’s entire AI and recommendation engine runs on Flink. So bringing that into IoT will definitely happen—it’s just a question of what exact form it will take.

Yeah, I see. Okay. So, thanks for your insights and for your time. I found it very interesting to learn from concrete, practical use cases how the technology is being used, and also how your partnership and the offerings behind it are structured. That’s really cool. First of all, thanks for your time, and thanks for being on the podcast. I’ll pass it over to you for the final remarks.

Stephan

Thanks, Madeleine, for having us. I’m really looking forward to the next projects we can work on with Ben and the problems we can solve together. And, of course, if anyone has questions after the podcast, feel free to reach out, and let’s talk about how we can make software solutions more real-time.

Ben

Same here. It’s great to be here and to explore these kinds of use cases and showcase what’s happening. We have a bad habit, particularly in the industrial IoT space, of working behind closed doors. It’s great to talk more about what’s possible, especially with tools that are open.

So, for the last word, I’ll also include your contact information in the show notes so that people can connect with Stephan and Ben. Please feel free to get in touch. Thanks again for being here, and have a great rest of the week. Bye!

Stephan

Bye.

Ben

Bye.