#17: FinDev and Wardley mapping with Aleksandar Simovic and Slobodan Stojanovic

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.

If you want to learn about Wardley Maps, then you can read the free book on Medium here, or take the online video course here.

To listen to the conversion we had with Joe Emison (mentioned in this conversation) about monorepoes and build vs. buy, check out Episode 2, and Episode 3 respectively.

And lastly, check out Furnace.io for a data-shipping platform (like Segment) that offers usage-based pricing.

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

Transcript

Yan Cui: 00:17  

Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real world practitioners and get their stories from the trenches. Today I'm joined by two other Serverless Heroes, Aleksandar and Slobodan. Hi, welcome to the show, guys.

Slobodan Stojanovic: 00:28  

Thank you. 

Aleksandar Simovic: 00:29

Nice to have you here.

Yan Cui: 00:32  

So I think it's all fair to say that we are all disciples of Simon Wardley and we are all big fans of his mapping and the FinDev. But before we get into that, can you just tell the listeners about yourself and what you've been building with serverless.

Slobodan Stojanovic: 00:46  

I'll start. I'm Slobodan. I was working with serverless for the past few years. And I also wrote a book with Aleksandar about Serverless Applications with Node.js. I'm building an application called Vacation Tracker. It's a leave tracking application that integrates with your chat system, such as Slack and now Microsoft Teams, and it's fully serverless and it's built on AWS. It's amazing how serverless now can help you to outsource many other amazing things that we did manually in the past to AWS and some other service providers. So, you have much more time to focus on some other things, more essential parts of your application, of course, that doesn't mean that your team will move faster immediately. First, there, there is a big learning curve for serverless because you need to learn how to build your application in a serverless way to be able to like use all the benefits of serverless but also, it depends where you focus later, because you can focus on the wrong things and just spend that time in doing something that you shouldn't do and that's where Wardley maps fits in and help us out to find where we should focus and where we should spend our time instead of like managing our servers, and building something that already exists and things like that.

Aleksandar Simovic: 02:06  

Yeah, and Hi, my name is Aleksandar Simovic. I'm also a Serverless Hero like Slobodan and Yan. I'm a senior software engineer at Science Exchange. And also, as Slobodan mentioned, we wrote a book about Serverless Applications with Node.js published by Manning. Yeah. So yeah, I guess like I can maybe speak for all three of us like we've been using serverless from like literally the early days of Lambda, we could say, and yeah Slobodan and I got together, also along with a fourth Serverless Hero. So yeah, it's a bunch of heroes, Gojko. We also were working and we're the core team member, core team behind the Claudia.js, one of the serverless, one of the first serverless deployment tools. And yeah, nowadays, doing a lot of stuff with serverless helping companies, and so forth. And as Slobodan mentioned, we are big, and Yan of course, mentioned we are big disciples of Simon Wardley and his concept of Wardley Maps, and finance, FinDev or finance and development.

Yan Cui: 03:14  

So for the listeners who are new to this idea of, well, who are new to Simon Wardley, can you maybe put in a few words and explain what is a Wardley mapping and why is it so powerful?.

Aleksandar Simovic: 03:26  

Yeah. Maybe I can initially do the, you know, small definition. So basically, a Wardley map you could say like, I can even change the defin... it's like a formal kind of definition, as it's an anchor driven visual representation of the business landscape of basically a context or company or market. It's basically represented in a series or a one big large value chain. Basically a value chain of needs with, you know, each component actually needing a component and so forth and so forth. What it basically is, it actually helps companies, kind of anticipate changes, shifts trends and also analyse which parts of their businesses can they outsource, build, and why should they build on outsource or, and why this way or why or not the other way. So basically it's, it's like a real visual map of various components in your business, even your competitors components, how we're using them, why are you using them, and the implications of that, and it's, it's not really like a real crystal ball, but it can help you anticipate some things that might that might come in the near future. I think all three of us found it, I think that helped us understand some parts of this gut driven businesses and business decisions that were made. And yeah, we were all attracted by it.

Yan Cui: 05:05  

So, and one thing that Simon Wadley has spoken about quite extensively especially to the serverless community is this idea of financial driven development and how FinDev, and how finance can and development can now become. I guess like a cooperative unit, like you have with DevOps and I know Slobodan you've been actually actively applying this Vacation Tracker. Can you give us some examples of how it's applied in practice and how has it helped you guys direct and prioritise work at Vacation Tracker?

Slobodan Stojanovic: 05:38  

So yeah, as you said, Simon is often talking about serverless as an example of like one things where we can apply this FinDev thing. And we also saw some other great articles in the past few years about that. For example, Gojko, theServerless Hero that Aleksandar mentioned that our friend that Aleksandar mentioned previously, wrote an excellent blog post about like how serverless is changing economy of how you build your applications because you do not have any more, your application is no more like. So you don't do not need to plan cost of your infrastructure upfront, you basically pay as you go. You only pay for your application if anyone is using it. And if no one is using your application, your costs are much lower. So we're trying to apply that to Vacation Tracker. so firstly the Wardley maps, we can finally like put that into some visual map and understand what our, what our needs are for our customers. And then we can decide, using Wardley map what should we build and what should we outsource. Of course there are some obvious things like user system and things like that because if you are building like another user system. There is no point of doing that because there are so many of them like that you can simply use, and of course there is like a serverless user system, which is Cognito. You are charged by number of users that you have and you don't need to pay upfront, anything and things like that. But also there are some less visible things such as like, you want to send emails from your application you can use things like Mailchimp. But that's not really outsourced fully because you still need to have developers that will implement some logic, when you will send these emails, which templates will you use and things like that. And you can also use some other tools like that, such as Customer.io, which is a tool that I learned from Joe Emison, where you can simply send some events, which you're already doing from your application to Customer.io through Segment, and then our marketing person can directly use Customer.io to decide which emails we need to send, which templates we need to use and when do we need to use these templates and things like that. And also, it goes much deeper. So for example, now I can even like calculate how how expensive is some bug for us, not all bugs, of course, some bugs are like customer facing bugs that you need to fix immediately as fast as you can, but some other bugs are like things that you have in the background that maybe takes more time to do some background tasks and many other things. So once we we fix some bugs, and we spent like two weeks working that issue and then after that I sit down to calculate how how expensive is that issue for us actually how expensive it was for us, and it turned out that it was like $2.37 per week. So, it was much smarter to leave that issue there and focus on some other things because it would be like $10 a month or something like that and even with like, much larger volume of users and things like that that issue wouldn't be that huge so it makes sense to sit down calculate some things before you do them, and you can apply that FinDev thing in your application by just like getting real information before you like, do some refactoring, do some fixing of the issues or implement something. Now, It's not just like a gut feeling. Now, you have numbers and these numbers can easily be calculated and presented to your other team members and you can you can have like a FinDev influencing your business decisions which it should be like that because the goal of every business is to make money, in some ways, so you want to spend more time on building your features and less time to build, to fix something so do things that you don't need to do. And if you can calculate which feature is better for you, which feature will save you more money or bring you more customers you can focus on that.

Yan Cui: 10:09  

Yeah, that is, that is… What you mentioned there in terms of working out the cause of the bug and how much effort to, well, how much is it worth fixing it or leaving it. I remember talking to some people about this thing where they were trying to, they were organising a massive meeting of I think eight people, eight developers to talk about how they're going to optimise the Lambda function to save themselves about 10 bucks a month. And when you look at the cost for that meeting alone, and eight developers, you know, if you're being conservative and and I guess estimate about $50 per head for that one hour meeting, now you're talking at $400 just for having the meeting before you do any work, and the payback time for the work is, you know, it's going to take them 14 months just to pay back for that one meeting along. So when you talk about premature optimization, now you can put a real, real dollar sign in front of that to see, okay, well, before we even think about optimising, is this thing even worth optimising before we make make those decisions like you said, based on gut feeling. And, and funny that you mentioned Joe Emison as well, we did an episode with him earlier in this podcast which you can go back to realworldserverless.com to check it out. And we did talk a lot about the whole build vs buy decision as well. And I guess, you know, this whole idea of FinDev also comes into that is you know how to, how much value, are you likely to gain from this feature and how much is going to differentiate your business from your competitors and by looking at the value chain where it sits in the Wardley mapping and help you decide which part of your business you should be outsourcing and paying for service as opposed to building and buy, building something yourself. I also wanted to come back to this whole idea of FinDev as well. Another thing that the Simon talks about is potentially you can also use FinDev as the fact that you get pay-as-you-go from AWS as a business competitive advantage because if you look at many of the services available out there now, many of them are really really expensive and you have to pay something like a couple $100 a year or month, just for one licence. I've seen software in the real estate agency world where you had to pay $4,000 a year per licence. If using the fact that you get pay-as-you-go from AWS and you can build a business model, where you only charge your customers based on usage, and you can put a premium on what AWS is charging you for the use of APIs, databases and things like that. You said something that you guys have explored with Vacation Tracker to potentially build a pricing model that really differentiate yourself from your competitors. 

Slobodan Stojanovic: 12:48  

That's a great idea and we thought about that. And that's something that I want to try in the future for sure but first you need to have a large volume of users to be able to apply something like that. And also, at the moment Vacation Tracker is quite cheap. So, 14 up to 50 users who paid, just $25 flat per month, which is really a small amount of money, compared to some other services and things like that but we definitely have support for that kind of pricing in future because our infrastructure is built that way but it's not just to, it's not enough to take just the cost of your AWS infrastructure and everything you also need to account the amount of time that your developers need to spend, and other team that is working on your product but also some other services that are often much more expensive than, than your infrastructure like marketing tools and some other tools, for example I think even Slack is costing us much more than our infrastructure at the moment. And there are some other tools like like Segment and many other tools that we're paying each month and most of them do not charge you per usage. So you need to count these like capital expenses and also some operational expenses and then you can calculate the cost that you need to charge your customers per, let's say, leaf requested through the platform or something like that.

Yan Cui: 14:14  

Yeah, funny you mentioned the Segment there. Segment is kind of expensive. And I'm actually working with a client of mine, well, I've joined, I joined them as an advisor, now called Furnace and we are looking at building a basically a data shipping platform that is similar to Segment but it’s built with serverless and we are also looking, you know, we are actively looking at this pricing model of usage base. And of course, like you said, you have to factor into the fact that you have developer expenses, you have other sort of fixed expenses for things like Slack and other tools, which of course is something that we take into account when we work out what is the premium that we should be charging on those requests that we are charging our customers. And of course, like you said, you need to have some volume of business before that becomes something that is economically feasible for you to actually go and build yourself. Otherwise, you're going to be charging every single one, every single customer just $3 a month. And you're going to go out of business pretty quickly. And Alex we've also talked about this idea of FinDev and the mapping quite extensively in the past. I remember sitting in, in the bar with you. I forgot which conference it was, and we spent quite a few hours just talking about this. And I know you've also been looking, and working with other companies around these ideas. Is there any any stories that you can share from these other companies who are also applying these ideas without naming any names? 

Aleksandar Simovic: 15:41  

Yeah. Um, well actually to come back also to your previous conversation with Slobodan. So all of these decisions were like, how would you price your product, or what, which piece of product are you going to build, which way and are you going to build it or you're going to maybe take some third party solution like in the talk that you had with Joe Emison. I mean, the oldest decision, decisions actually require quite some mapping, I would say. The reason why I say is mapping and what does this mapping mean it means basically you're analysing whether, you know, certain components actually makes sense that you build them yourself or certain components don't make sense that, and you, and you're just going to outsource like, like, I don't know, maybe, 20 or 20 years ago, like, you know, building website like everybody was like you know I'm gonna build my own website whatever but now we have I don't know tools like Webflow where you can very easily like, create the website like like visually or something and are you gonna hire someone and pay, I don't know, a couple of thousands, just for some or a couple of hundreds just for someone to make your website or are you going to do it yourself like maybe an hour or two hours and you have a completed website now and where you pay I don't know 20 bucks per month. But as I said, like every decision that we make is, I mean, must be carefully analysed and this is why these these Wardley maps are super useful, because they help you see when and why should you charge your product on a per, like per, per usage, or as a monthly fee. And the reason why, as you mentioned, like AWS is using this kind of like model which is like pay-per-use is because all of these, all of the components and the services they're providing have become a commodity. So they were. I don't know in the concept of Wardley maps you have these phases where a single product when it's first idea and then nobody else has made it or thought about it, is called the Genesis, then you have the custom build, and then you have the product and then you have the commodity. Basically, something which is like super famous for everyone. Everybody knows how to use it and so forth. And AWS as you can see, as everyone can see like a particular with serverless has very specifically focused on the commodity phase where they are providing services on these pay per usage fee and that's the creative characteristics. And for example, the reason why, for example I am guessing why Slobodan but, you know, and other companies are not not taking part of this model is because the products are and the tools they're building maybe they're maybe not yet a commodity, or they're reaching the commodity phase. And, you know, if you for example charge a pay-per-use, pay-per-use fee, usage fee, basically before that product comes into this commodity phase, the customers that are currently using it, aren’t gonna switch, they're gonna say, Well, I don't know how much this is gonna cost, I like it when it's a fixed fee and I don't know how and I know how much of the money I'm about I pay by, by the end of each month. And I can estimate my costs while with pay-per-use, you're kind of not so sure right. So, I mean, yeah, as I said like, I mean, as you mentioned, like I'm working with various occasionally various companies helping them out with their serverless and mapping knowledge and practices and so forth. And, yeah, one of the cases which I worked for which is which might be interesting, is the people who like we had a we had a plan about us for a service for some accounting basically. And this accounting service was something which is generally used by the by the finance and accounting departments throughout the world. I'm not going to mention the names and so forth. So, the thing was integrating this thing into basically a single data warehouse system, and, you know, the thing they estimated was like you know we could we could do it like in several ways, one of which was getting the licence and as you mentioned, Yan, like these licences are super expensive and I can tell you that the licence, the licence for this simple piece of software was in a range of several, several dozen $1,000 per year, which is ridiculous. And the reason why is because they actually have, they have this super nice integration with with any kind of data warehouse solution you might be using, and this company was using a very specific one. So, basically, you know, in order to do that, they have to pay each year a couple of, a couple of dozen $1000, just because you know they would be able to send daily reports and so forth into this data data warehouse. And another option was build it yourself, and that would probably... The current destination was, I don't know, several months. And, you know, calculate the developer time, calculate everything you would come to a point where maybe the first year would be several dozen $1000, but during the later years you wouldn't pay that much you would only pay for the maintenance and the time the developer spent. And basically, I mean, I was working in the, in the planning team I would say, at the time and I actually said about the third option is, why don't you use serverless, why don't you try using serverless, particularly because some of the solutions that we're using were on AWS. And we actually mapped out a small Wardley map of like the cost and how much would it cost and so forth. And based on the components we were using which was mostly S3, you know, and Lambda and Kinesis and so forth. We came to a cost of $0.09 per gigabyte. And, you know, while we were doing that, we came to a point where, you know, I just basically asked a question like, how big is the data we're loading and they said like well it's daily a couple of megabytes. And I was like, seriously, nobody asked this question before you know before actually decided to go for forty thousand, like, you know, several dozen $1000, nobody asked the question. They were like, you know, we need to do this, you know, this is what we need. Nobody was thinking about, like what's the volume of the data, whatever like, you know, they came to a point like basically the company is now paying as far as they know around $10 per year for the cost. So, I mean, just by doing a simple map and doing analysis of the components and because, you know, this FinDev, this whole, the whole story of this, you know this this set of finance and development practices on serverless and this capital flow management is based on capital flow management and this capital flow basically means that you know in this Wardley map you can calculate how much does a single flow in a single feature set of your company cost, you know, how much value does it bring, and then based on that you can say well you know this is, you know, if we for example move these components to be commodity or to be a product or evolve that even more. It will cost us a lot less and you know our software will be more resilient and so forth. And yeah, so we just did a little map and did a little bit of FinDev which is like analysing the capital flow of the, of our map. We came to a point of $0.09, basically nine cents per gigabyte. And yeah, I mean, imagine, I mean, we even… So the development costs, just to clarify some people asking themselves that that question in their head it was around two or $3,000 because it basically took the team a week to develop the solution as a service which was like amazing. And because the previous estimate was like three months. What we're trying to say I guess is, you know, if you do a little bit of mapping and applying FinDev and, you know, first learning about Wardley maps and FinDev and seeing how you can apply these methodologies on to your system and into your daily, daily work, you can you will you will quickly see results of this kind of approach. There are also cases where companies were able to calculate that for example a single feature would, you know is bringing I don't know $40,000, per year from, you know, base and by tracking on the usage of the of the of the feature but the cost was $100 so there were like, you know, any kind of bug we fix we fix here is going to be, as Slobodan mentioned, super tiny, you know, so actually they just focus on, like, you know, creating a better experience and focusing on other things. And yeah, this is why, you know, doing doing mapping and FinDev that is something we talked about a lot and we would highly recommend. 

Slobodan Stojanovic: 24:10 

I would just add that, if you want to have like decisions based on like FinDev and things like that you need to have enough data to to be able to calculate all these things. Serverless is of course one piece of everything, of that puzzle, but you also need to know some business parts of the application you're working on, and that's relatively easy when you're working in a startup, but you're when you're working on some enterprise application it's a bit harder to, to understand all the parts of the problem and things like that, and the, the hardest problem all the time is like understanding what the problem is. Exactly as what Aleksandar said, it's like, it's really important to understand like what problem are we solving, how big is the problem, how much megabytes will we have per week and things like that and most of the people don't ask that they just do the tasks that they have in JIRA or anywhere and that's it.

Yan Cui: 25:09  

Yeah, certainly, I feel that having sort of having read about and understood about mapping it certainly has transformed the way I think about not just what I do, but in terms, in terms of why I do it, and certainly when I apply that to companies I used to work for it give you a very different perspective as to priorities. Do they line up with the business objectives? And do they line up with the return on investment because like you said everything we do has got some kind of dollar price attached to it, be it our time. And I think as engineers we are really bad at thinking about ourselves as a cost because again, our time is ultimately money, and it's something that you know time that we could have spent building something else. And, and definitely I find that applying mapping and understanding, there's a chain reaction of the different components and how value, where value can be added, and where my skills as a best applied to create the most amount of value for the customer for the customer and for the business has been a really transformative experience for me personally, at least. And Aleksandar, and Aleksandar, the thing you mentioned about variable fee vs a fixed fee is something that we also spoke at length at Furnace as well, because something that we also notice at least for my personal experience is that enterprises, they don't care if the fee is big, but they care about the fee being predictable so that they can do their budgeting in April every year and know roughly you know what is the out.. what is the outgo expenditure in terms of services and things like that. Whereas for a lot of smaller companies, startups, they just want the cheapest option available that their cost can grow linearly with their traffic with their success so that hopefully their expenditure will also grow in tandem with the revenue stream as well. So I think, you know, with Furnace certainly we also apply and we also have enterprise level pricing which is a fixed fee, which is based on some, I guess a projected amount of usage you're gonna you're gonna have. So, so yeah, that's some really great points there, and so I guess with Slobodan I also want to talk about something that you have spoken quite a few times in the past in terms of howt... Well, because one other thing that comes up all the time I'm sure you guys get the same questions as me, is people asking about what about vendor lock-in, and I know Slobodan you've talked about in the past, different talks in terms of how can you, 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, you know, has some of those 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: 28:09  

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.

Yan Cui: 29:01  

That's part one of my conversation with Aleksandar and Slobodan. I hope you've enjoyed this conversation about FinDev and Wardley mapping. To access the show notes and the transcript for this episode, please go to realworldserverless.com, and come back next week to check out the second part of our conversation. If you have enjoyed this episode please follow us on Twitter, and to subscribe to never miss an episode. I'll see you next week.