Hi, welcome to building a serverless fintech startup bonnet. First of all, let me just introduce you to me. I'm Daniel Bass. I'm the CTO of Zeti. I was in a previous life the lead engineer for private assets and alternatives team, a major investment manager. So my background is in financial technology. I'm an author and a blogger, so I've written two books, one on beginning serverless architectures, Microsoft Azure, and then the second more recent one on advanced serverless architectures, Microsoft Azure, which don't let the advanced intimidate you. It's a very accessible book and definitely the one I'd recommend. I also maintain a serverless blog where I write about all of the things that I'm talking about today and more. So feel free to go and check that out at Daniel Bass. I thought I should also introduce you to actually what Zeti is. So Zeti is a paypermile digital financing platform to accelerating the adoption of zero emission vehicles. Now what does that mean? Well, the world desperately needs to move to zero emission vehicles to solves the climate crisis. It is a simple fact that if we're going to do that, we need to have zero emission vehicles powered by renewable energy. We're tackling mostly the renewable, the zero emission vehicles part of that. And these current zero emission vehicles on the market, I. E battery electric, is the majority one currently. They do actually present quite a few challenges for people to switch to. They're more expensive, as I think people are fairly familiar with, but they also have quite different patterns in terms of their usage. So the range is lower, but they also don't require any maintenance or very, very little maintenance. And that actually makes it very difficult for companies that have built their business models around the existing way that petrol and diesel vehicles work. So what we're doing is we're making it easier and more efficient for asset operators to shift to zero emission vehicles. And then weve also making sure that the investors who are funding that switch get a reasonable return on their investment. The real key innovation there is the pay per mile aspect. So rather than a fixed monthly payment, instead if youll drive 0 mile one month you would pay zero pounds on that month. And if you drive 1000 miles you would pay, let's say 30 pence per mile and you'd pay 30 pounds. This is really, really good for vehicles operators who generally think in terms of revenue per mile. So taxi drivers, delivery vehicle companies and that sort of thing. So what is serverless? That is an eternal question. It's not a fantastic name as it's kind of constantly debated and slightly confused about what it is, but the one thing I would say is that it is more than just function as a service. So a lot of people will have heard of AWS Lambda as your functions or Google cloud functions. Serverless is much more than just that. It really should include all services that I think of as being utility like. So you pay for what you use, it's instantly available on tap, it will scale to virtually any amount, you don't need to manage it. When you switch on a light bulb, you don't have to think about what frequency the electricity is being profile at. Everything just works. There's a bunch of services like that. It services like that. So cdns for example, you just upload videos to a CDN and it just works. You don't have to think about all of the details of how do they split that across all of the edge servers around the world and all that sort of thing. It is just fire and forget. Similar things with pay per use databases. So things like Google Spanner, you know, you just pay per database transaction and it works out everything for you, just put your data in there, it works out indexing and all that sort of stuff and it just works. So I'd say more broadly, a serverless mindset can be used to minimize waste and undifferentiated heavy lifting. So if your company's business is managing kubernetes clusters, then it's probably a fantastic thing to become very good at managing kubernetes clusters. But there's only a few of those companies, and there are a lot more companies that do that whilst their actual value is selling insurance or doing whatever. Being a cafe, like all sorts of different things. If you're doing that, it's not the actual value. And there is an established way of an automatable way of doing that. I youll classify that as undifferentiated heavy lifting. You're doing a lot of work that doesn't actually directly translate CTO value for your customers. Whereas a service mindset says right, let's try and make everything that isn't in that direct value chain of getting value to the customer, let's get rid of that and try and make it automated, use services to do it. And these focus only on the things that we do and we do well and that our customers will value. So why is serverless supposed to be a good fit for startups now? I've used it extensively in an enterprise world and it has very, very good benefits these, but now I'm in this startup world, it's been quite good to see that in theory the benefits are significant here too. Pay for what you use is really good for a startup where you've got very few customers, but when you've got very, very few customers, you also generally have very little funding and very little revenue. So that means that your bills are small when your revenue is small, and your bills only get big when hopefully your revenue is big, or at least your funding's big. That mapping is really nice for your sort of cash flow management. And if you're sort of seeing similarities between Zetti's model for turning finance into a bit of a utility and service's model of turning compared and it services into a bit of a utility, then that's no accident. The other benefits of serverless, you have a much faster development cycle, so you should be able to ship product a lot quicker. Scaling serverless system so generally should be considered to be a zero manual intervention. It should just scale. That's supposed to be very useful. If youll startup is suddenly on the how can you use homepage and everyone visits your website and it's always embarrassing if that happens. And then you can't capitalize on that traffic because your server is serving 500 and it's not great for your public image. So then other benefits are things like there's no patching and the only security that you have to worry about is the security of the code you yourself are uploading. So that's a really subtle point. But say if you decided to host your startup's code on a server plugged in in the corner behind me, if you think about all of the different security aspects, you need to think about there's a vast amount that are nothing to do with code. You've got to make sure that you install a burglar alarm. You've got to make sure that there's a failsafe power in case someone decides to, I don't know, go and cut your mains power or something here. Depending on what you're putting on that server, I don't know why anyone youll try and attack you quite so thoroughly, but in a financial world you do need to think about these sort of things because a lot of money can be made by attackers if they manage to compromise you. And then there's all sorts of other stuff as well. Like if you're running Linux on that server, there's recently a massive exploit that have been in the code base for like ten years. And you're going to make sure that you patch that very, very quickly. Otherwise an attacker can just get on by onto your server by just running a script. Now with serverless there are no servers, they're all managed services. So the only real security you need to worry about is your own code, which is a massive benefit. The other side is something that I don't have strong data for, and I'll admit that up front, but youll would expect that serverless systems would be generally better environmentally, and that's because your utilization of your system always hovers just a bit below 100% because obviously no one can get to 100% compared to a normal system. Say if you ran a server with, I don't know, four cpus and eight gig of Ram, and you need to do that because at the peak time during the day you use four gig of that ram or six gig of that Ram, and maybe when you have a spike you might go up a bit more. That means that the vast majority of the time in the middle of the night or whatever, you're using 0% or 1%. Now with a serverless system you scale down to zero. So when you're using nothing, you actually are using nothing. So the utilization is a lot better. There's a lot less waste. Now, the cloud providers don't actually provide breakdowns of the different energy usages and co2 emissions of each different service. So you can't say for certain, but logically it should be much better because of the lack of waste. Let's go on to the Xero platform. So zero is the beating heart of Zeti. It tracking thousands of vehicles in real time, and in future is going to track hundreds of thousands to hopefully millions. It keeps basically monitors where those vehicles are, which is important for default conditions, and maybe if there's something wrong with the vehicle, et cetera. It receives updates for things like crashes. So we need to know if a vehicle has been written off. And we also need to bill operators for their usage, so we need to check their odometer values. One of the key things it can also do is it informs investors of the performance of their investment in real time. So that's really cool. You've sort of got as an investor, usually if you're investing in vehicle finance or whatever, you've sort of got a finger in the air. Best guess of what the value of your investment is at any given time, because at best you get paid once a month, but you don't know if these person's actually using the vehicle at all in that time. So there was a big default of hurts at the start of the coronavirus pandemic. And that was mostly because there was a lot of finance lent out to them. But when the pandemic startup, no one was renting cars, so people had a massive delay between seeing that and then that sort of debt going defaulting. So being able to see all of your investment performance in real time for this sort of thing is very rare. You just don't see it. And it's a real differentiator for Xero. It's built entirely from serverless components, so there isn't a single Linux jump box or anything in it. All I've got is my Mac mini on the desk in front of me and my sort of managed cloud services. So I'm using Azure functions, Cosmos, TB, Eventgrid and Azure static web apps amongst a few other sort of services. So there is no physical server for me to actually use and no virtual server either. It's all managed services all the way down. So this is sort of an example of how the Xero platform works for a given use case. It's not a particular part of the zero platform, it's more a generalization of several sections. So on the left here you can see our users. So they might be investors, they might be asset operators, we call them. So the people who are operating fleets of vehicles and they're visiting a static web app now that is say a react application or an angular application, we tend to use react and typescript and they visit that and that app then goes off and says, right, I want the account details for this person. So it goes off to an Azure function. The azure function spins up from nothing and goes okay, let's go and get the account details for that person goes off to Cosmos Db where they're stored. Cosmos DB is in fully serverless mode as well. So it goes from nothing and goes oh, wakes up and sends the account details back. We also have the other way around for this, so that sort of pull method where the user has to be logged on for it to happen. But we also have the other end of our system, which is also serverless and flexible and does change vastly in terms of its usage, which is the vehicles driving around. So most vehicles tend to be parked at night, although if you're looking at things like taxi vehicles, that can vary quite heavily, obviously, because the busy hours can sometimes on Saturday nights, for example, can be a very busy time and they might be parked during the day during that period. But generally there's got CTO, be some downtime in a business that's operating vehicles, if anything, just because the drivers need to sleep. So only when the vehicles are driving do we actually collect events from them. We have an azure function that ingests all of those events, takes them all in, basically turns them into our view of the world. So we have lots and lots of different providers. You can imagine like the event coming from a Renault is going to be different from the event coming from a Tesla. And it depends. We've got chips and trackers in each of them and they're different makes and things like that. So it handles all of that stuff and then it pushes it onto Eventgrid. Now EventGrid is a massively scalable event handling solution. You can just publish as many events to it as you like and it will just work. And we use that. And then to get it into the user's browser we use something called signalr, which is a nice way of basically wrapping websockets and all of that sort of stuff. The real power of it is actually managing a websocket connection is hard and some browsers don't support it or support only part of the protocol, et cetera. Signalr just takes that all away from you as a developer. You just publish it to Signalr and then Signalr will work out between the client's browser and the serverless, which is the best way to connect. And yeah, so that's sort of the way that Xero platform works in general. And you can see that if weve only collecting events when vehicles are actually moving, you can see there's vast variations in terms of the traffic through that event grid and that signal r instance, during the day or during the busy times, it's going to be very, very busy, and then it'll go right down to virtually nothing during non busy times. So what's really powerful here is the static web app. That's what really allows you to eliminate bucketed usage, and that's how I refer to things that are server youll if you like. What you're really doing is paying for a bucket of usage. So even if you're only using 5% of that bucket, with bucketed usage, you have to pay for the entire bucket. So if you're thinking about virtual machine, maybe you have to buy a dual core or a single core machine. Even if you're only using that core for 5% of the time, you still need to pay for the whole core. You can't pay for a fraction of it to go fully serverless and get all of the billing benefits and all of the efficiency benefits, you need to be able to eliminate that from your entire architecture. The static web app allows you to finally do that and eliminate it entirely. So you can think of it as an alternative to MVC. So if you're used to running ASP net or Django, it's kind of a drop in for that. It consists of a bundle of HTML, JavaScript and CSS, or alternatively webassembly. If you're using frameworks like U or Blazor that are just loaded files into the user's browser, so they could be hosted anywhere. Generally they're hosted in cdns or something like that. Content delivery networks, you can use front end frameworks, so we use react and typescript as our preferred one. But again, we're fairly flexible. If there's something that comes along that we like, we'll definitely try it out once these apps are loaded up. And the way to really think about this sort of thing is think of them as an app, like an app on your phone, and that will help in terms of the security concepts and things like that is if you think of it as an app on your phone rather than a web page on the Internet, that sort of makes it easier. So once loaded up, they then go cto the secure back end, which is going to be in our case as your functions. And that has very, very stringent security. So for internal staff we'll use as your ad, and for external customers we'll use as your ad b to c, the world's worst named cloud service. And what that effectively is, is hosted login. So we don't store anyone's usernames and passwords, we don't even store their email address or anything like that. We leave that the service provided by Azure to do. And that allows us to protect people's information a lot better. Yeah, it also allows us to do things like apply groups. And this is basically a full enterprise. It allows you to use what an enterprise would use for segmenting these users. And I've done it on a massive scale for nothing or virtually nothing. So you can use these really top end, very expensive Internet commerce tools for virtually nothing if they are serverless in nature. These other benefit of things, static web app is it's so scalable. So to scale any sort of web application, what you generally start to look at doing is separating out the front and the back end. So say, if you've ever looked at, I don't know, say, scaling a WordPress install, right. One of the first things that they advise you to do is move all of your static content onto a content delivery network. Right. And then further things that you can do is. Right, well, let's maybe switch out so that we're using APIs on the back end and we're loading up a single page application instead. And that will shift some of the processing from our side to the client side. Once you've done that, you can then separate them entirely. So you can have the front end hosted somewhere totally separately to the back end and you can scale them separately. So it means that even if you don't keep everything in a serverless mode forever, for example, maybe for whatever reason you need to shift your API layer to be permanently hosted. Maybe you don't want cold startup, which are serverless, particular thing for serverless, or you need to be within a virtual network that has very specific controls. Whatever it is, you're in a very nice adaptable point of view. It's no bad architecture to be in, if you like. So yeah, so the benefits we found using serverless, being able to deliver very fast as a startup, that's really the big thing that we need to do. We need to deliver software as quickly as possible to be able to target that market and continue to grow. Yeah, we found that we haven't had to spend very much time, and part of the reason for that very fast delivery, I should say, is we haven't had to spend a lot of time managing servers or thinking about what planning what instances we need or all of that sort of thing. We've been able to just get going and not have to worry about patching and all that sort of thing. Scaling so far has been good. I've not noticed any problems at all. We are already tracking the entire fleet that we've got deployed through our serverless system and it's not even choked, even slightly. So it's going well so far. Obviously with scaling, it's one of those things where you can test it with things like serverless artillery and all of that stuff, but nothing really replaces the real production issues. So we'll see how we go with that one. But I'm not really expecting any problems. And it's incredibly cheap. Our bill is less than 100 pounds. And for a serverless, for a startup that's very, very cheap. And that's what you need as a startup, you don't want to be spending money on infrastructure when you could be spending on growing your business. Speaking of growing our business, we are hiring and we'd love to have applications through for c sharp developers and front end generally react. As I mentioned earlier, developers, if you've got another skill set that you think would be really valuable to us at Zeti, then by all means just drop me a note. And we're here to hire good people, so be sure to get in touch. And yeah, any questions, please get in touch with me on Twitter or email me dambass at zeti co. UK. And yeah, I'll try and get back to you and I look forward to hearing any questions. Thank you.