Cloud Infrastructure From Python Code: How Far Could We Go?

Speaker 1 [00:04]

Hi everyone, thanks for coming. A couple of words about myself. I'm Asher Sterkin, most important fact about myself that I'm a software engineer. Some wits argue that people do not live so long in our industry, but here I am. Don't program for money, that's the best advice I could give you. My social contacts are here, and I will be talking mostly about strategic potential of the technology, and it will give you some real-life examples of what could be done with it. Disclaimer, we are vendor, but we will make best effort not to directly criticize sibling competitors. We are not on sales commission of AWS, so icons are for illustrative purposes, code samples for illustrative purposes. We do not represent official stand of our company. Formally speaking, the mission statement of infrastructure from Python code is to make cloud technology accessible for mainstream Python programmers, not only for writing code, but also for deployment and operation without compromising security, cost, availability, and other. But I always feel a little bit uncomfortable with that slight and kind of smell of marketing bullshit for people who have more money than brains. And with your permission, I will switch to more human language, trying to explain what the problem we believe is, and how we suggest to solve it. There are a lot of questions we hear over and over again. Why the hell do I need to know about Terraform? Many people even don't know what Terraform is, or CloudFormation, or Azure Resource Manager, or GCP Deployment Manager, or CDK, you name it. And it might take one week to convince them. We all have kind of masochistic attitude to our problems, so we have to suffer from something. But even those who know it have another question. In other words, why we cannot just run Python code in cloud, treat it as a computer, and not to worry about SDKs and templates? Why should we deal with that stuff? And then what's the problem? The problem is silo and cognitive overload. On the one hand, we have SDKs from platform cloud vendors, sometimes more than one. On the other hand, we have templates. And there are many combinations of these couples, SDK and templates, but like in Nabokov's Ada, they all are unhappy in more or less the same way. They are low-level, complicated, hard to master, vendor-specific, local to particular vendor. They are error-prone, cost-prone, reliability-prone, and most importantly, they are far from business. They're far from domain. It's something different. How is it just to solve it? We need to raise the level of abstraction and bridge the gap. we could use more or less the same approach as 12-factor does, so separate logic and configuration. At the service level core, we need to specify ports, either to implement ports or use ports. For example, in this simple example, we want to implement REST API and to use SQL Alchemy. On the configuration side, we want to specify that SQL Alchemy has to be binded to PostgreSQL API Postgres database, and we want specific way of user authentication for this API. Anything else has to be done automatically, we feed these two sources into compiler, produce modified code, actually port binding to cloud resources, and template to acquire resources and configure them and to deploy them for different cloud infrastructures. Again, if you continue this 12-factor metaphor, it's build, release, run. At the build stage, that's vendor-specific example, where transform original sources into final sources. Again, it's kind of port to adapters binding with cloud resources and produce template. And release, we upload them to some central cloud storage. And run means to deploy that stack on the cloud. That's what we do. Well, for those who are familiar with data, it sounds too abstract. For those who are familiar, it sounds like it cannot be. Too good to be true. So let's eat the pudding. Let's prove. Here is my, it's a sample application. more or less traditional CRUD service for Todo. Please pay attention, zero imports of cloud, nothing. Even zero imports for vendor-specific stuff. You see, it's standard Python. For simplicity of that application, I switched to mutable mapping rather than SQL, just simple and fast. And this is typical CRUD service. Create the Todo, delete Todo, update Todo, to do and the same in plurals. Nothing cloud-specific, pure application logic. Now, I could test it locally, and again, test is typical unit test of Python, runs blazingly fast, a couple of seconds, right? But that's not the most interesting part. Now I want to test it on on cloud, right. Eventually. That's a quirk of VS Code. Now, running that same software on cloud will take probably five minutes. So I will launch it with your permission and and explain what we're doing behind the scenes. Murphy log is my favorite one, but it worked several times, so hopefully nothing will happen. Just ask it to run all tests I have, including remote. In my remote, you see, local test, one second, nothing. Now, interesting part starts. It compiles my source and transforms it into target functions. and it will generate the template. While it's doing it, let's look at remote test. Remote test is more involved. It wants to create user and user pool to validate that. If unauthenticated, I will get suitable HTTP error code, and that service is available through internet. It's more involved. Okay, we create a template, we compile sources. Template looks ugly, I warn you. So let's look here at CloudFormation. In this case, it created CloudFormation template. And with a ratio of one to three or four per function, it generates multiple resources. Because you need to bind your function to external HTTP resource. You need to provide a log stream for that function, you need to provide access permission for that function, to provide real code. Most of the time is spent by cloud for cloud because allocating resources takes time. That's what happens here. How does it know what to do? We still have configuration. But configuration is a simple Python function. What it says, it says use some default config for mostly login configuration and all this stuff. By gateway, please use default user pool for user authentication, and choose database depending on which mode you are. For development mode, let's use S3, normal bucket, and for production, let's use DynamoDB, all right? Now it's created, and now it runs tests. Again, running tests in remote also takes time, because it's authentication and it's a handshake. One thing I want to show you while I was doing it, let's pick up one function. Let's give it. If you want to see template, it's one to 20 ratio approximately in terms of lines of code. It still runs because it takes time. Again, it takes time to run HTTP request. You see, one second against maybe five minutes. I will continue my presentation, and we will see the results later. So, to summarize that point, the need for infrastructure governance doesn't go anywhere. You have to control. Maybe in production mode, you need to specify VPC and the data encryption on REST and some other important things, maybe backups recovery. but what we could do we could significantly raise up the level of abstraction and provide a reasonable default size that most of the time our life is not that miserable it is normal yes let's take one inch depth dive into that machinery it's a little bit more sophisticated and challenging for every resource coming from different services which might come from different vendors and might have different api's also coming from different vendors and probably intended for different deployment locations I need to specify by how to acquire these resources, how to configure them, how to use them, and how to operate them. So if we use this simple to-do example, that more or less what happens. And again, it's very, very simplistic example. One region deployment, very few resources, but still, you're even not unaware about some of them because they are created behind the hood, like IAM rule. Why the hell you need to know what is it? unless you have to. And different APIs, again, performance considerations could drive us to use different APIs of the system. Let's see what happens with it. Finished, done. It took two minutes, almost. Or only running the test. The total time is about five minutes. Okay, let's scrap resources. I wanted to show you only one thing. I have one second for that. Let's see. That's important. You see this? This is a lambda function created for a particular function, for a particular source function. But please pay attention what is there. It's a very simple shim file, shim code, generated automatically from the source there is no application code there application code resides on bucket and it's dynamically brought in through cloud import system it's very important for a round-trip like that when you change your code you could quickly redeploy it so let's grab the resources There are about a dozen of vendors in infrastructure from code field generally. Many of them are working with Python, now providing solutions for Python. Most of them are Python compiler, C Python compiler for Python runtime with one notable exception of Cloudflare, which provides it for Node.js. But the potential is much bigger. We could use different compiler frontends, not only Python. It could be PyPy, for example, or Titan. We could use different extensions in Go, Rust, C++. The point is not that these technologies are unavailable. They are. But the whole experience of development is not seamless. It's pretty cumbersome to do it and deploy in cloud. Unless you masochistically enjoy dealing with documents, files, and containers and all this stuff. JSON is an unfortunate, in my opinion, story because it's stuck in Python 2.7, but Python net is pretty good one, pretty advanced, and you could generate your You provide code for target.net runtime. The point is that your runtime environment determines what extensions you could use. C Python in proc integration limits me with the same process space. I cannot use directly C sharp code unless I convert it somehow through GraalVM or pretty sophisticated stuff. The same is enough. That brings us to interesting observation where infrastructure from code technology takes its place in domain dreaming design hexagonal architecture. What responsibility it takes? It takes responsibility on port binding to adapters and optionally and but very powerfully automatic compilation of application logic to cloud native orchestration engine. like step function on Amazon. Domain logic could be encoded in different languages. We all wanted them to be encoded in Python, but it doesn't have to. If you have legacy or useful code, especially in supportive subdomains, on GeneXus, I know it's developed in the other languages, you could use it. That leads us to more open-end architecture when application logic is compiled into workflow, cloud-native workflow engine, invokes computation engines, for example, in Python, uses in-proc extensions available for Python, Go, Rust, C, C++, and out-of-proc integrations with whatever you want through sidecar or Lambda extensions, all kind of that technology. So the answer to the question, And how far could we go? As long as there's a market for that. The sky's the limit. It's virtually unlimited. And Python is very well positioned to be cloud-native language. What is needed? Let Python be Python. That's probably the most important message here. For example, if we elicit protocols from PEPS and standard library, we could provide cloud implementations of this protocol. example would be DB connection or path we could do the same for popular open source de facto interfaces and bind them to cloud native solutions in this example sentiment analysis through AWS comprehend believe me you don't want to know how comprehend native API looks like very unfriendly so the objective is is to unlock Python web potential by adjusting runtime and a compiler for cloud environment. Cloud is a computer, it's a super computer. And don't forget about library shelf. It's an extremely critical piece of technology here. And it's not academic. My colleague and best friend, Yitzhak, will give you some real life examples of that. Thank you. Good luck.

Speaker 2 [17:14]

Okay, so a little bit about myself. I'm the VP product in BST Labs. It's a subsidiary of Black Swan, where I lead the Kiosk project, which is based on the IFC infrastructure. From my professional experience point of view, I come from the cybersecurity domain, where I have more than 25 years of experience there. In the last three years, I was the chief security and privacy officer at Black Swan. Part of the time, I was also the DevOps and FinOps there. You know, startup, everybody needs to do more than one role. And in the last year, I also achieved some childhood dream and wrote a child book. This is the book. And the reason that I speak a lot about myself is just to completely convince you that I am not a software developer. In fact, the last time that I actually wrote a code was when I was 18, which was a long, long, very long time ago, where I actually looked like this. And the main programming language that I used was, I don't know if they exist today, was Pascal, and Assembly, and Cobol, and Basic. Since today someone mentioned Commodore, so I related to that. So when Asha reached me and told me come join to this IFC journey and told me what it is, I was of course suspicious because first it sounds like magic, second they come from the cybersecurity domain. In the cybersecurity domain you don't trust anyone and nothing, especially humans, especially software developers. But like you said, I'm not a developer, so who is the most suitable person to test it? And two years later, and after I wrote more than tens of applications above Kiosk and above this technology, I can say that the magic is real. And the only challenge that I had, writing a lot of applications, of course I will speak in a minute. I wrote a lot of applications related to my domain, to cybersecurity and Phenops and et cetera. The main challenge was to find the equivalent code in Python to what I was familiar with Pascal, yes, from the history. And since then, a lot of application was written. And like I said, the magic is real. Of course, we make a long way since then. There are applications running in both Kiosk and the public cloud for a lot of categories. I gained some... I am showing you some statistics, two main observations. First, the average time that it takes to bring something from scratch to the cloud is several days. And you can see that the average ratio that is being saved by using the IFC technology is around 1 to 7. You can see also that HR application takes a lot of time. This is due to privacy, a lot of double checks there. And I also summarized, aggregated all the code, total lines of code that was saved only for this project. Yes, this is only projects running daily in production in our company and also partners. I reached to 75, more than 75,000 lines of code. I tried to estimate how much is it in time. I, of course, went to chat GPT and ask him How long does it take to write a Python code? He said 13 seconds. I must admit that I never wrote a line of code in 13 seconds. But even if it's 13 seconds, it's still 270 hours, which is a lot of time that's being saved. And again, you need to focus only on the Python code. So I said, I asked myself, what will I present today just to convince you how the magic is real. Thanks to PyCon, the answer was very clear. I think nobody in the first day could miss to hear about pandas and polars. So I will say I will try it myself. And so I basically, in the beginning, I did exactly like the presentation, like what was shown in the sessions. I took a six million record of a parquet file, and I basically wrote two different functions. I guess the basic thing that they are doing, they are, of course, reading the file, taking relevant columns, and I just did some basic sorting function on it. I don't know. I must say that this took 20 lines of code. It didn't. It should take me five minutes. It took me around one hour. But I was able to do that. So at first, I ran it locally on my local machine. And as expected, Pandas was like 23 seconds. Polar was seven seconds. But my main thought or what I was wondering following the sessions that I had was, what happens on the cloud? Because it was interesting for me to see if I will get the same results. Also, in Cloud Functions, I specifically tested it on AWS Lambda. So I wanted to see if serverless function, where you cannot control the CPUs or the resources that are located, will have the same results. So from there, to move to the cloud like Asher thought was very, very easy. All I need to go to my terminal and say, chaos test run remote, and the magic happened. And 35 seconds later, this code was on the cloud, two different functions to run the test. And then I could just grab the data out of it. And as you can see, this is from, for those of you familiar, it's actual logs, the log file of the Lambdas. Pandas was 24 seconds. And Polars was even shorter than in my local machine, only four seconds. And this is basically, I think, demonstrate how easy it was for me to move to the cloud. Because I just had the idea, I wrote it locally on my machine, I wrote the code on my local machine, Kiosk Test Run Remote deployed on, in this case, AWS, can be multi-cloud. And that's it. We have a lot of use cases in our medium. You can check it out. And just to wrap everything, we really believe in this technology. We really believe in this journey. We encourage all of you to take a part of it. make us, help us to, to take, to, sorry, help us to reach the cloud to everyone. And the same as this was the local machine. And that's it. Thank you.

Speaker 3 [24:37]

Thanks very much perfect with perfect with the time we experienced

Speaker 2 [24:43]

You scared me with these talks.

Speaker 3 [24:45]

We're very sorry. There's only one question in the slide. How does PyIFC handle, and now there's a number of things, auto retry, stack drift, change set, rollback, layout stacks, and remain cloud agnostic? Maybe this will. How does pi FC handle auto retry stack drift maybe auto retry? How does that?

Speaker 1 [25:04]

that cloud does it we don't I mean when you launch serverless computation on cloud it takes care for it right it takes care for scaling unless you have real strong reason to do it yourself want to go under than under the hood cloud does it for it what with what we do I've see we simplify utilization of cloud resources which are available exactly as normal compiler simplifies CPU cache on your on your computer you don't deal with CPU cache you don't many people don't know how many caches there are compiler does it for you

Speaker 3 [25:51]

Perfect, thanks. Dear Faust, I would suggest to get in touch with these two gentlemen directly for more questions. Right, any more questions? Oh no, here's one more. Is there a deletion process for the created resources? A deletion process for the created resources. Yes, it's the same argument.

Speaker 1 [26:08]

When you shut down the stack, Cloud takes care of it.

Speaker 2 [26:11]

scale for you yes the same chaos test shut down like shut down it shut down everything automatically you can run a test for several minutes and everything

Speaker 1 [26:18]

At the point, the cloud does 80%, 90% of the job for you. It's just not easy to use. So when you shut down the stack, all resources are gone. Huge cost saving. Tens of thousands of dollars per month.

Speaker 3 [26:40]

Any more questions from the room doesn't look like it all right. Thanks very much

Speaker 1 [26:49]

Thank you, guys. Very impressive. Keep in touch. And thanks to all the organizers of that wonderful conference.