Rafal Wilinski: Dynobase, Single-table Design and the Future of DynamoDB Development

About Rafal

Rafal is a cloud-native software engineer, AWS consultant and founder of Dynobase. After hours he's a big supporter of the Serverless paradigm, wannabe generative artist, cyclist and calisthenics fan.

You can find him online on Twitter, GitHub, and his website.

Transcript

Adam: Hey everyone. Welcome to AWS FM, a live audio show with guests from around the AWS community. I'm your host Adam Elmore, and today I am joined by Rafal Wilinski. Hi Rafal.

Rafal: Hi. Thanks for having me.

Adam: Yeah. Thanks for joining. So, I wanted to start with your story. Your young career. If you could take me through getting in technology, getting into the cloud. However you want to start.

Rafal: Yeah, sure. Of course. Since I was a child, I think, I was born as a nerd. I was playing with Lego blocks and then I met my first computer. I was amazed by the technology, especially by the games, and I was spending an extraordinary amount of time playing random video games, but towards the end of each video game I was kind of dissatisfied. The content is limited. And there is nothing more than the programmer's creative, for me, for gamer. So I started messing up with the configuration files, and then I started messing up with 3D models and things like that. Some basic scripting languages and so on and so forth.

Rafal: And I think that when I was 15 or 16 I decided, hey, maybe it's time to create something from scratch, like totally. I knew some basics of C or C++, JavaScript isn't a super complicated language, so I started using an engine that was called Unity 3D. And that allowed me to create games for PC, for Flash, for Android, later for iOS. And that was like 2012, 2013, something like that. So the mobile revolution wasn't yet there. There was a lot of things that were still in the early days, and I decided to create my own game that was actually called Voxel Rush. This was very minimalistic game because I am lacking graphical skills, so I was trying to get around this limitation by creating this dystopian, minimalistic racer through this kind of minimalist landscape.

Rafal: And I released that game on Android and because there was a lack of games, there was shortage of games, like processors have 200 megahertz. GPUs wasn't there. But the game was kind of fun, and to my surprise it became a success. There was like first 100 downloads, then was 1,000 downloads, then like 10,000. Then a publisher reach out to me. When I was 17, I was still in school but I had a publisher. I started making money through some ads revenue and through some in-app purchases. Actually my game even won some kind of competition for indie game. I managed to visit London. I think it opened my career, and I really wanted to be into game development like really, really hard. I've applied to an internship to the CD Projekt, you know the creators of Witcher and Cyberpunk. They rejected me, but okay. It only gave me that feeling that just you wait, I'm going to create something even greater.

Adam: Oh geez, you're 17, if you knew what I was doing when I was 17. I don't think I was even using a computer when I was 17.

Rafal: So then I was developing that game. Everything had been running smoothly, but my parents were like, "You know what, game development isn't a serious job. You should do some kind of mechanical engineering or civil engineering or things like that. Creating games isn't a legit job." And I was like, "Well maybe they are right." Maybe let's try web development. So I got into this new, shiny thing which was called Node JS. I started an internship at company called Wikia, which is like a sister company to Wikipedia. I learned how to work at scale, with scale, because they have massive scale. There were so many servers and microservices all around. I was simply, I got super interested in all of that. I pursued certification they called Architect Associate. And then it was like a second job and then a third job. Then I was working for other companies doing only cloud stuff.

Rafal: One day I was kind of dissatisfied with my current setup, so I started working on my own personal brand. I started creating some blog posts. I wanted to become kind of a personality in this growing niche called serverless. And so I wrote a few blog posts and someday this guy called Zack Kanter reach out to me saying on Twitter, "Hey, I like what you are doing. We are doing stuff on Stedi kind of same way. So maybe let's schedule an hour or half and let's talk about how we can work together." And that started something really great, and I'm working on Stedi for almost year and a half, right now. And it's been great. And I totally missed the part about Dynobase but I think we can talk about it a little bit later.

Adam: Yeah, we'll get to it. And we'll talk about Stedi. Anyone's that listened to any of these knows I have a fascination with Stedi. We'll talk plenty about that. But I've sort of followed you on Twitter for a long time, and I remember your first year recap on Dynobase and when you'd sold like $10,000 worth of Dynobase licenses. Then just recently in August you had your year two recap, and you're now doing close to $10,000 a month. Could you kind of, first, correct me if any of that's wrong, but second, just talk about Dynobase and the origins of that. When you decided you wanted to create this better dev experience for DynamoDB.

Rafal: Yeah, sure, of course. So it all started more than two years ago. I think like two and a half years ago. I was working as a cloud consultant. I was working on a project which had a multi-talent requirement, and each talent could have been in a different region. Actually, each talent had a separate table. So because there was a separate account for development, a separate account for staging, separate account for production, pre-production. Some accounts were in U.S. Some accounts were in Australia. I was jumping between the tables all the time. And AWS console is structured this way that you can be logged at one time, only one region, only one account. So I ended up having like 10 instances of Chrome open, or playing with some shady extensions to get around that limitation.

Rafal: I was super dissatisfied with this experience and I was like, "Hey this whole console thing, it isn't pretty. Let's be honest." After all, it's just a bunch of SDK calls with a facade in front of it. So maybe I can just get data off this SDK, cook up some credentials from the profile's file, give it a little bit nicer front end, and here we go. So I rushed into a POC around June 2019. I started scanning the profiles. I displayed tab per profile and boom. It started working. I pitched the idea to a few of my colleagues that were also cloud consultants working on some, many projects, many accounts. I was like, "Hell yeah, this is what we need." Because jumping across accounts is super annoying, the search experience, the filtering experience. It is super annoying.

Rafal: There are so many terms that are hard to grasp, especially for a beginner. Like what's the difference between a scanner query or what the heck is a local index or global secondary index. Annoying. So I identified that the database to DynamoDB is great because it covers so many services at amazon.com and all the other things that Amazon creates. So the technology is definitely there, but the bridge from the developer, especially from the beginner, to that technology, like that bridge doesn't exist.

Rafal: So I realized that, hey maybe that's, maybe this is this kind of unique opportunity that you don't get many in your life. Maybe that's the thing I should pursue, and what's the worse thing that could happen? If I'm not going to sell this thing maybe it's just going to turn up into a great open source project, and that open source project is going to drive me a little bit more of an audience, and maybe some contracts. There's simply no downside to this endeavor. So I decided to go. I spent probably two or three next months polishing that idea, adding better tables, better personal experience. Things that I thought are important, which turned out to be totally not true because customers wanted something totally different. But after two or three months working in this kind of ecstasy, like When you start a project, you are think probably only about this one thing.

Rafal: And when I was about to finish, I was in Australia at that time, I logged in into Twitter one day and I saw that AWS introduced no SQL workbench and I was like, "No, no this can't be true." And I was devastated because the project was almost ready to be released, and it turned out Amazon created their own tool. There was no chance I could compete with them. I mean, they have an infinite amount of money, the brightest engineers in the industry. So how can I create something better? And for one day I was really depressed because on the second day I decided, "Hey, let's give it a try. Let's see what is this all about." I don't know that it, and it seemed like many of the bad patterns have been repeated from the console.

Rafal: Actually they focus on totally different things that I wanted to focus on like no SQL workbench from the very beginning. IAMs to be a data modeling tool which you use before the development. While I was scratching my own itch, and my own itch was problem with working with data in production, on staging, on testing environment, like debugging many things. Debugging actual data. I found remaining bits of motivation in my head and I just pushed it across the finish line because that would be stupid to not do that. I've released it to the public. And many things, some people got really excited. Some people opened it and said that's not for me.

Rafal: But one person that initially was a customer made a big impact because the person basically sends me a few pages essay or report like what is good, what is wrong, what would he improve, how big it could be. And that person later on, [Privan 00:12:26], became a co-founder. Because I decided to team up with him saying, "Hey, what's the worse thing that could happen." This guy seems to have great ideas. He knows how to grow. He knows how to design. SO let's team up together. And let's pursue that together.

Rafal: And we are working together today and hopefully we are going to work together years to come. When teamed up we completely redesigned Dynobase. We basically rewrote it from scratch. We release the free option. We went with only paid model with seven days of trial. After another three or four months of hard work, we re-released that thing. And I was genuinely stoked when people started buying this thing. You know, some engineers, some people are willing to pay like $100 or $200 for this. What? It's crazy.

Rafal: Once you earn at least one dollar on the internet selling your online products like a book, a course, or something, your perspective dramatically changes, because your input can be translated directly to output, to money. That's great. So I think that's it when it comes to the history.

Adam: So I want to dive into some kind of more specific features of Dynobase and, I think for me, the initial pain that you had in managing multiple accounts, I do freelance work and I have to do the Chrome profiles, different profiles for each client, to keep multiple browser windows open, and keep the console focused on the specific customers. But that's super painful. I had Tomasz and Maciej, your colleagues from Stedi. Their building Cloudash which takes Cloud Watch to your local machine. Similarly, to Dynobase taking DynamoDB. I think there's value in that, and that's sort of the thing that sold me. What are some of the other key features, things that you've heard from customers that sold them in the first place? Why they decided to buy Dynobase?

Rafal: Yeah, sure. For me the key issue was, for instance, browsing the data. Querying it or scanning it. The DynamoDB console had the limitation where they could only display 100 items at once and it wasn't working in a streaming monitor. Imagination was super slow because it was doing the hops between your back-end and front-end and back-end and front-end. So if you're using scan with some filter expression, searching for some kind of value was super slow. So that was like the initial key feature for me to be able to find relevant pieces of data super fast and I wanted to make sure that we're the best. And I feel like I achieved that.

Rafal: Another thing that was problematic, especially to the beginners, to the newcomers of the cloud, and there are lots of people that are starting to use cloud, it's that they come, for instance, from MySQL background or preposterous background, where they can use a where clause or any attribute. And in DynamoDB where you are using query, you can only use index attributes. And it's like why can't find some value based on email or create an app attribute. So I was like maybe I can extract it in a way. Maybe I can just give you a form, tell me what you would like to find, and we'll figure it out. Whether that's going to be a scan, whether that's going to be a query. Maybe there is some kind of suitable index to do that. Maybe let the machine figure it out because that's not super complicated. And you don't have to know your table structure by heart. So that was another feature.

Rafal: It's actually like a bigger motive of making the DynamoDB more accessible to more people. So, for instance, when you create a query that satisfies your needs you can now just export the parameters that are used under the hood inside Dynobase to create that query so you can replicate the results in your application. In your Lambda, or whatever, if you like this also helping a lot of people.

Adam: That's a huge time saver just riding out just the single SDK call to DynamoDB is non-trivial. I mean there's a lot there to accept that you're generating that, that's saving a ton of time.

Rafal: Yeah, exactly. And we started with just querying and scanning with just reading the data. Now we are creating Operation Builder, which spits out ready code for update operations, for delete operations. We are going to have transactions a little bit, probably, this quarter. I don't know. And there is also a variety of other features like, for instance, in the AWS console, correct me if I'm wrong, there is no history of queries that you've made. So if you wanted to use, for instance, browser native and a function you were brought to another page not to your previous query. So I also added a history. I also added bookmarks because I've had some queries that I've been executing like you know 10 times a day and I didn't had a chance to bookmark it even using URL or things like that because the query parameters are not encoded in the URL.

Rafal: I feel like there were lots of small features that accumulated into this package that could provide a tremendous value. That could accumulate a big amount of tiny time savings. Of tiny improvements to the UX. Let me think, what we also have. For instance, offline support. So when you are using the browser DynamoDB you can only connect of the tables that you have, well, in a cloud. There's no option to connect with offline tables. And I know that many people that are also starting working with the clouds. They're like, "Hey, I want to have 100% offline experience. I want to develop my software in plane." I never understand that argument because replicating-

Adam: I don't like being in planes so I definitely don't want to work on planes.

Rafal: Yeah but many people want to be able to recreate the whole stack using local stack or some kind of weird tools. I'm against that but if people want it then-

Adam: Yeah, then you support that.

Rafal: Yeah, exactly.

Adam: And you just recently rolled out new features for single table design. I want to talk about that. You're right in the middle of that, right? That's sort of rolling in now?

Rafal: Yeah.

Adam: Could you speak to the pain, I guess, even, just frame the problem. So what is single table design? Why is it painful? And then how does Dynobase come in and help?

Rafal: DynamoDB is a non-relational database but it is capable of storing relations, or relational data, if decided, using single table design, which is basically creating your items and, I would say, allocating them across the table space in a smart way. Using partitions, using sort keys, using global secondary keys, and massaging your data mobile into items that are located in a small proximity within a partition or a thing like that. And this is really hard problem, I would say, because when you are working with relational databases you basically create a table for each entity. Maybe you have some tables for that are joining some entity, like you're doing many-to-many relationships or one-to-many relationships. And everything seems to be logical. In DynamoDB you put all of your entities into one table and it seems wrong. It's counterintuitive.

Adam: There's a learning curve for sure.

Rafal: There is a learning curve, so you need to figure it out, what kind of items you need. What kind of keys they should have, what kind of attributes, what you would like to index, how you're going to get the relevant pieces of data. What are your access patterns? So you need to come up with a plan. And simply there wasn't a good tool to create that I mean like I have been speaking with folks from the DynamoDB space like how are you approaching creating DynamoDB models? Single table models. And there is a work secret, no SQL workbench, but not everyone like it because it has some opinions on how it should be made, and many people are using Excel spreadsheet to do that. This is kind of interesting that best tool to create a single table model is Excel. Why?

Rafal: Well, I discovered that it gives you great clarity and great flexibility. It's just super adjustable to your needs. So I took an Excel. I took [inaudible 00:22:14] web modeler, that he uses on his show. And I wanted to merge those two ideas into something that can take the best pieces from Excel, some DynamoDB features or tenets or composite keys, and I would say create and opinionated Excel for modeling needs that helps you to massage your data. To create the items, create access patterns. Then use those abstract access patterns to query your model to check whether your assumptions are good.

Rafal: Once you have your model we want to also generate code for you. So once you have your model, your abstract model, we can give you a library that is going to be a drop, like a replacement, for the AWS DynamoDB SDK for your Lambda. But yeah that's the future. Right now we have only a MDB, a single table designer, which should help you create your model. And yeah, we are desperately looking for feedback because, after all, that's the tool for customers. We want to make that the best thing you can imagine. To make that a little bit more approachable.

Adam: I'd be curious of your thoughts, you're kind of on the front lines of DynamoDB development experience. And I wonder if you have any more general thoughts on the future of building on DynamoDB. In particular, I think about the way serverless is moving and some of the recent stuff, the step function stuff that just came out so more and more we're bolting together services and writing less Lambda code. How do you see DynamoDB changing or the development experiment evolving with serverless, if you have any thoughts on that.

Rafal: That's a great question and I don't have any pre-made answer to that.

Adam: The thing is I do a lot of VTL. I interact with DynamoDB through VTL quite a lot and I wonder... I would pay whatever amount of money to make that experience better. I wonder does Dynobase sort of branch, I don't know if it could branch into those. I love the idea that getting into the run time and injecting itself into my Lambdas. I just wonder sometimes about how is that experience going to change? Or how is writing these single purpose functions that seems to be going away, which I think is good. But it makes me wonder how what I know about writing DynamoDB code, how is that going to change maybe in the future?

Rafal: That's a great question. Not longer than a year ago DynamoDB introduced a software for PartiQL so now you can use a SQL-like language to read and write data. That's definitely an alternative method. It's closer to the hearts of many developers, but further from the, I would say, truth. Because when you write, select, star from X or something that's going to be translated into SQL-er query under the hood. So you might not understand what's happening, but that's PartiQL. I'm not a big fan, actually, because of the reasons that they mentioned. How is it going? Well, I still feel like this whole concept of putting all your entities into one table is tricky, it's too hard. I feel like there's some kind of abstraction missing in the middle. Maybe AWS could somehow, I don't know how, but give you a notion of multiple tables, and under the hood that would be just one table.

Adam: It's like an optimization step that they're sort of hiding the single table. [inaudible 00:26:34] these from you. I remember sending a message to Alex DeBrie, just DMing on Twitter. It's been several months ago, but just like around the idea of so if you're familiar with Prisma, the idea of the model, where you're just defining entities. And then something that's generating all the single table best practices, like how you manage many-to-manys and one-to-manys and all of that stuff, just being machine generated. And it feels to me like that's where Dynobase is headed, and that's super exciting to me because that's something that I was like, "Ah, someone needs to build this. Do I need to build it? I don't think I'm the person to build that." And I think it fits perfectly in the wheelhouse of Dynobase. So this is me giving you more validation, if you needed it, to keep going and keep pushing on that front.

Rafal: Yeah, another thing that I feel like could be on the roadmap is that a lot of people are getting into AWS because of Amplify. It's an addictive drug because you define a data model and you get a library, you get your tables functions, I don't know, even some AI capabilities. But right now, correct me if I'm wrong, but Amplify is creating multiple tables?

Adam: Yeah, right.

Rafal: And so someday maybe that could create into a single table model. That would be great. But I feel like, correct me if I'm wrong, that the model in Amplify is defined by a GraphQL. And the GraphQL data model is not giving you enough information to create a good single table model because when you're creating a single table model you have to take into account things like if this value is high cardinality, or if this value is going to be unique, or am I going to edit this record frequently? If yes, is it only this one record should be edited, or maybe multiple records would be edited? Like, how big is going to be that item? So there are many, many things that you are losing when you're just expressing your data model using GraphQL. Maybe some extra directives in GraphQL could help to create an efficient single table model based on that. But I don't know.

Adam: Yeah, it does feel. I mean, I've spoken about it. It feels like, I do a lot of AppSync stuff, GraphQL seems inherently opposed to the idea of single table design. You're not getting a lot of the benefits and that's a bummer to me because I am fascinated by both things. I do a lot of work with GraphQL and I like it from a front-end, full-stack perspective. But then I'm just a nerd about you and Alex and all of the evangelizing of single table design is exciting to me as well. It's tough because it does feel like they're on two ends of the spectrum, that it's hard to marry them.

Rafal: Yeah, exactly. And in single table design you need to have strictly defined access patterns, whereas in GraphQL, well you know, there's a graph. You can traverse it like almost endlessly if you don't put the limitations in place.

Adam: And that's the feature. That's one of the main selling points, is that from the front-end you can kind of dictate the access patterns on the fly. That sort of flies in the face of everything that's great about Dynamo and single table.

Rafal: Yeah, exactly.

Adam: One thing I've had some of your colleagues on the show and it's not a secret that I'm super fascinated by Stedi. I wonder if you could share some of your experiences working there. A day in the life at Stedi, what you've experienced.

Rafal: Stedi is quite a unique place because everyone there wants to achieve something and they don't need external motivation to do so. Everyone is super intrinsically motivated. And everyone treats their products actually because we believe you are, each team is creating a product, they are developing them on their own. They don't need managers, they don't need leaders. Every team is self-organized. Every team is actually inventing features, designing features, implementing them from start to finish. We have a lot of freedom to create and to invent and that's great.

Rafal: If you have an idea that you would like to execute or that you think is going to be beneficial for the company, you simply start a PR FAQ for those who don't know it's like starting from backwards. It's taken from the Amazon culture where you start at product by creating the release notice that you send to the public like, "Hey today we announce, I don't know, elastic compute service." And based on that you figure out how that should look like, and then you figure out the technicals. Then you gather the team, and then you start implementing that. If you have a good idea that you think the company is going to benefit from you have full freedom to do so. And that's great.

Rafal: Also, there is a really minimal amount of meetings. Like probably I have three or four per week. So I have a lot of time to do coding. We embrace totally [inaudible 00:32:17] culture so we write important things down. We are using Rewatch to watch meetings that you were unable to attend to because we are globally distributed. And some calls take place when it's two a.m. in central Europe. SO things are happening all the time, 24 hours Stedi is working. You can wake up and see that some initiative has started and some other initiative has been deprecated. It's constantly changing, it's constantly reconfiguring. And I think it's healthy, especially if you like to sharpen your skills. Just strive to be better. It's good be surrounded with like-minded people who like to code and like their job and want to create something great.

Adam: Do you get any internal DynamoDB questions now that with what you've done with Dynobase? Have you become a resident expert?

Rafal: I get a lot of questions but sometimes I simply don't know. I've met people doing working at Stedi that know so much better about AWS and DynamoDB. I no longer consider myself an expert after seeing all the crazy patterns that we invented at Stedi. It's really I feel like we are creating some kind of cutting-edge tech or we are pushing the cloud to the limits when it comes to some use cases. Yeah, I still feel like a beginner. I'm on those people.

Adam: I followed Zack as well for a long time. He's an excellent follow on Twitter, and I didn't know until talking with Tomasz and Maciej that he doesn't have an engineering background. That completely blew me away because just in terms of leaders in the serverless space, thought-leaders, he's right up there, right? What's it like, could you share anything working for Zack? Working with Zack?

Rafal: Yeah, sure. I think it's great. The one thing I really like from the very beginning is that he understands engineering and he puts engineering in a first place. It's not about marketing, it's not about business, or things like that. I think he prioritizes that. Many co founders think engineering is this necessary sad thing that you need to do to create a product, where Zack embraces the engineering. He understands that this is really core. He know how engineers work. He know many engineering terms. He is, as you said, really, really fluent in all those things so that's great. I don't know what I can say.

Adam: THat's great. I'm kind of putting you on the spot here and you probably didn't expect so many questions about Stedi. I've got a question. I'm going to count this as a question. So Michael Barr added me on Twitter and asked if I was becoming a Stedi recruiter. I have to say I'm not on the payroll at Stedi. No one has given me anything for saying all the things that I say. I just have a technical crush, like a career crush, on Stedi.

Rafal: You know we are hiring.

Adam: Oh, there you go. So I wanted to talk to you a little bit, shifting gears, you've said in your recap how important learning in public has been for you in your career and specifically for Dynobase. Could you share a little bit maybe about your experiences on Twitter and what you've learned in sharing so much publicly?

Rafal: Learning in public helped me landed that job. I started blogging about things that I've learned about. I've created this blog post about globally distributed [inaudible 00:36:33] tables, and Lambdas on edge, routine to the DynamoDB, and that... When I decided to write the blog post I didn't know about that stuff a lot, but I decided to simply document my journey. And that has been seen, and that has been rewarded so that's great. And I saw so many similar stories on Twitter where people just basically document their journey. They create those digital gardens of some thoughts that I loosely cobbled together. And in a world where writing well becomes so important skill, it is simply being recognized. Especially in engineering, people like that are needed, and I want it.

Rafal: So, no, what can I say? It helps. There's a zero downside to it. You can only get a little bit of criticism because you make some grammar mistakes. Some stuff that you wrote might be true or might you have missed some kind of detail. But after all, probably thousands of people, or hundreds of developers, are going to benefit from your learnings, from the things that you've discovered. So you're doing not only a service to yourself but also to other people so this is only great. I can't see any downside. And when it comes to learning in public, or making in public, when it comes to product, it's like a free marketing. Especially in a developer niche.

Rafal: People that are into software engineering many often times don't like the classical marketing full of buzzwords and things like that. You know, AI-powered, blockchain, serverless, things like that. It's like you have this kind of red alert blinking light in your head when there's too much buzzwords. But if you're documenting like, "Hey I wanted to implement this. What do you think?" Or maybe see if you probably are going to be interested in something that's a free marketing. That's also feedback. Feedback is super valuable when you're creating products because your initial vision of something might be totally not needed by people. Validating idea is super important thing so you also get that for free.

Adam: And I followed closely enough that I remember when you posted, when you launched Getaboard, which is like a create-a-job-board page. I guess you validated that idea. At this point your bandwidth is strapped, and you're focused on Dynobase. Is that basically the story there?

Rafal: Yeah, so for people who don't know, I wanted to create something new. The startup called Getaboard it was basically, I don't know, think of Webflow but for job boards. If you want to create a job board for rabbit trainers, or women in code, or whatever, you can pick your niche, and you can create a job board for that specific niche in seconds. I like that idea. I created an MVP in seven days because I really wanted to see what I'm capable of doing that, but there is a surprising amount of not coding related things that you need to do properly when you want to launch a startup, or launch a successful product. Coding is probably like 20% of the success. You need to come up with great story, you need to know how to market that. There is SEO aspects of how you're going to be discovered that's really a top one.

Rafal: And I simply discovered that I don't have the capacity to develop Dynobase, to work on Stedi, to have a healthy life, with friends, girlfriend, things like that, and I'm not able to do all that at the same time.

Adam: Yeah, it's a lot.

Rafal: So I decided to abandon this idea. Right now it's in the freezer.

Adam: Could be thawed out eventually, but no plans.

Rafal: Yeah. We'll see.

Adam: So what is the future for Rafal? Do you have, I guess you're all in on Dynobase, obviously you're at Stedi. Are there other plans that you have? Things that you want to move into or just anything you'd share?

Rafal: Interesting. I don't know. The landscape at Stedi is constantly reconfiguring so each week are presented with a new challenge and I feel like this keeps me really entertained. It's satisfied my need to find new things, to start new things, because there's always something to create something great with great people and get paid for it.

Adam: Hard to beat.

Rafal: That's super fun. I feel challenged and it feels great. Apart from that I don't know. I have a backlog of things to implement at Dynobase. We want to support more languages when it come to code-gen. There are obviously bugs, unfortunately, there are always bugs in software. No, I don't know.

Adam: That's fine. I haven't thought about what I'm doing next week so I don't really know why I ask. I feel like I spend so much time talking to people about what they've done I want to give you space if there's things you're excited about in the future. I guess here's something I'd love to get from you because I feel like, I want to make sure, we're talking about things that interest people. And people seem to be really interested in controversial hot takes. So do you any hot takes, particularly in technology? That would be ideal, but generally any hot takes that I could market this episode with on social?

Rafal: Oh my.

Adam: And take out of context, entirely.

Rafal: My teammates know that I am not a big proponent of unit testing, for instance. I don't like it, especially in a serverless environment. But you have so many moving pieces and testing each piece in a separation is kind of counterproductive because you have to assume your interfaces. And you have to assume that everything works. I'm a big fan of testing things as a whole in an integrated, or even end-to-end, manner. Especially unit tests are not testing assumptions about IAM or things like that so.

Adam: I don't know if this is a hot take. I actually think this is becoming... you're the second person on the show that has said they're not big into unit testing. So I think the serverless movement, that must become, that's just par. It's not hot enough, Rafal, I need hotter.

Rafal: You need hotter?

Adam: Something controversial. Yeah, like you just don't like testing. Say that.

Rafal: Yeah, I don't like testing, that's true.

Adam: Okay, perfect. We'll throw that up on the internet.

Rafal: I don't know how to frame this whole thing, but I don't know if you are following Peter Level on Twitter, the guy behind Nomad List. So here's a thing, he built a business that is making right now something like $2 million per year and it's a single PHP file, hosted on a single VPS. No master recovery, no high availability, no cutting edge tech, no DynamoDB, no cloud. Just FTP, PHP, VPS and that's it. And you make money, you make a shit load of money. Do you need serverless for all that? Five land tests?

Adam: It does make me question my career choices at times when I see [inaudible 00:45:29].

Rafal: Many of those things seem to be so overly complicated and I often think about it like we create this crazy infrastructure diagrams and engineering documents about how we should solve a particular problem and sometimes I'm thinking, hey, if we would've used Django or Ruby on Rails and hosted on EC2, like T2 Micro or things like that, maybe we could get away with that for the next two or three years. I know it's a global ultima, I know it's only a temporary solution. But hey, like world, the whole world is working on top of temporary solutions.

Adam: Yeah, we need that perspective. It's easy to get very far down the serverless purist and lose site where it meets business needs where the real world comes into play. And I think the more perspective we have from that very customer obsessed, like just get the thing that they need out there, I think that helps balance out. Keeps us from going too far down that path.

Rafal: In some sense I would frame it as just being, the fun of being practical. Which is totally not a hot take, it's a cold take, I would say.

Adam: We'll take cold takes. That's good.

Rafal: Yeah, cold takes. What else? I'm super excited about how this whole CloudFlare thing is going to play out because you have a big CBN, we have distributed computes, we have better is free. Objectively it's super, super cheap. So I'm really looking forward, how this thing is going to play out because they are on this very ambitious mission to become like fourth cloud vendor as far as I remember. And I would really love to take CloudFlare, take Pulumi? And do this blasphemy of not doing CK and see how this works because it really makes me super excited. It's really a breath of fresh air into the industry.

Adam: Yeah I would love to hear how that it goes for you because that's something I very much got my popcorn out. I'm enjoying the show and I want to see where it goes, but I don't know if I'll take the time to actually go down and play those curiosities out, I guess. It's been so great just to have you on and to catch up. I think, I said I followed you for a long time on Twitter first time meeting you face to face. I've looked forward to this so thank you so much for taking the time.

Rafal: Yeah, thank you, too.

Adam: And thanks everybody for joining. We'll be back next week. We got three guests next week so yeah stay tuned and we look forward to seeing you all next week.

Rafal: Thanks for having me. Bye.