The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode Go   to   python   podcast.com/linode. That's l I   Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.  

Your host, as usual, is Tobias Macy. And today, I'm interviewing Antti Karjalainen   about the RPA framework for automating your daily tasks and his work at Robocorp to manage your robots in production. So, Antti, can you start by introducing yourself? Hey. So I'm Antti Karyalainen. I'm the CEO and cofounder of a company called Robocop.  

[00:01:15] Unknown:

We are bringing open source technology   into the world of RPA, which is all about automating business processes.   And do you remember how you first got introduced to Python? 1st got introduced to Python. I was trying to think about this. It's way back,   something like 2006.   I have a software engineering background so that's when I was really starting out and Python was becoming popular.   Python has always been there as this thing that existed in my words. I can't remember the first time I got introduced, but it's just been over there always.  

[00:01:46] Unknown:

Yes. Become part of sort of the background noise of programming.  

[00:01:49] Unknown:

Exactly.  

[00:01:50] Unknown:

Before we get too deep into what you're building at RoboCorp and the RPA framework, can you start by just giving a bit of an overview about what robotic process automation is and some of the types of use cases that it's employed for? So RPA is really a way to automate anything that human users would do on IT systems. So it has the capability  

[00:02:10] Unknown:

to mimic human behavior on systems.   So the way I like to actually think about RPA,   it's a form of agent based automation. So you have this software agent that can act upon any system out there. It's running on a specific location,   might be using user credentials just like a human user   would. But then there's nuances how it can access systems and so on. I think we're going to go deeper into that a bit later.   But on the simple explanation side, it would be a way to reduce  

[00:02:41] Unknown:

manual routine work from human users without having to change your existing IT systems too much. Yeah. So from my understanding, some examples would be going to a website, downloading an Excel file,   changing some of the cells in there, maybe adding a formula and then saving that and then reuploading it to a different portal would be something that you might do with RPA.  

[00:03:00] Unknown:

Yeah. Exactly.   You would be surprised how much people spend their working days on really routine tasks accomplished   with digital systems.   Sort of this new type of manual labor that people are just used to doing. So people really even question the things that they do   from day to day with IT systems. And, you know,   there might be pushback from the techies saying that,   you know, you shouldn't do that in the 1st place and so on and so on. You should redesign your systems. But but then again, when you start to look at the economics of it all, are you gonna really redesign your ERP system in order to get 1 accountant's life a bit better?   So that's not gonna happen. So that that's where RPA steps in and and is able to pick up that work. And as developers,  

[00:03:49] Unknown:

you know, our natural inclination is to say, oh, I'll just write a script or I'll use the API or whatever. So I'm wondering what are the cases where somebody might use RPA and some of the advantages that it   has   over writing a custom library or a Python script to be able to automate some given task and just sort of the trade offs of   time investment and usability and sort of who the audience is for the tooling?  

[00:04:12] Unknown:

So API tools started with these kind of drag and drop type of tools where you build   a process or automation   with just combining bunch of tasks or actions together.   You know, they started to become more sophisticated, and now we're seeing something like Robo Club where we are actually starting to take Python based tooling and apply it for RPA.   At the end of the day, it's really not that different from from a Python script.   It's sort of a weaponized form of that if you if you wanna use that.   So I wrote a medium article   some time ago actually saying that 1 use case for RPAs in a way   building proper governance around all the dirty hacks that coders have been doing for years. On the fundamental technical layer of what the actual script does, there's really you can you can blur the lines of just scripting with with RPA,   about how you actually deploy inside of an organization. That's where the differences are going to start appearing. So you're going to have security governance,   access control, scheduling,   remote execution, and so on and so on, built on top of that script. So it's it becomes actually a maintainable   piece of your IT infrastructure.  



[00:05:25] Unknown:

Another type of automation that's been gaining ground a lot is systems such as Zapier or If This Then That for being able to tie together sort of event based work flows between different systems where   my email might hook into my CRM, might hook into my accounting software,   and I can use something like Zapier to say, you know, when this happens in this software, do this other thing in this other piece of software. And these different SaaS providers will have hooks into Zapier or into IFTTT   for being able to perform these workflows.   And I'm wondering how the functionality and use cases of RPA compare to some of those automation services and where   something like Zapier might fall down and RPA might be the preferred tool of choice.  



[00:06:09] Unknown:

So workflow automation like Zapier and and if this then that they are adjacent to RPA,   but they don't overlap too much. Sure, you can try to use RPA in that way. Oftentimes, it just doesn't make sense.   These tools, these APS and likes our API based automation.   They are in a sense automated workflows,   while RPA is coming back to that agent topic that I I mentioned. So that agent can run on your desktop, that can run inside your, corporate network on a VM.   It can automate things like mainframe terminals if you wanted to. So it can do pretty much anything that you make it do. Some things make more sense than others to do with RPA.   I think RPA is really about enabling those sort of long tail use cases   while the workflow automation will try to do the mainstream stuff like combining SaaS apps,   where the SaaS app provider hasn't, you know, gotten around to build an integration.  



[00:07:09] Unknown:

In terms of your involvement with RPA and what you're building at Robocore, I'm wondering if you can just just give a bit more context of sort of what you're working on and your motivation for getting involved in this area of the industry and turning it into a business. So I've been involved with this project called Robot Framework for quite a while. Already 2013, I think I started there. We were running a consultancy that where we did a lot of software test automation back in the day.  

[00:07:37] Unknown:

And and robot framework is a generic Python based test automation framework for doing end to end testing.   So I had that background. I've been also   involved in creating the Robot Framework Foundation, which is a nonprofit organization that governs over that project   with over 40 member companies sponsoring it. So there's an active vibrant community around that specific tool. And I just saw the rise of RPA   in, I think it was 2016.   I immediately thought that, that looks exactly like test automation. What's any difference there between   end to end test automation   and R. P. A. Where you essentially want to do the same kind of things.  

And I started exploring really cold calling people that I could find out there doing RPA as starting to understand it.   From the technical level, it seemed that they are in fact, pretty identical is only on the governance   and orchestration side where the differences really start appearing, where you run test automation with something like CICD   tooling.   Also, it test automation. You build 100 of even 1000 of automation routines and manage them by DevOps teams. While in RPA, you might have a dozen   automations   that we actually call robots. It's a funny term to call something a piece of code robot.  

But the more you spend time in the industry, the more used to it you are. And I don't find it any troubling anymore.   So I just gonna use that term bots or robots. You're gonna have, you know, a dozen bots that are maintained by 1 or 2 RPA developers   inside of an enterprise.   I've really started seeing that that similarity   between this open source world that I was involved in and this new   emerging field in enterprise software. And I wondered that, you know, is there a possibility that we could actually introduce this existing   open source ecosystem to this new rising space of RPN and just really started pushing that. And we started on the open source side   2018. I think that was the year when we introduced some of the RPA syntax capabilities into the framework.  

And people just got excited about that and really saw the promise of what we can do. But when you went kind of further into that and started applying into, like, proper organizations is is at larger companies. You saw that we we were lacking a lot of really tooling, the robot framework, and how it's supposed to run as an RPA solution. So I wanted to create a company that really creates a tooling that was missing in the ecosystem back then. And also, we wanted to create a lot of documentation learning material. So far, it says we built this community around,   robot framework based open source RPA. That's how it all started. And and still on that journey.  



[00:10:17] Unknown:

In terms of the end user that you're targeting with Robo Corp and the RPA framework,   who are you directing your communications toward? Who's the person that's actually going to   become a customer of you directly? And how does that inform the products   that you're building and the direction that you're taking the business?  

[00:10:36] Unknown:

In a way, the end user is a developer. We wanna   really have a great developer experience. That's where it all started. So we are building tools for developers like bs code extensions and Jupyter lab based experiences.   Also a lot of just other developer focused tooling, but the buyer isn't the developer to develop and doesn't buy our service.   Our SaaS offering is the line of business folks who do that. So there we are balancing   between the developer messaging   and also the business value   positioning that we need to do. So this is sort of a nuanced marketing   problem that, you know, keeps going here. So we we need to communicate to both sides of the of the fence, both of the businesses make even CFOs and the CIOs and so forth. And then, you know, really have a great story to tell for the developers who who use the product. In terms of the broader ecosystem  

[00:11:33] Unknown:

of RPA tools, you mentioned robot framework that started out its life as this end to end test automation platform, and you're giving it RPA capabilities through the RPA framework.   And you mentioned there are some other businesses that are targeting the enterprise space. And I'm wondering just what is the kind of constellation   of services and systems that are available   for building RPA and employing it in an organization?   And where do you see Robo Corp and RPA framework fitting in that larger ecosystem?  

[00:12:03] Unknown:

If I can kind of paint the picture in a way of that full stack.   So we created this open source automation stack that's based on Robo framework on Python.   So on the bottom, you have Python. On top of that, you have a Robo framework. And next to Robo framework, you'll have RPA framework. So RPA framework is set of libraries that allow you to form typical RPA tasks like, you know, manipulating Excel and so forth. They're really underneath, they are a huge collection of different Python libraries   that have been   put in a form that are easy to consume for their RPA developer. And then on top of that,   we have a tool chain called RCC,   which is really part of the secret sauce that we are bringing into the open source space. And I think this is really unique approach that we have here. So RCC   is a way for you to, in a sense, easily distribute Python based scripts that are running, you know, even hundreds of dependencies   without any headache. So if you think about what we're doing now, we are deploying these Python based routines   on remote machines and   expecting them to execute their thing   really fast, reliably without hiccups and manage dependencies   released fluently.  

Python   doesn't have good facilities for that out of the box. You know, you could do something like, you know, requirements files and deep in stores, but that gets a bit messy   really, really fast. And if you try to do that over and over again, you're gonna be managing virtual environments and what haves you. So we we build RCC as a seamless open source tool chain to really   put everything together in a way that the RPA developer doesn't need to deal with that headache   of managing packages and environments. It just works. So that's the open source stack. Anything that you can do things like create   new projects,   run them, package them and deploy them.  

And then on top of that, we have a host of editors and tools. Obviously you can use the editor of your choice, but we have bs code extension for robot that makes it a bit easier to manage all that.   And also we have a Jupyter based environment called Robo Corp Lab, which comes essentially with a single installer that you can deploy anywhere.   And you'll have batteries included there. You can start building immediately. That's for that kind of new users coming into the ecosystem.   That's all free and open source and publicly available. And on top of that, a platform that you use to operate and orchestrate   your robots when you want to do a proper deployment,   then we have RoboCop Cloud for that. And that's a cloud native platform for really   running, monitoring and orchestrating those robots in production  

[00:14:50] Unknown:

then. In terms of the kind of complications and challenges that developers might run into when building these RPA systems and deploying them to end users. You mentioned some of the things like managing the dependencies and the libraries and getting Python running on the system. And so that's what the RCC tool chain is aiming to provide. But beyond that, what are some of the complexities   that developers of RPA tools might run into as far as handling credentials or   educating end users on how to be able to customize the flows to be able to fit their specific use cases? And what is the   granularity   of detail that somebody who's building these RPA systems might go to as far as just saying, here is the entire system. You just click a button and it does its thing, or is it, you know, here are the building blocks. You just need to add these pieces of syntax, and then you can customize it to be able to fit your workflow, you know, within this kind of constrained space.  



[00:15:48] Unknown:

Regarding credential management and these kind of things we provide that through robocop cloud. So that's a common thing that we wanted to solve for everyone.   You know, when you start an RPA project, you'll start up with a process definition   of some sort. So you have the current process that you need to to go and automate. You know, the auditor will go and say,   tell you that I need to go in every month and take screenshots of SAP   and Salesforce   and make sure that those things match and then store them somewhere on a network drive. It takes me, you know, 3 to 4 hours, let's say on a weekly base. Can you help me out? And then they'll show you what they're doing   as an RPA developer. You will need to take that   as is process.  

Kind of try to think about, can you make it a bit better somehow? Can you improve the process itself?   And then when you're satisfied with the design, you need to translate that into a working robot,   working piece of script. In a way, you'll start looking through the libraries that are in drop a copy ecosystem or in the robot framework ecosystem. You kind of see, okay, I need to do it in a browser automation here, I might want to have something for SAP. You look through the documentation, get understand what kind of keywords they offer and really start putting it together.   The best case is that that's really straightforward.  

Within a few hours, you test it and you deploy it. But always bump into something that there's a weird system from the late nineties that you need to interact with and it's gonna be kind of just challenging getting any handle on that thing.   For that kind of purpose, we have things like image based automation, so you can match image templates in that UI and try to automate it on the surface.   Then we are even going a bit further than that. And we actually   developing deep learning based   systems that can classify UI elements and automate them that way. So try to make that   process a bit more   manageable if you need to do that level of automation.  

So there's a whole range of stuff. You sometimes you need to be this reverse engineering master in a way. If you go and automate some web app that doesn't have any any proper   API to it or any proper controls. You might need to go deep and understand how the dam is built and and what kind of x path you want to craft in order to get in there and really make it robust and reliable.   So you need to know a ton of things about a lot of different systems, how they're built and be able to reverse engineer them at times to get the most reliable and robust solution. So that's really all about RPA. It's a and a special kind of development challenge.  

[00:18:22] Unknown:

Digging a bit deeper into RPA framework and the Robo Corp stack itself, can you give a bit more detail as to sort of the system architecture and   the set of sort of libraries and utilities within the Python ecosystem that you're relying on and just some of the ways that the overall scope and design of the project has evolved since you first began working on it? Yeah. RPA framework is sort of sub piece of all the thing that we build. So as I described, we have to build host of of  

[00:18:52] Unknown:

projects, but API framework is 1 key component in the sack that allows you to do a lot of these actions that I expected of API systems.   So we typically leverage existing Python projects   for Excel manipulation,   the spy Excel   and for image based automation. There are a host of different kind of projects out there. Browser automation, we leverage   selenium underneath, and that's wrapped into robot framework keywords   to make it easy to consume.   We also have playwright support right now. So Playwright is pretty   interesting   way to automate a browser and makes a bit life a bit easier than compared to Selenium.  

We have support for that as well. So it's it's more about the in a way,   RPA framework is more about the sort of breadth   than than the depth of the project. So you need to be able to design   these keywords   that are really ergonomic to use, cover a lot of the typical use cases and these keywords underneath these rubber framework keywords underneath, they translate into Python calls into different kind of libraries. So that's really how RPA framework has been built.   I think the version is right now we have something like 9 point something version. So you can imagine that there has been a lot of iteration going on over the past year and a half as as we've been building it. And we try to incorporate a lot of our customers and users feedback. You know, somebody has a use case around, let's say, Excel, they report, they   You know, somebody   has a use case around, let's say, Excel, they report back, hey, guys, I'm having difficulty with this kind of use case. Can you help me? And we see that opening up RPA framework is the best way to answer that. And so we'll just put it in there. And so that really drives   that project. It's a huge set of keywords   for our framework. And underneath that, that's actually usable with Python as well. There's a Python API available. So you can actually use just plain Python to access some of the RPA  

[00:20:46] Unknown:

framework functionality as well. In terms of the developer experience, as you mentioned, you can just do this directly in Python.   And if you're also relying on some of the components from Robot Framework, do you have   an API into that system to be able to do it all natively in Python as well? Or do you use sort of the specialized syntax that Robot Framework provides? And what's the dividing line between when you might wanna do it all in Python versus when you might want to rely on the customized syntax for the robot framework?  

[00:21:16] Unknown:

Excellent question to have. So robot framework, the way I think about it myself, it's a way to simplify automation developer. It's really this procedural   syntax that's easy to understand on the top level. So, you know, if I need to go to a website and click something there, what I'll do with Robo framework is I'll include 1 library, the browser library, and then I'll just say open browser, click. And that's that It's few lines, and I don't need to understand how that thing does it underneath, what kind of web driver is using and so forth, and what version of selenium is compatible there. So it just makes it a bit easier. We need to do any kind of heavy lifting.   You start manipulating a lot of data, let's say, then you spend us. That's what it's meant for. From Robot Framework, you can call natively into Python code. So you can have Robot Framework files and Python Python code. So you can have Robot Framework   files and Python files next to each other, and you can just call from Robot Framework into Python,   return objects as you need. So it's really fluent to switch between these 2 modes. But what really robot framework allows   you to have in addition to that simple syntax, that's kind of new user friendly. So even if you don't know Python, you can start using that pretty easily. But that also kind of brings 1 additional   point to the table, which is logging. So you have really good logging facilities. So   it'll create this detailed trace of what happened on a kind of a visual format   that's easy to follow. And so you'll have that for each execution of the robot   that gets stored as well in RoboCop Cloud. So if something goes wrong, you can dive straight into that log   and pinpoint your probe in a matter of seconds, or then you know, you oftentimes need to build an audit trail to show what the robot did at what time so so you have that as well. So it's all about, you know, that ease of getting into the scripting,   the ability to pull from readily available keywords without having to understand all the   great logging.  

But if you wanna do something complicated, just do it in Python. That's my advice always. Like when when it starts to look ugly on the robot framework script site, that's the time to move, move to Python.  

[00:23:36] Unknown:

Software is read more than it is written, so complex and poorly organized logic slows down everyone who has to work with it.   Sourcerie makes those problems a thing of the past giving you automatic refactoring recommendations in your IDE or text editor while you write. And yes, I even have it working in Emacs.   It isn't just another linting tool that nags you about issues. It's like pair programming with a senior engineer, finding and applying structural improvements to your functions so that you can write cleaner code faster.  

[00:24:02] Unknown:

Best of all, listeners of podcast dot in it get 6 months of their pro tier for free if you go to python podcast dotcom/sorcery  

[00:24:09] Unknown:

today. That's   s o u r c e r y, and use the promo code in it when you sign up.   And in terms of the level of complexity   of these workflows, as you mentioned, there's a tipping point where you decide, okay, I'm gonna switch from using Robot Framework and move it into Python. But for workflows that are naturally segmented,   what is the capability for being able to chain together multiple robots into a more kind of complex and fully featured workflow beyond just, you know, you might have 1 that's does 2 or 3 steps that are, you know, fairly rote and somewhat time consuming, but relatively simple. And then, know, I wanna be able to actually tie together,   you know, 5 or 6 different robots where the output of 1 step is actually the input to 3 other different robots that have different responsibilities or things like that? So for that, we build what we call data pipelines into RoboCop Cloud. So that allows you to run these tasks or these workloads in steps  

[00:25:11] Unknown:

that each step can fit into another step and so forth and processes can be chained into other processes   by passing on data.   So we really built that into the management platform side of it all. I know some people are using like external databases to facilitate   switching states between processes and so forth. But if you want to kind of keep it simple,   then RoboCop   has that covered. But that's kind of typical in RPA   where you might have processes   that need to, let's say, collect data from, you know, 5 different sources and that data might come over the span of multiple days. And then when you have everything in place, you can continue working on something and kick off another stage. And so   that's how you typically build these processes that are long lasting all the time and build them together.  



[00:25:59] Unknown:

For people who   have a specialized use case where RPA framework and robot framework have the majority of the functionality, but there's this bespoke system that I need to be able to integrate with. What are the options for being able to add new components to RPA framework or be able to integrate into that runtime from Python to be able to maybe integrate it into a larger application or pull in some additional functionality  

[00:26:23] Unknown:

that isn't there yet? Yeah. So it's really common that you'll build some sort of a Python library next to your RPA project.   Even though Robo framework itself has 100 of 1000 of users around the world, Python has over 7, 000, 000.   So every molecule in the universe probably has a Python library to it. So you can really leverage that,   that extensive   community there and lean into that. So when you have that bespoke thing that you need to attach to,   you can write a piece of Python code to do that and expose that piece as a Robo framework keyword. That's really it's a simple API.   So you can expose that to your robot framework syntax, and you can simply call to it. Or you can have that piece of the workflow be done a 100% in Python. So up to you really as a developer.  



[00:27:12] Unknown:

As far as   the   open source aspects of RPA framework and RCC and kind of the dividing line between it and Robocorp, as you mentioned, you have this management platform but then you   also   have these open source components. And   but then you also have these open source components. And I'm wondering   what are the dividing lines between something that you're going to sell as a product versus, you know, release to the community   and your overall approach to governance of the open source aspects of this ecosystem?  

[00:27:45] Unknown:

Open source is really important part of what we're building. I'm a firm believer in that. I don't think there's any other way to build software than to lean into open source really nowadays.   Everything that you use as a developer to build a robot and, you know, make it run and so forth, that's open source. So the dev tools and the whole automation stack starting from Robo framework and the RPA framework and then going to RCC, they are Apache 2 license. So really permissive   open source license there.   The the RoboCop cloud platform that you have for deploying these robots to run either in the cloud or then locally as well. You can deploy them locally through an agent.  

That's really a managed service that we as a company then provide with SLA included and everything that comes with that. So have   a lot   of governance   and security   and compliance requirements that come with larger organizations   in order to really be able to respond to those. We we provide that as a managed service. So there's a big clear line is is   anything that's RoboCop Cloud and the orchestration platform there. That's really our commercial end of the things.   And outside of that, it's open source. So RCC   is in a way, it's a bridge between those 2 worlds.  

We build it   initially   to solve our own problems, how we can   easily create projects and then run them anywhere without any   pre installed dependencies,   without actually even requiring Python to be there in in the first place.   And then be able to deploy those routines across   100 and thousands of different environments and be able to update them seamlessly and so forth. This kind of management headache   that was the first question that we asked from ourselves when we were envisioning the company and what we wanted to build. We thought to ourselves, man, that's gonna be a problem. Like, has anyone solved that? So when we started working, we ended up solving it, and we thought that   this might be actually   useful for some other people out there as well. And that's really RCC is the bridge that we decided to then open source. And it's a large part of our own IP that we've been able to bring. And I think that if you put some some marketing effort behind it, it should be something that others in the Python world, you know, even even people who are not interested in RPA 1 bit should be able to look into and and say that, man, this is a useful project. We need to have this. When I was looking at it, I noticed that it's written in Go, which because of the fact that you're targeting this as something that's easy to just drop on a system and get up and running is sort of a natural choice because of Go's tool chain for being easily statically compile things. And I'm curious  

[00:30:27] Unknown:

if there were any kind of challenges or complexities that you ran into interoperating with   Go as sort of the base layer and then being able to bootstrap Python into then executing all these other workflows and sort of packaging up and managing the dependencies and just some of the complexities that you ran into there? They're actually leaning into  

[00:30:45] Unknown:

conda over there for package managing quite a bit,   and we are using something called MicroMamba internally   to manage conda environments.   I'm working with the actually the original author of that project   to tightly integrate that into the chain. Lucky for me, I haven't I haven't been the 1 to implement that. So I don't know all the pain and sweat and tears   to go into RCC, but I can watch the depth. That's plentiful. So what it does underneath the hood is it keeps track of all the dependencies and files that you have   cached locally and is able to pull the required environment   together really fast when you need to run something.  

And so it's actually pretty efficient way to manage things. Like if you have, let's say that we are running in the cloud side, we are running   hundreds of different types of Python environments   all the time. If you have them as separate environments installed, it's gonna probably consume.   These are big libraries, so it consumes   thousands upon thousands of gigabytes of actually data   to store these hundreds of different individual   environments with huge dependency loads.   With RCC, it actually compresses into just few gigs. So it doesn't store anything twice there, and it manages all that under the hood pretty elegantly.   Actually, there's few patents that we have pending for some of the stuff that goes into us. You see, but,   but yeah, I mean, we we spend a considerable amount of time on that. That's all I can say. So we we we know we know too much about Python dependence management.  



[00:32:21] Unknown:

Yeah. I'd be interested to see how this plays out in relation to things like pyoxidizer   and some of the other approaches that are out in the community for being able to statically compile   a hermetically   contained Python environment and runtime and all the dependencies.  

[00:32:36] Unknown:

It actually with the latest release, it's gonna do some of that same stuff.   Some instances, we have the requirement to ship a static instance of a robot.   So when we're talking about really high security stuff like government   and the sort of   government and military side of things, they don't really allow you to start loading   packages dynamically   from pipe and package index or anything like that. That's really out of the question. So we just need to exactly her medical seal and everything and make sure that they are approved and scanned and and so forth and and ship that as the robot. So that's something that the RCC is built to be able to handle as well.  

[00:33:15] Unknown:

In terms of the use cases and the   sort of implementations of the different robots and workflows that people have built using RPA Framework and Robocorp,   what are some of the most interesting or innovative or unexpected ways that you've seen it employed? I think what what's amazing with it is,  

[00:33:35] Unknown:

grinding routine, it can automate away. So,   grinding routine, it can   automate away.   So I've heard that, you know, people are doing, like, health care insurance claim automation   at a hospital's way. It just frees away, like, half a day every day from somebody's work.   But I also know of a bank in the Nordics   that they use this technology   to automate a way, a routine that they had to do. So they had to actually go through all of their business applications and and update the end users, the the customer's   phone records   due to a record or a change that was pending.  

So they use a framework   to build that automation and they actually ended up saving.   I think they quoted this to me. So they saved   7 years of their customers   waiting time on the phone within 1 month. So having that kind of result, think about it 7 years of just people   waiting on the phone   and being able to get rid of that is pretty amazing.  

[00:34:36] Unknown:

Sort of the perennial promise of computers is that it's supposed to save us all of this time, and yet so many of us end up wasting a huge amount of our time on very tedious and menial tasks that the computer is supposed to do for us. That's definitely great to see that, you know, there there are some cases where that promise is actually being realized.  

[00:34:53] Unknown:

Exactly.  

[00:34:54] Unknown:

In your own experience of building and growing the RPA framework and Robocorp and sort of the business and community around all of it, what are some of the most interesting or unexpected or challenging lessons that you've learned? Running a startup, obviously, is a lot of hard work. There's no way around it.  

[00:35:10] Unknown:

I will say this to everyone who's about to join the company. I tell them that, look,   we live in dark years, so 1 year over here will be equivalent to 7 years in a regular company. I think that holds true. Oftentimes   the timelines are so condensed. You need to achieve a lot of things in just a short time and it constantly under pressure   to perform and and grow the business. So I wouldn't change this for anything I have to say, but it's definitely a unique set of challenges and something that you you really can't prepare for   in advance.  



[00:35:48] Unknown:

We've all been asked to help with an ad hoc request for data by the sales and marketing team. Then it becomes a critical report that they need updated every week or every day. Then what do you do? Send a CSV file via email?   Write some Python scripts to automate it? But what about incremental sync, API quotas, error handling, and all of the other details that eat up your time?   Today, there is a better way. With Census, just write SQL or plug in your dbt models and start syncing your cloud data warehouse to SaaS applications like Salesforce, Marketo, HubSpot, and many more. Go to python podcast.com/census   today to get a free 14 day trial and make your life a lot easier.  

Another thing that I'm curious about is how much you're using   RBA framework and Robocorp   to be able to build out and maintain Robocorp itself and just sort of how much of your own work you're using to be able to perpetuate the work that you're doing? I typically say that every company will have some sort of a routine thing  

[00:36:48] Unknown:

that's automatable with RPA.   It's not just for the largest of the large enterprises out there.   Something like a startup will be so fast moving that you you're not gonna have   static processes that are gonna be sitting there in place   for long enough to kind of get in anyone's way usually   or then you do them on purpose the wrong way. Kind of you do purposely things that don't scale   because that's the fastest thing to get there. So, you know, we have some nagging things in payroll, for instance, that we need to do every month.   We've been wanting to automate a way. We just simply haven't been able to get to that. But what we actually have in place is   I think we have 1 bot that handles Slack invitations   because Slack didn't have any good way to automate that. So we have 1 robot in place to do that. Don't test Slack. They probably shut it down.  

But but then we also have 1 robot that'll   check offices security system each night and let us know if somebody forgot to turn it on.   So these are pretty trivial things, but   these are the ones that I know of at least. We might have something like scraping the web for some data here and there, but these are the ones I know of and they have been fairly fairly long standing and running and serving as well. It's pretty fun to have those. So for people who are looking at the things that they're doing in their day to day and starting to think, oh, this might be a good opportunity for RPA or RPA framework. What are the cases where it's the wrong choice, and  

[00:38:20] Unknown:

you might be better served either just continuing to do something manually or using a different approach to automation?  

[00:38:25] Unknown:

I would refer to that xkcd   comic that's out there. It's there's this matrix of how much time it takes for you   to automate versus how much it will save, and it'll take you just tell you the breaking point.   So I started that XKCD comic and then oftentimes   RPA is sometimes popularized   as something that, you know, should be on everyone's desktop. It should be there for every business user in a company that they should automate away their routines.   Oftentimes,   your personal   routines are, you know, not so time consuming that you would wanna apply RPA to them. So it's oftentimes   when you go into   things that run across people or across organization that you're gonna find this sort of larger   and more rewarding   automation tasks that you can deploy.  

So on the personal level, there might be some things like I know a guy who used to book his tennis courses, like tennis appointments with a bot.   But beyond that, it's really rare to see like actually like somebody running it on their desktop if it's not, like, web scraping a bunch of stuff for them   or something like that. So this there might be definitely better solutions out there for simple point tasks like that. So always   check before you   apply it if you have some other way to do it. There are definitely a ton of times where RPA is the right choice, but, you know, don't try to replace API with it if you're not that kind of person who likes to maintain stuff,   if it's not a hobby for you, and use it wisely where it's sort of has its strengths.  



[00:39:58] Unknown:

As you continue to work on Robo Corp and the tool chain for the IP framework and RCC,   what do you have planned for the future of the business and the platform?  

[00:40:11] Unknown:

Difficulty is trying to limit the scope of all the things that we may be engaged in instead of just figuring out new ways to burn more capital. So I guess staying focused is number 1.   Right now, we are really keen on getting started with our enterprise users. So we've been   working hard to get the the platform in a state where it can pass all the strictest requirements of the largest of the large enterprise users out there. We are we are starting some of those deployments right now. That's super exciting. And then maybe the next stage that I'm really excited about as well is   our partner network. So we have roughly   40 or 50 active partners globally building on top of Robo Corp. We are adding new ones almost daily nowadays,   but really enabling   partners to build business on top of RoboCop and the platform that we created. That's something that I am super excited about. We have a lot of new things that we are building on that side, which essentially allows some of these partners to run what we call robot as a service. And that's a great way to operate for mid market users specifically.  

So I think the robot as a service wave is something  

[00:41:20] Unknown:

once we have conquered the enterprise side of of things or started a journey, we will turn our attention to the robot as a service in in full force. Are there any other aspects of RPA in general or the work that you're doing at Robo Corp and on RPA framework and RCC that we didn't discuss yet that you'd like to cover before we close out out the show? Yeah. I mean,  

[00:41:40] Unknown:

there's a lot to uncover there and it's,   you know, it I'm envious of the people who are building a point solution that you can click and and buy and that's it. It does a thing for you, and that's the end of the story. But RPA and building this kind of developer ecosystem and develop a stack of open source developer tooling and a cloud platform. Everything is it has a lot of things to uncover there. So I think we went through the basics, but I think 1 last thing would be that if anyone is interested in getting into RPA more,   we have great documentation   on robocop.com/docs.  

There's even a free certification   course that you can take. The first level 1 is gonna take you just a while to complete. The level 2 is gonna be a bit more demanding, but I challenge everyone to   try to get a stab at it and try to see if they're interested in learning of RPA,   what it's like, and those certification courses are great way to get into it. On the point of certification,  

[00:42:37] Unknown:

what are some of the types of organizations   or   jobs   that where that certification would be useful or that people might be looking to that? Good question. RPA developer market is  

[00:42:49] Unknown:

growing fast. So our partners who work on the mid market side,   they are basically limited in just getting RPA developers hired. That's the limiting factor as you might imagine.   Enterprise is the same thing. You know, getting RPA developers to join is limiting fact. I'd say that know, if you have some experience in scripting, you're   interested in gaining new skills there and, you know, starting your career there,   getting into RPA might be actually a great step towards learning   new skills. And because if you start building on something like RoboCop, you'll learn Robot Framework, you also learn Python, you get skills that way you can actually take them to other places as well. So that might be a great place to enter the world of software in broader terms  

[00:43:36] Unknown:

is in high demand right now in many, many places. Well, for anybody who wants to learn more about that or get in touch and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks.   And this week, I'm going to choose   the WandaVision series. I just watched those recently.   So only 9 episodes. So it's a little mini series, so you don't have to invest a bunch of time into it. But it's just a really well executed story and interesting and few good twists to it. And it's interesting how they weave it in with the rest of the Marvel Cinematic Universe. So definitely worth taking a look at that if you are looking for something to watch. And with that, I'll pass it to you, Antti. Do you have any picks this week? My pick is gonna be a movie.  

[00:44:18] Unknown:

I rarely watch movies, but I watched this last week. It was The Tenet.   And if you're able to   watch that and understand it the first go, good luck.  

[00:44:29] Unknown:

So that was a mind bender. Well, thank you very much for taking the time today to join me and share the work that you're doing. It's definitely very interesting problem area and a very approach to it. I appreciate all the work that you're doing to make it open source and accessible to more developers as well. So thank you for all the time and effort you've put into that, and I hope you enjoy the rest of your day. Great. Thanks for having me.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.