 a bit much. Okay, can I just have the, how do I get to the browser if I wanted to? Just so that for those who are interested, I usually keep a version of my talk online here. And I've got ten minutes, right? I can't, I'm not used to, can I just say that the keyboard on Macs are terrible. You should get, ThinkPad is the future guys, ThinkPad. And hold on, let me just set a timer. Okay, whatever. Okay, maybe I'll go back to that. Yeah, this is mostly the talk. Serverless Lock-in. I think lock-in is a pretty important topic. I mean, it's something that I am concerned about because, well, let's just start. What is lock-in? Lock-in is like, you know, we all are buying into the software services offered by some company, and this one's AWS. And I'm at least concerned is like, I'm integrating with Serverless, I'm integrating with the Lambda APIs, I'm integrating with S3, I'm integrating with this. If I wanted to choose another vendor, would that really be realistically possible? It makes me feel uneasy, so I have been thinking about it, and it's definitely a hot topic nowadays. Just the last month, there was a blog on the Amazon website arguing that there's no such thing as vendor lock-in. It's only about switching costs, which is a better argument to do. But switching costs are very difficult to ascertain, aren't they? Let's just go for it. So there's many reasons why we all choose Serverless. I think we all know the reasons. I think other people will cover them. But yeah, there are bad sides to it. And they're pretty much well known, like long-running web sockets. I think they can be handled. I haven't seen great examples. Anyway, long-running stuff is difficult to do in a Serverless environment. We have the warm-up times, which is an issue. But getting back to the integration stuff, who uses like SQL, or who uses like flat file storage? I think most of you use SQL. Come on, you've heard of it. But the thing is, when you use SQL with a Serverless function, just starting a conversation with the SQL Server takes like half a second in my experience. So using SQL with Serverless is kind of painful. So you kind of push towards DynamoDB, which, as far as I know, is a proprietary data storage thing. If you integrate with DynamoDB, I dare say you will face very high switching costs. And then there's the fact that you might integrate with AWS-only events. That's something to be concerned about. And last but not least, the one bad thing about Serverless is that you have to fire all the system administrators and all those assholes. I mean, they're great people. I love those guys. I'm a system administrator, really. Switching costs. This one's really hard to do because the devils and the details, I set myself a little project recently where I tried to get one of my services running on Azure. Dude, it's not easy. Like, okay, AWS had the head start figuring out S3 and everything, but the S3 API, I think, is pretty well documented. You would think by now Azure would have, I don't know, an ability to change the permission of different objects. Oh no, it doesn't. They caught me by surprise. There's lots of, similarly with Google, the API isn't one-to-one. So it's kind of a gnarly experience to switch just S3. And S3 is an easier thing to switch than, say, the other thing. So that's what I wanted to focus on. Well, I wanted to focus on that and some other elements to a typical Serverless running thing. The way, I wanted to focus on, like, okay, you have frameworks. You have a framework. No one bundles up there lambda by zip file and uploads that. Does anyone do that? You guys are hardcore. Everyone generally uses a framework because usually there's some crazy cloud formation bullshit to go along with your lambda function. So you need a framework. And you need some storage. S3 I'm focusing on because I like S3 a lot and people should be using S3 because it's way better than most other things. And then there's that other chestnut messaging. And most people, I would say, I mean, I'm just making assumptions here. Most people would, there's lots of stuff in the messaging landscape, but SNS is a typical one that most people might use, at least AWS, to communicate between and to coordinate stuff, okay, whatever. So frameworks. So there's a few to choose from. There's Serverless. There's I think this one's called Sam. I don't know. What does it stand for? Something moral, whatever. There's apex is my favorite. But the idea of frameworks, in my opinion, they should make it easy to deploy a more than one platform. And guess which one doesn't do that. So I would argue that don't use Sam, guys. Use something which gives you an ability to move to another, to target another, what do you call it, cloud provider or something like that. And also, who's a fan of YAML here? I hate you guys. Jason is the future. I hate YAML. To be honest, Serverless and Sam both do it. But can I just give a plucky recommendation to apex? To be honest, it doesn't target, it doesn't properly target other cloud providers, to be honest, yet. But the promise is there. They use Jason. I love Jason so much easier than figuring out YAML indentation. And it works rather well. For example, if you're doing API gateway stuff, instead of like making you do this like Lambda startup bullshit, it just gives you an HTTP request response. So for frameworks, consider apex or consider whatever can make it easier for you to switch. Storage. Okay, this one's a tricky one. And the short answer is, because I can't remember what I was going to say here, is you should be using or consider using something like Go Cloud. It's kind of new on the radar for me too. Go is a programming language. I'm sure other programming languages have this stuff. But the Go Cloud thing makes it easy for you just to use the Go Cloud S3 blob. And the cool thing about it, as I was going to try to show you in my demo, is that you can basically change the provider between Azure and Google cloud platform, GCP. And using this sort of cool abstraction, you can move between S3 providers. And I have a demo I could quickly show you. Why doesn't this tab, how much time do I have? Shit. Come on. Okay, what? Well, where's the demo? It's here. I did like a make file. Who uses make files? You guys are geniuses. I love you. But like, okay, here I just show that you... Oh, it's cool. So I'm not really benchmarking here. Don't read too much into the numbers. But here, funny enough, Google was the slowest when I was uploading, but who cares about those guys? The interesting thing is that, as you can see my demo, shit. Where did it go? What was the interesting thing? Well, I managed to upload to those three without too much hassle. Well, it was hassle, to be honest. Just signing up for Azure and Google platform. You think the AWS console is bad? Check out Azure and Google GCP, man. Horrible, horrible bullshit. I just probably used to... Oh, God. Here it was traumatizing. It was traumatizing. And the Google is the worst for the authentication part. Okay, so I really recommend you have a look at Go Cloud or consider using some sort of abstraction because it actually kind of works except when it doesn't, like when you have to do permission stuff. For messaging, messaging is what most people use SNS for. To be honest, SNS is beautifully simple and I like using it. But there's so much going on in the messaging space. But the real-time web is like, oh, my God, pubs up, all that stuff. But let me just get on to webhooks, the old Chestnut webhooks. It's a standard request response model, HTTP. It's the thing that if you were integrating with other services on the web like Stripe, they would use. It's a little bit slow compared to SNS. You do have to do some extra work to log things out and all that stuff. God damn it, it works. And it's standardized. Just make sure that your app can maybe consider taking webhooks and obviously document it in postman. This is how you integrate with other things in the same way. Don't use some crazy proprietary bullshit. Please use the webhooks is my recommendation. So ultimately, just wrapping up here, I don't know about you, but I just want vendor choice. If one day AWS doesn't drop their prices and Azure becomes cheaper and I do some benchmarking and they seem to do, okay, Joe, I want the, I definitely see AWS as a utility company. I want things to be cheap. I want things to be basic. I don't want them to write frickin' frameworks and shit like that. I want them to just provide basic services as cheaply as possible. And I think we need to think about introducing competitions, the mix to keep them lean and mean. So that's what I'm arguing for. And what else did I would say? You stand interfaces. Yeah, think about avoiding this lock-in stuff because if you go lock stock and barrel with, you know, DynamoDB, Aurora, venting everywhere, you'll be stuck. It will be very painful. And if you go all in, it sounds very attractive, but I can't help but think, you know, someone has to think different and otherwise you will be taken advantage of. I mean, who knows? You can't trust anyone forever sort of thing. But I must say AWS is the best right now considering I've tried the other ones. And considering where I am right now, thank you for the 100 plus. And last but not least, I make a lot of videos lately because I'm just at home bored and I have quite working conditions. So I make videos about Lambda. I have a whole playlist. Please subscribe and do comment and things like that. Any questions? I think that's 10 minutes. Sorry, a little bit over. Any questions? Sorry, I just rushed through that. Yeah, please. I'd love to hear about your experiences about using other cloud providers because it's kind of hilariously bad how the other ones are. Is anyone actually doing multi-cloud out of interest? God, you guys, you're heroes. How do you do it? We've got to talk. Okay. Oh, yep. Well, I didn't go into this. I mean, it's a serverless night, isn't it? But yeah, not container night. But yeah, I mean, the whole primaries of Docker, the whole primaries of Docker is that you should be able to get running another shit. Well, if anyone's interested in using my solution, which is just some open source, but I know how to use it. I know how to use it. I know how to use it. I know how to use it. I know how to use it. I know how to use it. Well, if anyone's interested in using my solution, which is just some open source, but I know how to use it, come to me because the Google stuff works for S3. Yeah, well, it's good that companies are doing that. We need competition, I feel, because AWS is killing it. Stop it, guys. Any more questions? Yeah, you can run anything. Anything that effectively compiles down to a binary 64, no, AMD 64 binary, anything, write assembly if you wanted to. But I use Golang because that's the best language right now, guys. Okay, I've sprouted enough nonsense. Thanks, guys.