Real World Serverless with theburningmonk

#18: Hexagonal architecture and voice with Aleksandar Simovic and Slobodan Stojanovic

July 01, 2020 Yan Cui Season 1 Episode 18
Real World Serverless with theburningmonk
#18: Hexagonal architecture and voice with Aleksandar Simovic and Slobodan Stojanovic
Chapters
Real World Serverless with theburningmonk
#18: Hexagonal architecture and voice with Aleksandar Simovic and Slobodan Stojanovic
Jul 01, 2020 Season 1 Episode 18
Yan Cui

SPECIAL OFFER: get 40% off all Manning books/videos with the code "podrealserv20" at manning.com

You can find Aleks as @simalexan on Twitter, and Slobodan as @slobodan_.

They are running back-to-back courses this month, on "Testing Serverless Applications" and "Serverless for Frontend Developers". Check them out and enrol on Homeschool.dev.

Also, check out their book "Serverless Applications with Node.js" by Manning, and Claudia.js, one of the first deployment frameworks for serverless applications.

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Show Notes Transcript

SPECIAL OFFER: get 40% off all Manning books/videos with the code "podrealserv20" at manning.com

You can find Aleks as @simalexan on Twitter, and Slobodan as @slobodan_.

They are running back-to-back courses this month, on "Testing Serverless Applications" and "Serverless for Frontend Developers". Check them out and enrol on Homeschool.dev.

Also, check out their book "Serverless Applications with Node.js" by Manning, and Claudia.js, one of the first deployment frameworks for serverless applications.

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Yan Cui: 00:00  

Hi, this is part two of my conversation with Aleksandar and Slobodan. To check out part one of our conversation where we discussed about FinDev and Wardley mapping at length, please go to realworldserverless.com. I hope you enjoy this episode where we're going to talk at length about hexagonal architectures and how to use it to mitigate vendor lock-in and lower your switching costs as well as why voice is the future of computer human interfaces.


Yan Cui: 00:39  

And I know, Slobodan, you've talked about how you can use hexagonal architectures to help mitigate some of the concerns around the vendor lock-in. Do you have some examples that you can share with us in terms of how that looks in practice? And if has some additional efforts, have they paid them off in terms of you having a decision to make to switch to a different service, and that helps you minimise the amount of work you have to do at that moment in time?


Slobodan Stojanovic: 01:07  

Yeah, sure. So, about vendor lock-in. What's vendor lock-in? Of course, everyone talks about like cloud vendor lock-in, and I still need to hear one really good story about why someone migrated from for example AWS to Google or Google to Microsoft or whatever. Most of the time, it was like mistakes of like us as people, not really because platforms raise their prices and things like that. And Mark Schwartz from AWS explains that really well. He says that, that's not really cloud, that's not really a vendor lock-in, that's a switching cost. And you have switching costs, whenever you have some decision. For example, we decided to use Node.js for Vacation Tracker, but if at some point we decide that Node.js is not really a programming language that is solving our problem and that we need to switch to let's say Go or something else. I don't know why but let's say that's our… that's what we realise at some point, we will have a switching cost, we'll need to rewrite our application and it will be expensive to migrate to some other programming language. It's the same with like cloud infrastructure and things like that. So when we try to analyse our potential project that moment - Vacation Tracker, we put everything on the map and we use some, like we did some analyses and things like that and then we decided it's okay to like go with AWS because, well, our infrastructure cost will be really low, and it's low, first like eight months were like $0 and now it's still like around $100 per month or something like that. And we also have some credits so it’s basically zero right now. And also, it can grow with more usage and things like that, but it also allows us to build something faster and things like that so it's a good trade-off. And we know that we need to migrate things from one service to another, not not really from AWS to Azure or something like that. But we already did many modifications of our application. When we built like MVP of our application, we we had some like ideas and now we saw that some of these ideas are not good and we try to use different like tools for different things. And, for example, at the beginning we had some MongoDB database, and at some point we migrated most of these things to DynamoDB but because it's scaling better, it's faster, and we have less problems maintaining it and things like that. And hexagonal architecture is something that helped us, helped us a lot to do these things. And for hexagonal architecture, that's something that we first have learned from Gojko, and both Alexander and I are using hexagonal architecture basically everywhere now. And the idea is really simple. Hexagonal architecture was like defined by Alistair Cockburn. And he says that the application itself should be developed in isolation from its eventual databases, runtimes and things like that so you can easily like run your application from a production environment but also from, let's say, automated tests or your local environment and things like that. And if you apply that to serverless, it makes sense. Because it's really hard to test your serverless application locally, because you need to like simulate many things like DynamoDB which is relatively easy, but if you want to simulate Cognito and many other things it's not that trivial, and you'll have some issues that are not real issues. You need to spend more time solving your like local issues like local mock issues or whatever. With hexagonal architecture, you basically remove the business logic of your application from its connections to real world. So you have some kind of adapters and our application is saving some lead requester database. And then we have different adapters. One adapter is for MongoDB. The other adapter is for DynamoDB. And they receive the same data, like the same interface because we are using TypeScript. And then they have different logic how to write that to the right table of DynamoDB or right part of MongoDB or when we run everything locally then we decide to do that in mem— to write the data in some in-memory DB just to be able to test the integration and things like that. So, yeah, hexagonal architecture, ports and adapters help us a lot to like develop our application in a way that we can easily, not that easily, but depending on migration, we can relatively easily move to some other like adapters and things like that. It's trivial to change the adapter. It's not that trivial to write a new adapter and make sure that you don't break your business, your other parts of logic, not the business logic of that function. That that part is, is isolated from everything else but maybe you're saving some data to MongoDB and reading other data from DynamoDB. And you somehow need to make sure that you are moving all the data at the same time to to another data source and things like that. But that architecture helps us a lot to like simplify our code and be able to like migrate and use new services, and things like that.


Yan Cui: 06:48  

Yeah, I do think hexagonal architecture is a very powerful way to structure your code and certainly make it far more portable and flexible as you may switch switching decisions. I guess one of the things that I have found in terms of just, just the pain point of using hexagonal architectures is that it does take a bit more effort to write the first time. And you have to be quite conscious of the abstraction layer that you put in there so that it’s flexible enough to make you change decisions to go from say Mongo to DynamoDB without being too restrictive that you can only use the least common denominator in terms of features into the different services that you want to use because my struggle with hexagonal architecture is understanding when to actually use it, because I can't really predict when I'm going to incur those switching costs, and most of the time I should just default to talking to DynamoDB directly without going through some other abstraction layer. And because 99% of the time, or 90% of the time, I'm not going to switch my database.


Slobodan Stojanovic: 07:49  

So basically I don't know that. I, if I'm building a product that is MVP, I think that there's a possibility that we'll need to change everything. For example we tried to use Pinpoint at the beginning for analytics, then we decided that that's not the optimal service for that. And then we switch to like segments and some other tools and now we're using many integrations through segments so we're not trying to decide that upfront, if we don't know that. And we kind of found the easy way to, like, write our code using hexagonal architecture, maybe it's not the right way I don't know, but it's the way that works for us, but basically how does it work. We have like different, let's say repositories, or maybe these are just node modules that talk to DynamoDB and MongoDB and some other things like maybe events like segments and things like that. And then what we do. When I have some Lambda function I have a lambda.js file or now lambda.ts file that basically imports these, like, let's call them adapters for DynamoDB and segment, let's say, for that function. And then I just basically pass these libraries to our main function that does real business logic and that main function doesn't have any connection to the real world except these parameters that it is receiving. And then you can easily like change these things. You just need to change like lambda.ts file nothing else, your business logic inside stays the same because you have like database dot say li, or whatever, with some parameters and things like that. Then of course you need to have like a lot of tests to make sure that your adapters are really working with different databases and things like that. And we're not really using the... As you as you said, you need to decide how deep do you want to go into everything. We're using a lot of things from DynamoDB and our migration from Dynamo, from MongoDB to DynamoDB wasn't that trivial. When we wrote our like that layer that is storing data to the database and things like that because we tried to do some more like a single table layout and things like that but you can still spend a bit more time on writing your new adapter and your business logic will stay the same. When user want to request a new lead, it doesn't really matter how do you store that lead in the database. The logic is the same. You need to check some things, you need to see if that user have an update and things like that, then you need to start that to the database. That part of the logic is fully isolated and tested in isolation of real database and other parts of the system that we're using.


Yan Cui: 10:37  

Yeah, yeah, that I understand. I guess my struggle is more that sometimes it's just easier to pay for that switching costs when you do make the decision to switch from one thing to another then to try to make it easier later by investing upfront, doing all this work to build the adapters and all of that.


Slobodan Stojanovic: 10:54  

Sorry, if that takes too much time and cost you too much to like build an application with hexagonal architecture, you definitely shouldn't use it. For us, it doesn't take more time because somehow we have our own system how to write these functions in that way that is not taking more time for us. So, going back to FinDev, you can easily decide when you use Wardley map and FinDev, what should you do. And you can decide what's the best risk for you. Is it the, is it better if you have like potential higher switching costs that never switch in most of the cases, or you have like a lower switching cost and then more development time that you're invested in things like that. For us, it's it's it's not costing us much more to like build everything using hexagonal architecture so for us it's like no brainer to choose that.


Aleksandar Simovic: 11:48  

I mean, I'd like to add that, you know, I mean it's it's a very simple question, what what I mean, there's a there's a this question actually was given to us by our friend Dan. Dan, he works at Amazon. And he told us, like, what the best question to ask yourself is what is, what is the thing you're trying, what is the problem you're trying to solve. So is your focus on trying to solve your infrastructure, or your focus to provide better services and better features for your customers. Like, you just need to ask yourself that question if your question is I want to provide more features for my customers and more value then obviously you you know where to where to focus. But if you're like saying well you know i know i have a product but I'm gonna focus still on my infrastructure. Well, that's gonna be a problem for customers and later for your business.


Yan Cui: 12:37  

Yeah, I get that. But I guess the, the question for me is still just the... Of course I'm always going to focus on building features for customers but that doesn't tell me, that doesn't inform me when I need to apply adapters to how I write my Lambda functions. I guess I don't really have a crystal ball that tells me...


Slobodan Stojanovic: 12:53  

It's really hard to decide that it's...


Yan Cui: 12:55  

It's really, it's really hard to decide that, isn't it. So for me I think I probably... in the past I've used adapters in cases where I am not certain which is the best service I'm going to use. But I think nowadays, most of the time I kind of know what tools I'm going to reach out for. And by the time I make those decisions, I should have understood the requirements to know, to know whether or not say DynamoDB is a good fit for these particular requirements that we have. And then I probably, most likely, I'm probably just going to go straight to DynamoDB rather than going through some abstraction layer they are built through, you know, with adapters and whatnot.


Slobodan Stojanovic: 13:37  

So for me, the question is not if we'll need to switch to something else. The question is when. So even for DynamoDB and things like that, for DynamoDB works perfectly fine for me right now, but who knows maybe in next few years, AWS will release something else that will allow me to delete a lot of our code and just outsource some parts, more parts of our logic to to AWS directly, or maybe someone else. It doesn't really matter. So the question is, when do you want to switch to something else and how big will that, how big impact that will be to your business. That doesn't mean that you want to go multi-cloud or anything like that, because that doesn't make any sense. If you put it on a map or something like that. But if you're building the application that you want to stay on the market for like next 10 years or something like that. Some point you'll need to switch to something else, if you built everything using VMs and things like that like 10 years ago. Now you want to switch to serverless somehow and you want to remove parts of your logic. At that point you have like perfectly fine technology, probably the best technology that you had at that moment that much better than your competitors and everyone else. But market is changing and that's where Wardley map can help you to see how market is changing, to see some potential changes and things like that. And of course it's not the crystal ball. It will not tell you all the answers but it will point you to, to look in the right direction. And then you can like calculate all the risks and look in the right part of the map that you want to focus on.


Yan Cui: 15:09  

Yeah, but for me I’ll have a method, I’ll have a method in my, in my module, in my functions code that says get something from, well I don’t know, get a profile get whatever. That's the only function, that is the only method, God this whole name function is messing you up. That, that's the only method that's actually talking to DynamoDB directly without having to have explicit abstraction layer to represent adapters. When is that not enough versus having to have some more formalised ports and adapters in place ahead of time. So I don't think that's a question that we can probably find definitive answers right now. In the interest of time, I want to maybe switch gears a little bit again to to Alex, because you've done a lot of work with voice and Alexa. So, how do you, how did your interest in voice come about and what do you think is the future of user experiences or UX?


Aleksandar Simovic: 16:05  

Yeah. Well, thanks, thanks for the question. I mean, this is one of my main topics currently in my life. Well yeah, my interests in voice came a long time ago. I mean, obviously I guess we all we all as kids, you know, we watched a lot of Star Trek and a lot of other TV shows that kind of like, you know, showed us the potential of a future and so forth. But, in general, yeah i know i mean if you're if you're an impatient person sometimes as I am. Sometimes you want to see some things which you know you want to create somethings which are up in your, I mean in your imagination you're thinking about it. Some time ago, I was thinking about like, you know, if I mean, I guess everybody would thought about like, you know, what if you could build your, your applications or anything with voice and, I mean, of course, some people I mean many, like, just give out because it's like you know how are you going to build applications with voice and so forth but as serverless came along. I came to like, to an like, basically to a conclusion and I was further pushed into it by the usage of Wardley maps, and also by Simon's prediction on on on like saying that conversational programming is going to be the future. But basically, yeah. A few years ago I was, you know, when just Alexa get started, I was basically just helping around my house with a with a voice and start exploring a bit and also you know my, my father he tried to… when he saw like Alexa he was like what if I could open the gates of my of my yard with my voice, you know. And so all of these things kind of pushed me forward. And, yeah, like, maybe two years ago, I came to a concept of something called, called Jarvis because I like, I still like these Iron Man movies and so forth. And I basically started building... I mean I first first built the prototype, what if you could, like, you know, build a Lambda function or something, or build a little CloudFormation stack using voice. And after literally a month. This evolved to a point where I could build multiple stacks and multiple applications. And, yeah, all of a sudden I got this whole idea of like you know actually you can now build, you know, just with with serverless you're now able to build now applications with voice because you can easily abstract away, you know, do the application, I mean that actually the application logic and the application and their infrastructure finally got their own, how can I say, a concept are regarding the business like business logic transformations. You had business storage with S3, business storage with DynamoDB, also Aurora, you know you had other types of transformations and streams with Kinesis so like, you know, every single concept we have in the, in the software engineering are now, like basically formalised services. And through that concept I was like yeah but yeah basically before you weren't able to do that because infrastructure wasn't ready. I mean, you could build applications with voice but how would you deploy them, how would you scale them, you know, all of these things were a problem but as things now evolved, now we've come to a point where you know actually voice has become a part of our daily life. I mean, if you, if we all recall Alexa has been here now for like, you know, four years already in our in our life now, and all these things, led me to a point that you know the future is definitely going to be voice. You know just, but I want to clarify, it doesn't mean voice first. What what voice first means voice first means that you know it's like Alexa you don't see the UI but you just talk into it. But even Alexa has realised that, so even now as an Alexa team I guess has realised that because now you know you have a small Alexa shows available for everyone like you know every Alexa now has almost, almost every Alexa, except the small dot ones have a screen, you know, which means that they have also realised that human interaction with them with each other. We do... I mean, our human interaction among each other and we live with machines is basically based on not not just on audio but also visual is also visual. So, my belief, that's something which I'm building this this tool called thecomputer.ai. And there's another one as well regarding to healthcare, but anyway that's a different story. It's like, you know, in the future, people will be able to build applications and software and a lot of other things using their voice and their touch and their and their eyes. I mean, you're not gonna build using your eyes but you're gonna evaluate. So, yeah, yeah so yeah even two years ago on the re:Invent AWS re:Invent 2018. I've forgotten I have actually given a workshop on how to build your first like this kind of, like, you know, building voice using, building a software using voice called Jarvis. You know, you know, Alexa to Create an App, that's how the workshop was called. And, yeah, it's, yeah since, since that moment I've been actually very involved in this area. Yeah, I mean, the current evolution technology is such that, you know, we are actually more and more used to this voice. For example this Christmas, I've seen my nephew using his phone as basically for, like, you know, searching. I was like, I mean I just saw him talking to his phone and was like, I mean, has the seven year old kid going crazy or what. And, but no, actually he was searching for Minecraft. And he was like, just googling like, hey man, hey Alexa, hey Alexa, hey Google, yeah, can you show me Minecraft or something like that? And I was like the guy doesn't, the kid doesn't know how to write, you know, and he's able to use his phone already. I mean, not to write Latin letters. I mean, because he is seven years old, you know, to write Cyrillic in Serbia we have two types of letters. Anyway, so I was like so amazed. And yeah all these things as we see them then, for example, even reports by AWS, by Amazon that actually, there's been, there's been like a 300% or 400% increase in shopping view using Alexa and so forth. And we have a bunch of other Alexa devices, I don’t know, for your fashion look. You know you can take photos, there's an Alexa for that, for... There are even like, you know, tools available like software tools in the market that are like, I don’t know, helping lab assistants do or do the research, taking notes and so forth called LabTwin. There is, I mean, I don't want to like go into detail but it was just like there's like literally a bunch of tools are available that enable like regular people do amazing stuff, using voice. And so yeah, yeah, that's basically the whole story behind it. So yeah, I do believe that voice, and, like, voice equal with a voice and voice and visual is going to be the future.


Yan Cui: 23:22  

Yeah, even the Star Trek characters, they still have tools that require them to click buttons and to look at a screen like those, like those devices are used to scan you, well, scan you to see if you got any bugs or any diseases and stuff.


Aleksandar Simovic: 23:36  

Yeah, exactly. So, I mean, but but just like for more complex things I don't know if you recall, for example, they have this, they have the computer and they have also the doctor so these are actually the two fields, the two named tools which I'm building in some way. I mean I'm not building a doctor but they're just like, you know, using the, using the, using the term for, for the, for that, which is like, how can we using like voice help people do their job better. And in the Star Trek for example this doctor is basically kind of an artificial assistant doctor which is able to, you know, help the, help the crew by analysing their symptoms, analysing their conditions and so forth, you know. I mean, it doesn't make any decisions, actually humans do. But it actually just informed them of of the potential of what's going on and so forth without actually having the people to do the manual labour or, and you know, actually, you know, trying... I mean you can't remember like, not a single doctor can remember every single disease that exists on this world. And particularly the combinations of symptoms can be... I mean, the current moment we have this coronavirus crisis and that's going around the world. I mean, the doctors are still, are still discovering like throughout the whole world which kind of symptom is suitable for what. And I mean is this symptom really occurring, where, what. I mean, you know, and we as humans are flawed, you know, and I mean even I mean even computers are flawed because they're built by humans but anyway. But still, what I want to say is, you know, we can use computer computers to assist us. And they can help us actually provide more and better services and better, you know, even healthcare for, for the people around the world.


Yan Cui: 25:23  

So yeah, that's great, that's definitely a future to look forward to. But right now, because so taking us back to the present. With AWS, you guys, you know, we've all been working with AWS for quite some time now. What would be your top three AWS wishlist items that you would like Amazon to work on and fix.


Slobodan Stojanovic: 25:42  

I guess I can start. I'm using HTTP APIs now a bit more than, than traditional REST APIs from API gateway. So I would love to see tracing available for HTTP APIs. Also I really like how long the destinations work but I would love to see the destinations working for all integrations, not just for async invocations. And also, I don't think I have a lot of other things that they want AWS to implement, or to improve and things like that. I basically need a better documentation now and better examples and things like that, because I think the hardest thing with serverless right now is how to start with serverless, how to see some more real world examples, and how to find all these excellent tools that they already have, because most of the people know about Lambda and API gateway and that’s it, may be SQS and SNS. But there are a lot of different services that can help you to solve your problem that you have right now but it's really hard to find these tools and then understand how to use them and if you try to do something slightly more advanced or things like that it's really hard to like figure out how to do that, if you don't have a lot of experience with AWS. And that's something that I would love to see like more real world examples that people can follow and probably be better documentation. I have no idea how better documentation looks but definitely not like documentation they have right now.


Yan Cui: 27:20  

Yeah, for the real world examples, I think they are, they are starting to work on that. Obviously Heitor did his airline example and I think, Alexander from, from the Nordic team has also recently published another, I guess more real world like example that's that's quite comprehensive and not just a very very small project limited the project that doesn't really give you a sense of what a fully fledged service application looks like and all the problems that you can run into. So hopefully they are already moving towards that direction in improving some of the documentation and also giving customers more real world like examples that they can look at and see how to build things themselves. 


Slobodan Stojanovic: 28:02  

Yeah, I agree and we really like what Heitor did with the serverless everyone project. And yeah we hope that they'll have more projects like that. I think that was really really helpful for people to understand how to build a serverless application using AWS.


Aleksandar Simovic: 28:20  

I mean personally for me, I would also like to mention that Heitor’s projects which was like super super useful because, I mean, again, we did kind of cooperate. He invited us on a few shows because you know he actually built the whole solution step by step which involving certain series of guests and so forth but I really appreciate that, that because it actually shows how people cooperate together, how they build the product, how do you how do you use and which services from AWS, should you use to solve certain problems, particularly for example I love how he used AWS step functions to actually track the booking status of files when I know an airline ticket that you might order and so forth like. This is really really really amazing. I mean, at least from my surroundings I heard a lot of a lot of people in AWS customers that which mentioned that you know they really loved the show and they, they even go go to, you know, go and go and find it to reference it and you know they go to the, to the GitHub and so forth. So yeah, that was one of the things which was the highlight. But now to mention something which is like for me like one of the top three AWS wishlist items is, I would actually put Slobodan’s third documentation testing as my first, because this is definitely something which you know I find the most useful. They have amazing services, but on some occasions, you can't find things that you want to use, which is again a lot better than everything else on the market but still you know, actually it saves me, and I guess my company's time and everybody's time, a lot more if we are able to like quickly find the necessary properties cases when and why are you using a certain case solution, why would you, for example, use, I don’t know, S3 or DynamoDB for some cases because sometimes S3 as Gojko wrote an article about it. He's like you know sometimes S3 is a better thing than to use for some storage than, than DynamoDB. Or for example, when you should, when you should use Athena, and S3, and instead of actually using, you know, Lambda with DynamoDB or something like that or, or GraphQL. I mean, these cases are super useful for any kind of customer, and for him for him to build anything else, anything actually business driven. But uh, what I want to also add is, in my opinion, I would also like more actually a lot more precise tool kits regarding Alexa, because Alexa has seen a lot of changes of their SDK, not SDK, like tools, how do you build it. You know like, now I think, several of them, the Alexa SDK kit has changed quite a bit. I mean, these kind of things are a bit you know tricky I guess they're like work-in-progress, but still, you know, there are people who are actually building some Alexa Apps for production and for even for some businesses. And, yeah, the thing is they're not seeing... I mean, it's a bit hard decision process which you should use and why . And these things are problematic. And then the third thing is, I mean I would like to actually see more and more examples and cases for Amplify. So I'm a big fan of AWS Amplify and a big fan of... I mean I seen Nader Dabit’s work regarding anything he was using Amplify and using a managed like solutions to actually, to build even example projects for free, like JAMstack commerce or JAMstack, you know like, I mean he has like a bunch of things. Things like that are super useful and I would like to see them even more. In the for the basically from them, Amplify team. So, yeah, these are my top three wishlist items.


Yan Cui: 32:16  

Yeah, yeah, I have to say that Nader is doing some amazing work on the developer experience side of things for AWS, I do, I do very much like the stuff that they are doing with Amplify. I think that that's probably one area that Microsoft is probably lacking a little bit as well that they don't really have something equivalent to Amplify or Firebase. I guess they probably have different customers telling them that they have more enterprise needs than AWS. But still thank you guys very much for sharing your, your top AWS wishlist items. But before we go, are there anything else that you guys would like to share with the listeners, maybe personal projects you want to promote or potentially job openings at your companies?


Slobodan Stojanovic: 32:58  

So nothing really special from my side. There is of course a book that both Alex and I wrote together. It's called Serverless Applications with Node.js. I guess we can provide some promo code or something like that, feel free to reach out to us via Twitter or something like that. And, yeah, that's it. We are writing from time to time with Gojko on serverless.pub website so there are some, I guess, I hope, useful articles there and that's it from my side.


Yan Cui: 33:29  

And what about you, Alex?


Aleksandar Simovic: 33:30  

Yeah, and on my end, yeah, just as Slobodan mentioned, is again the book, also the serverless.pub website. And I also would like to mention if, I don't know, if you're, if you're, if you're keen to Wardley maps and would like to, if you'd if you'd like to know, I don’t know, because, you know, with Wardley maps you can also do gameplay mode which means what you can do an what and when. I recommend there's, I mean I open, I open sourced a workshop called BattleCamp, which is basically, it's free open source kind of workshop where, you know, several people, can several groups of people can actually compete, kind of, I mean not to really compete but kind of solve the problem differently or compare or even occasionally compete against each other if necessary, and practice gameplay mode so it's called BattleCamp, and you can find it on GitHub or battlecamp.io. I need to update the website though. And that's it. Thank you for having us, Yan.


Slobodan Stojanovic: 34:25  

Thank you for having us.


Yan Cui: 34:27  

No worries and I'll make sure that those links are available in the show notes so that people can find you on Twitter and to find your book serverless.pub and battlecamp.io. And again, thank you guys very much for joining us and sharing with us your serverless stories. 


Slobodan Stojanovic: 34:44

Thanks.


Aleksandar Simovic: 34:45  

Thank you for having us.


Yan Cui: 34:46  

Take it easy, stay safe. Bye, bye. 


Yan Cui: 34:59 

That's it for another episode of Real World Serverless. To access the show notes and the transcript for this episode, please go to realworldserverless.com. If you have enjoyed this episode please follow us on Twitter and subscribe so you never miss another episode. I'll see you guys next time.