So this is really extreme case, but this presentation will not cover that. Regarding vendor lock-in, I really think that Mark Schwartz, enterprise strategist at AWS is right. He thinks that term lock-in is misleading because we're actually talking about switching costs. As soon as we commit to any platform or a vendor, we'll have switching costs if we later decide to change that vendor or platform. For example, if you build your application in PHP, and then at some point you want to migrate that to Node.js or Go or something else, you'll have a big switching cost because you need to pause for some time, rebuild everything in a different language, and then continue from that point.
So, how do we fight vendor lock-in, or let's ask the better question, how do we keep our switching costs reasonable? Well, we can do a few things. First, we need to do planning and analysis. For example, we need to answer some questions such as how likely will I need to switch to another platform or service? What would be the cost for that switch? If there is no big chance to switch to something else, for example, you picked your database and you don't think you will need to switch in the near future, it's okay to have a slightly higher cost of migration, but for some other things, you need to keep that cost lower. You need to have a good architecture, of course. And finally, you need to have deployment procedures because if you don't have them, it will be really, really hard to migrate anywhere.
That leads us to our topic for today, and that's writing testable serverless applications and preventing vendor lock-in using hexagonal architecture. But before we continue, let me introduce myself. I'm Slobodan Stanovich, I'm CTO and partner at Cloud Horizon and VacationTracker, VacationTracker is a lead tracking management system and Cloud Horizon is basically an agency we are doing web apps for other people. I also wrote the book, Serverless Applications with Node.js with my friend Alexander Simovich, and it's published by many publications. And I'm also AWS serverless hero. You can follow me on my website. I write about serverless a lot and testing also. So let's go back to our topic because that's definitely more interesting than I am. So we'll talk about writing testable serverless apps using hexagonal architecture. But let's focus on testable part first. Why is testing important for serverless apps? You basically outsource some parts of your app to a vendor, but that's not covering everything. They'll manage infrastructure for you, but you still own your code and your business logic. So you need to test that part of the application. And also most of the time serverless applications are not fully isolated monoliths without integrations. Instead, there contain a lot of small services that are interacting with each other all the time, and they have a lot of external dependencies. I mentioned vacation tracker, so here's an example. Our application is WebApp that has also Slack chatbot. And inside Slack, you can type slash vacation and request vacation in just a few clicks. It's so easy, you can do that in just a few minutes, actually a few seconds. But in the background, that looks something like this.
Comments