Andy Watt is a Senior Software Engineer. He returns to the show to talk about his book, "Building Modern SaaS Applications with C# and .NET". He begins by explaining what "Software as a Service" is all about. He also tackles the main concerns you might encounter when creating SaaS applications. Additionally, he dives into the pros and cons of using C# and .NET to create modern SaaS applications. 

 

Shawn Clabough (00:03.877)

Hello and welcome to another episode of Adventures in.NET. I'm Sean Claybo your host and with me today co-host Adam Framonic. Hey Adam. Hey. And Mark Miller. Hey Mark. Good. It's nice to see you guys. You know I was off for...

 

Adam Furmanek (00:11.563)

Nice to meet you folks.

 

Mark Miller (00:15.094)

Hey, how's it going Sean? I'm like a I'm a professional. I'm a professional co-host now Just if you have any issues talk to my agent. That's all I'm saying Just be checking a second here. I'll get back to you by the end of the show I think

 

Andy Watt (00:24.124)

Thanks for watching!

 

Shawn Clabough (00:26.685)

How do you define professional? Yeah, Webster's probably has a couple definitions there. I'm not sure which one you fit under, so we'll have to check.

 

Mark Miller (00:38.214)

It's bad news, Sean, I'm not a pro! It's bad news.

 

Shawn Clabough (00:42.469)

Eww. No, it's good news for you, Mark. Every time. Every time we got you on, it's good news. All right. Let's welcome back to the show Andy Watt. Hey Andy.

 

Mark Miller (00:48.624)

Okay.

 

Andy Watt (00:55.896)

Hey guys, lovely to be back, nice to talk to you all again.

 

Shawn Clabough (00:59.317)

Yeah, so I think last time we had you on the show was about June of last year. And what did we talk about? I think we talked about containers and using containers remotely and things like that. That was a good talk.

 

Andy Watt (01:10.736)

That's right, dev containers.

 

Yeah, yeah, I enjoyed that. It's a tool that I've used quite a lot since actually very powerful, very, very useful tool.

 

Shawn Clabough (01:21.889)

Yeah, so if anybody's looking up the show, that was episode 107. And actually it was February of last year, so a little more, a little older than that. So, as of now. So what have you been up to since then? Did you write a book?

 

Andy Watt (01:29.956)

Time flies.

 

Andy Watt (01:36.288)

I did, I did, I wrote a book on software as a service with.NET. So I've been rather occupied since then.

 

Shawn Clabough (01:47.405)

Yeah, so the book, what is it? It's software about SaaS applications.

 

Andy Watt (01:54.288)

That's right, SaaS application. So the idea of the book was to take people through start to finish everything, hopefully, that you need to do to build a SaaS application and focusing on the Microsoft tech stack. So that was SQL Server, Entity Framework, C Sharp with Web API, and then Blazor on the front end. Which Blazor was a learning experience for me as well because I hadn't done a tremendous amount with that. And possibly a less common choice still, I think, just now.

 

Shawn Clabough (02:22.245)

So for the new developers out there that might be listening, what is SAS? And how is that different than just a normal application they might be building on a day-to-day basis?

 

Andy Watt (02:34.94)

So software as a service, as the name implies, the software is provided as a service instead of as a licensed product. So what that means for the people that are using it, I suppose, is the way that you would interact with the product is it doesn't necessarily have to be delivered as a web app, but I think they all are basically. So you log in, you pay a subscription and the subscription gives you access to the software and the software is a service rather than a thing which you own, as might have been the case, you know, when you used to have to go and buy a CD and.

 

license key and install it on your computer. If you think about the likes of Gmail for example, that's a very common software as a service which you don't actually have to pay for.

 

Andy Watt (03:17.26)

I think you can make the case for social media being software as a service as well. And many other things like if you use TurboTax for your tax or QuickBooks for your accountancy for example, that's all software as a service.

 

Shawn Clabough (03:31.445)

Okay, okay. I think the one I'm most familiar with that I use on a regular basis is all the Adobe products. It used to be something you would buy the box and install it and you'd have a perpetual license forever and ever. But now you pretty much have to pay a yearly fee for all the different applications you want to use. And then if you don't pay the fee, then you don't get to use it anymore. So.

 

Andy Watt (03:40.582)

course.

 

Andy Watt (03:54.872)

Absolutely. And there are pros and cons of course, you know, because I think to a certain extent people liked feeling like they owned the product and they had the product. But of course the big plus side of software as a service is upgrades, right? Whenever a new upgrade is pushed, everybody just gets the upgrade. And normally that would just be included in the monthly fee that you're paying. So you stay on the latest and greatest software as long as you're paying the monthly fee for it.

 

Mark Miller (04:19.158)

You know, one problem that I think you don't really think about in this space is that, is in the area of paid plugins. So if the paid plugin for, to the software as a service.

 

Mark Miller (04:37.282)

isn't a service itself. It's something that's installed and has a perpetual license forever. That license is still only as good until your next upgrade that happens. This has actually happened to me with a couple of different software products inside the Adobe Stack where I've-

 

paid for a full on perpetual license outside of it. And then Adobe gives me the free upgrade. And even though the license I have is for forever, now the program I bought that forever doesn't work anymore because the updates there and their tech support is like, well, you can roll back to an earlier version of Adobe or you can buy this other product we have, which is now going to work with it.

 

Andy Watt (05:20.168)

Or more likely than not they'll sell you a license for their new software as a service plugin because everything's kind of moving in that direction

 

Mark Miller (05:26.87)

Yeah, well, you know, that would be actually better than where the situation that I experienced. I would take that over the other, right? Over all of a sudden, now software you paid for is not working.

 

Andy Watt (05:30.236)

Hehehe

 

Andy Watt (05:38.316)

Of course, yeah, that's a terrible outcome no matter what the cause of that is.

 

Shawn Clabough (05:44.165)

So when you're developing a software as a service application, what are some of the main concerns you have to think about as you get started and come up with requirements and design and things like that?

 

Andy Watt (05:56.688)

So starting from a blank page, I think picking the tech stack is not easy at all because there's so many different ways you can go with it. You're picking the tech stack from the database through to the front end. And the way that you expect your customers to interact with the application when eventually it starts to sell will have to influence how you build the tech stack. So I think that really is your first big problem to overcome. And you kind of...

 

you sort of need a crystal ball to some extent because you know what it's like when you start building a product, especially something which you hope is going to be large and successful and run for many years. It's kind of difficult to predict how people are going to use it. And you can't really be agile with your entire tech stack. You have to just make some decisions at the start of it. To some extent, I know there's always wiggle room and you can change things out, but to a certain extent you're locked in. So I think that's the big one. And I think that giving people a good starting point.

 

at least explaining how a certain tech stack will grow and will change with their user bases is one of the things I was really hoping to get across in the book. Just prevent that problem with a completely blank page when you approach a problem.

 

Adam Furmanek (07:07.246)

So which parts of the tech stack is something that we really need to make a decision very early because we can change it later? And which parts are something is like a two-way door decision that we can change as we go?

 

Andy Watt (07:23.364)

So in theory, if you're doing your interface-driven development properly and you're segregating everything and you're splitting into microservices, you do have a lot more control over these things. But one good example is, are you writing a web app or a mobile app? And that will influence how everything works down the line. And in certain scenarios, it can be easy to say, our customers will use their mobile phones. And 90% of the cases, they were writing a mobile app. If you're not sure about that, you can find yourself tied to a certain platform.

 

And for all that you can build both, it's slightly different building mobile apps to building web apps. And the choice on the front end, mobile or web, will have some knock-on effects on your API layer and whatnot and maybe your authentication layer. So I think that's a really important one to think about, is what are most of your users going to access your application on? And it used to be very easy before, because it was only their desktop computers. Whereas now you've got.

 

desktops, tablets, mobile phones, watches, and maybe even headsets shortly as well to think about. So that's one. And the other one is on the other end of the tech stack. I think the database is important. And assuming you're gonna have like one monolithic database, I do talk about microservices in the book, which is a whole different side of things. And...

 

It's possible to switch around databases to some extent, but say for example, you want to switch from a document database to a relational database. I have never seen that done successfully. You're gutting your application if you want to do that. You're fundamentally changing the shape of the underlying data. So you definitely want to get those decisions right.

 

Adam Furmanek (09:04.53)

Yeah, I had the same. The only time I saw someone actually changing some of their database internals was in some internal project when they really had like three months to waste. So they decided to change the database in DRM just for fun. But what about things like, I don't know, programming language or maybe your cloud provider or infrastructure provider? Do these decisions affect the process very early or can we change the mass along the way?

 

Andy Watt (09:13.5)

Yeah. I have like three miles to go. Haha.

 

Andy Watt (09:34.412)

So the programming language that you want to use, I would argue, it is quite interchangeable, but why would you? You know, like what you can do with a.NET Web API, you can do in Node or you can do in whichever other language you choose to use. It's more the, like that's just, you know, you set up at the start and you go with it. It's more the things that change like the mindset that you're working in. You know, if you change the document database, you're changing your mindset about data. If you change the mobile app, you change your mindset with the data.

 

Andy Watt (10:03.84)

It's very difficult to change because you're rewriting it, but it doesn't really affect things. It doesn't affect how the users interact with the program. So now the second part of that question, changing your cloud provider. In theory, very easy. In practice, I think very difficult because the promise of cloud, you use Terraform and you use Docker and you can just ping it off to whichever cloud provider you want and you can chop and change. But the reality is the cloud providers, they...

 

they know that and they will try and hook you in, right? So if you're writing Azure functions, you're not changing that to AWS. And if you're using the AWS storage options, you're not changing that to Azure very easily. And I have used Terraform before, and I know that in theory you can just change, but in practice, I don't know how easy that would be either. So I think that's a very good point. I think that making your choice about your cloud provider early and making a good choice early is very important.

 

And if you're hesitant about that choice, you need to make sure and not use any of the cloud specific things. Azure functions being the classic example of that.

 

Adam Furmanek (11:10.242)

Yeah, not to mention that we may be actually like looked out from the cloud provider as it happened with something like TikTok, right?

 

Andy Watt (11:20.768)

Yep, yep, and it can be very, very expensive as well. That's the other thing to consider with cloud. It allows you to set up so quickly. It can give you this false sense of security at the start when you don't have any customers. But then once you have a million customers hitting your API and your database and your authentication services, the price can really start to ramp. So not only choosing the right one upfront, but also being very clear about what the costs are gonna be. You know, you need to look at this and say,

 

we want to get to a million customers, how much is this gonna cost us? Because the answer is probably quite a lot.

 

Shawn Clabough (11:57.925)

So your book covers.NET as the tech sack for SaaS applications. How well-suited is.NET for building this type of application? Is there positives and negatives to it?

 

Andy Watt (12:14.1)

Yeah, of course, I mean, there's positives and negatives to any tech stack you care to choose, I suppose. I would personally argue, and I've been developing a dotnet for 18 years, so I'm somewhat biased towards it, but I would argue it's an excellent choice. And I've kind of wondered, you know, like the open source community doesn't use dotnet, even though it's open source now and multi-platform, they will always go to a JavaScript or TypeScript solution. But if you look at what you get from dotnet,

 

or the Microsoft tech stack, you know, SQL servers and extremely powerful relational database battle tested over decades. It works entity framework. There's there's pros and cons of entity framework, you know, it can be slow. But it's also very good. You know, it gets you it gets your ORM layer very, very quickly, very well established way of doing it. The API offerings for Microsoft just now from web API are also good. I know there's, you

 

tech stacks to use in the back end like rust for example which are faster but Does do you need bleeding edge speed for a lot of what's happening a web app? I would argue maybe not and When we get on to the front end, I think the situation is a lot less clear because Microsoft have got history with front ends, right? I don't know if any of the rest of you were silver light experts for a while But I did many years worth of silver light and then the rug was pulled out from under us on that one so

 

I think the argument for using Blazor on the front end is much less, so I included it in the book because the book was on.NET, Microsoft, Stack. I hope that at some point it's a good choice, as in that Microsoft do start to support it, because there is tremendous power in being able to use the same language across everything for using.NET essentially for your data interaction through Entity Framework API and on the front end. It's much easier to support. I also...

 

Adam Furmanek (14:11.339)

Yeah.

 

Andy Watt (14:13.404)

There's one other thing to say about Microsoft is they have been doing this for the long haul, you know, aside from the front end. They've, you know,.NET has been around for years. It's got so much work behind it, so much support behind it. It's not going to go away in the next 20 years. So if it's not like a flash in the pan back end, you know, like for example, Ruby on Rails, that was big for a while, never really hear about that anymore. But.NET has outlasted that and then some.

 

So from that point of view, I think you've got a lot of longevity with.NET, or the Microsoft Stack rather, I should say.

 

Adam Furmanek (14:48.598)

We're all dinosaurs here, so we've seen a couple of like front-end or even desktop frameworks that were around super popular and then died out. So we know what you're talking about.

 

Andy Watt (14:51.408)

Hehehe

 

Andy Watt (14:59.536)

Exactly. Exactly that. I don't quite trust them to support Blazor for the long term, but we'll see. I hope they do. I like it. But I think it's fairly safe to say that if you build something a web API, that'll be relatively well supported for the next decade.

 

Shawn Clabough (15:14.981)

So some of the concerns and questions I would have when I first would build something like this would be how to handle licensing and then also security concerns because it's gonna be one application with lots of different tenants inside of it. How do you handle that and what's the best way to do that?

 

Andy Watt (15:38.9)

Well, I don't know if you can say for sure there is a best way to do that. And the other problem with all things security is that the best practice changes all the time. It's a total moving target. With multi-tenancy, there's a number of ways you can do this. I do have a chapter in the book covering multi-tenancy, but it really depends on how important is it to your customers that the data is definitely segregated. And so if we think about

 

Gmail, for example, there's no way that every Gmail user has an individual tenant where they have a unique installation of the application they're using. Because Google will read your emails anyway. So if you're using Gmail, you can't be all that security conscious. But for example, if you had a tax application, like TurboTax, for myself who uses that, I don't pay extra for my own instance of it. But if I was.

 

an enormous corporation or a military contractor or someone like that, I would be prepared to pay extra to have a completely segregated tenant. So as with everything in this, you need to look at what you think your use case is going to be. Are you going to have any of these very high security conscious customers? Is it all just going to be the general public? You probably don't want to pay the enormous extra fee for it and decide you're going to cut it up that way. And the general way you can cut it up is you can have a unique application instance.

 

per customer, which is the most expensive and the most secure because it's got a nice circle drawn around it with nobody else on it. The next sort of step up, which you don't see very often, is you can have a unique database schema per customer. So they would be using the same database server, but with completely segregated schemas in the database. I can't think of a good example for that, and I couldn't when I was writing the book either, because I just don't think that should be very commonly done. And the one that I'm sure we've probably all seen is like a shared schema where you've got a tenant ID column.

 

in the tables. And that just sets up when you're fetching the data for me, you say where tenant ID equals Andy what. But then my data is in the same table as everybody else in the world's, which is a little bit easier to attack perhaps. Did that answer your question? I'm not sure if I want off on a tangent there about multi-tenancy.

 

Shawn Clabough (17:56.185)

You know, that was good. You know, it's my concern there is, you know, do I make an instance of each application, you know, to keep it as secure as possible? Or, you know, I guess it's always a trade-off between that security and performance. Because, you know, each one's its own instance, so it's gonna be raising up costs, but be more secure and it could be less performant. So I guess pick two out of the three type of issue. What do you want?

 

Andy Watt (18:11.868)

Absolutely.

 

Andy Watt (18:22.809)

Yeah.

 

Andy Watt (18:26.764)

If you've got customers with sufficiently deep pockets, you can pick all three. But they need to have deep pockets.

 

Shawn Clabough (18:30.437)

Hehehe

 

Adam Furmanek (18:33.458)

You mentioned a very good thing, whether we should create like separate schemas for each tenant or put everything in one table. I believe many programmers felt into this like, wow, separate schemas, this really sounds like a good idea. But there is big drawback to that, meaning that many databases do not let you create infinitely many schemas. So you just hit some...

 

Shawn Clabough (18:33.744)

Yeah.

 

Andy Watt (18:59.697)

Yeah.

 

Adam Furmanek (19:00.53)

unexpected limit and especially we hit it when your business starts to grow and it's kind of a little bit too late to reorganize everything. So that's the pitfall we want to avoid.

 

Andy Watt (19:11.352)

Absolutely. And it's not particularly well supported. Like for example, an entity framework, you can support a unique database per customer instance or the tenant ID in the tables, but they don't really offer support for a unique schema. I think probably for the reasons that you said, because the database backend will at some point eventually start to complain about that. And then you've got a huge problem if you've based your entire application around that.

 

a huge and very expensive problem.

 

Adam Furmanek (19:38.318)

Yeah, I think that's generally that applies to multiple libraries, multiple ORMs. Like while it's easy to change like the patterns how you name your tables, it's generally pretty hard to specify what schema you use. Sometimes you just define it on connection so you can't change it like dynamically depending on the request you get. So it sounds easy, sounds nice, but in practice it's very hard to maintain.

 

Andy Watt (20:06.22)

Absolutely, I would argue that the unique schema in a shared database is the worst of both worlds. If you need the security, unique database and app stack, if you don't care so much and you just need to make it easy and cheap for people to use, tenant IDs in the tables. There's very few use cases where I really can't think of a good use case where I'd recommend the middle ground.

 

Adam Furmanek (20:27.626)

And what about monitoring? If we can switch gears for a little, if we have like one database, how do we do monitoring? So we see which tenant it applies to. And if we have multiple databases, should we like put it all together when it comes to monitoring? Have one dashboard, should we split them? How would you organize that?

 

Andy Watt (20:46.836)

Yeah, well, again, I feel like I'm going to say this a number of times. That's just, it depends on the customers because you have to be careful. You know, if you're segregating your databases, but you've got a single monitoring point, then your monitoring becomes a attack vector to get access to all of the databases. And you have to be very careful with what you're putting into the logs. You know, if some information that you don't want shared winds up in the logs and they're all just stored in one centralized location, then there's no point in segregating your database. So

 

Yeah, unfortunately the answer is it depends. But if you've gone to the bother of giving a customer a completely unique app stack and database, I think that customer would probably be a bit disappointed if you had a centralized logging solution that was logging to one place with all of the other customers.

 

Shawn Clabough (21:34.009)

Are there ways to limit what one customer can do, set their threshold of you can't use any more resources, a cap on it so that one customer can't take down 1,000 other customers' performance because you're running on the same system?

 

Andy Watt (21:51.648)

Yeah, so that's called the noisy neighbor problem, which is a well-known sort of issue with all of these things where you're essentially sharing resources. And even if you are talking about a unique app stack for a customer, if that's running on the same cloud platform and there's some limitation on bandwidth or whichever on the cloud platform, then they can easily start to leak across. So yeah, you can look at all sorts of ways of doing that, just throttling the request, for example, is a fairly basic one, or throttling the bandwidth.

 

when they get over a certain amount of bandwidth. But that's certainly something you absolutely have to think about when you're taking on customers. And it's gonna work that, you know, there'll be an 80-20 rule where 20% of your customers will use up 80% of your resources. And there's gonna be some argument where certain customers are costing you money to have, and also annoying all of your other customers by consuming all of the shared resources.

 

So there's a number of, you can put that in at just about any level you want, but I believe that my DevOps is not the hottest, but I believe that with Azure and AWS and all of these platforms, you can set up at that level, which would be a good place to put it, because then you're sort of preventing them getting into your application at all if they're over the usage limits.

 

Andy Watt (23:05.74)

You can see this. I was going to say like a very good example currently that I'm sure everyone's probably been reading about is chat GPT. You know they limited their GPT 4 to 25 requests per three hours I believe recently.

 

Shawn Clabough (23:05.925)

And how about, yeah, go ahead.

 

Andy Watt (23:22.192)

Presumably to prevent the noisy neighbour problem.

 

Shawn Clabough (23:26.545)

Right, right, right. And how about back-end design? Is there certain design techniques that work better? Is it best to go like microsurface architecture or some other architecture for doing this?

 

Andy Watt (23:42.912)

Yeah, so microservices is a good buzzword just now, and I think everyone's sort of looking into it. My impression with microservices is it's extremely powerful. It can get you out of a lot of problems that you will encounter as your SaaS application grows, but it also gives you a tremendous overhead in terms of development, especially at the start. So if you're a startup, for example, and you don't have your customers yet, and you maybe don't have your product market fit yet, do you want to spend the extra engineering time building microservices into it? I'm not so sure.

 

It depends, it depends what your resources are of course. But so I think that microservices are very powerful and very important part of the puzzle here, but it needs to be used carefully because there is a very steep learning curve for it and quite a lot of overhead across the board. Hosting gets more complicated, maintenance gets more complicated, debugging and testing gets more complicated. And this is for the life cycle of your project. My take on it is you should work with a single service until it's too big to justify being a single service and then break it down.

 

rather than trying to start off with a microservice architecture. Because when you cut the service at the start, you don't really know where your boundaries are. But when you build it and one part of it outgrows it, you know precisely where your boundaries are so you can cut that piece out of it. But there are good arguments to do the opposite of what I just said as well.

 

Adam Furmanek (25:05.31)

Are there any parts in C Sharp and.NET, as your book focuses on that, that make the building SaaS applications much easier? Any remarkable things that.NET provides to make your life better?

 

Andy Watt (25:21.576)

Entity Framework, I think. It's a fantastic ORM. You know, once you get the hang of Entity Framework, you can basically, I hesitate to say this because I'm sure that people will disagree, but you can somewhat stop thinking about your database to a certain extent, as long as you know what you're doing before you start not thinking about it, and as long as you set it up, okay. I think that's a fantastic tool, especially if we're talking about a startup, maybe trying to get a software as a service thing off the ground as quickly as they can.

 

That's fantastic.

 

Andy Watt (25:54.904)

If you want a counterpoint as well, like maybe something that they don't do so well, it's authentication and authorization. And I believe that's being improved with.NET version 8. But the authentication stack has been extremely difficult to work with with.NET.

 

Adam Furmanek (25:55.394)

Yip.

 

Andy Watt (26:13.42)

Assuming that is you want to build your own, I don't mean completely roll your own. You know, if you're shying away from using one of the third party options like Auth0 for example.

 

Adam Furmanek (26:23.098)

Yeah, generally authentication is always tricky, so you probably don't want to roll your own solutions in that case.

 

Andy Watt (26:27.192)

Yeah. No, but there you can do...

 

Shawn Clabough (26:30.645)

Yeah, I recently went through some headaches with authentication because we had to switch a.NET web forums application over from using forum-based authentication to Okta.

 

Andy Watt (26:46.276)

Yeah, if you want to if you want to use the identity server part of dotnet which isn't really rolling your own authentication as such But it's taking a bit more control over it. It's it's painful. It's extremely painful They have acknowledged that and they do say they're gonna fix it with version 8. So we will see

 

Adam Furmanek (27:02.734)

And what about testing that? We mentioned a couple of different areas here, right? Multi-tenancy, databases, hosting, authentication. How do we actually make sure that what we developed works well?

 

Andy Watt (27:14.872)

Yeah, with great difficulty is the answer to that question. With SAS apps, testing is difficult across the board. The unit testing, as ever, is relatively easy because you just test the units. And the unit testing frameworks for any technology you're going to use is reasonably well established, as well, I think. But when it comes to integration testing and end-to-end testing and really making sure the thing actually works, then it's much more complicated. I think.

 

you're basically looking at a Docker solution, especially if you have gone with microservices. Because then you could have, if you've got five microservices, each with their own database, potentially with different database platforms, then you need to be thinking about how you're gonna spin them all up for E2E testing. So with testing, it's very, very important not to shy away from it with a SaaS app.

 

I think it's true of any app, but it's even more true. And because it's so difficult, I think it's easier to just not do it. But you really need to think about it. And the thing you need to think about is end-to-end testing. How am I spinning everything up and doing the user interactions and following it through and making sure that everything works?

 

Adam Furmanek (28:28.646)

So you mentioned Docker basically and the other approach we could take is basically creating infrastructure from scratch using infrastructure as code in the cloud provider we have. Do you think any of these approaches like better than the other and there is like significantly I don't know better outcome or maybe lower maintenance in any of these?

 

Andy Watt (28:53.604)

So I'm a big fan of the developer environment being on a developer's laptop. So I strongly prefer if I can have the whole application up and running on my laptop, and I can run all of the tests without having to go to a cloud service. Not that it ever happens, but the example I always give is it's good to be able to develop on a flight, on a transatlantic flight with the Wi-Fi, if you want to, for example. And I think that any sort of break in the developer's workflow, so if they have to stop and spin up these things in the cloud, and if this takes a...

 

a bit of time where they've got to wait in a queue for it, that can break your workflow. Whereas if you've just got a terminal window open and the tests are spinning through and you can see when they go red and you can see when they go green, I think that's a much more pleasant environment to work in. So I would say that is good in terms of having it all locally in a Docker setup. But of course, if we're talking about SaaS here, you can talk about some enormous applications. Like I can't imagine that anyone can run Gmail on their own laptop.

 

you'd imagine the back-end infrastructure behind that is enormous. So in that case, you'd have to start moving on to something like infrastructure, for sure. So I would say that I would argue that you're always better off running on the developer's machine if you can. So if your SaaS application is small enough that that's feasible, you should attempt to do so. But you have to be prepared for it growing too big for that. And you need to have a strategy for moving on to a cloud solution when the time comes.

 

Adam Furmanek (30:20.574)

Yeah, I couldn't agree more with ability to run stuff, especially when you're flying. One thing though, I never learned how to do properly with such an approach, which I'm big fan of, as you said as well, is how do I do load testing with running stuff locally?

 

Andy Watt (30:26.084)

Yeah.

 

Andy Watt (30:38.252)

Yeah, that's challenging. That's one of those things that you maybe just will not be able to. There's certain instances where you just have to move it onto the server. You can say the same about pen testing. You're gonna have to have some infrastructure for that. There's no way around that. It has to be as close to your production environment as possible, if not your actual production environment.

 

Shawn Clabough (30:59.985)

What do you think some of the biggest mistakes people make when they're developing a SaaS application?

 

Andy Watt (31:09.668)

That's an excellent question. So choice of database technology, very important, very difficult to change. I think that's one that you have to get right. You can see the database is the foundation of your application. And if you need to change it, it's tricky to do that. And I think the other really big one, which we have touched on already, is not thinking about the cloud costs as you start to scale.

 

because that can put you out of business, and often these costs, they're not really linear. It's like as a small company, you get certain discounts or free access, certain amount free, and then suddenly you've got a big step change when you go over X number of customers. So not taking the appropriate care when you're choosing your cloud provider at the start could literally sink your company or sink your project.

 

Adam Furmanek (31:57.922)

When you mentioned now the costs, Microsoft was well known for providing BISSpark or other programs for startups. Are there any programs like that nowadays that we might be using?

 

Andy Watt (32:12.504)

Oh, you mean... Um... I'm not...

 

Adam Furmanek (32:16.194)

For startups, I mean, I'm starting a new company doing SaaS. Does Microsoft give me free perks and other stuff?

 

Andy Watt (32:27.601)

They do. I'm not 100% sure what those perks are like just now. I'm not too deep into that side of things. I believe there's startup discounts that you can get from Microsoft that will see you through the first year, for example, with a certain number of credits that you can use.

 

But it's worth being aware that doesn't last forever. You're going to have to pay the bill at some point.

 

Adam Furmanek (32:50.038)

Yeah, and as you mentioned, especially that you run into your business, those increasing costs can actually put you out of that. So how do we prevent that? What do we do to make sure that we are not surprised when things go good, remarkably good, that we are put out of the business?

 

Andy Watt (33:05.296)

Hehehe

 

Andy Watt (33:08.948)

Yeah, well, so, you know, it's easy for us technical people to just talk about code and databases and whatnot all the time, but you just have to be aware of the business environment that you're operating in. So you need to know roughly speaking what your customers are prepared to pay for it. You need to know what it costs. So you need to analyze your customers. And this is just from the monitoring and the logging tools. You need to know how much your average bandwidth is per customer, for example, database requests, all of these things. And then you have to be aware of what that's going to cost. So a little bit of a look ahead, you know, if we get a million customers.

 

the server costs go up to this, there'll be some economies of scale, there may be some step changes. So, and that is important for the more technically minded among us, but it's also a question for the business people in the presumed startup. From our point of view as techies and coders, we can write efficient code, make sure that it's not being wasteful of bandwidth or wasteful of processing time or database.

 

Andy Watt (34:07.492)

database capacity.

 

Mark Miller (34:11.01)

Andy, I've got a question on user interface design. Is there anything different about designing a user interface for a SAS application compared to, I suppose, any other user interface? Are there any special considerations?

 

Andy Watt (34:32.093)

I don't think so. I think a good user experience is just across the board, whether it's a mobile app, a web app or something which has been delivered as a SaaS app. You definitely need to pay a lot of attention to that. I think it's very important because your customers can just stop their monthly payments if the user experience is not sufficiently polished. So I think it's maybe true to say that you have to pay a little bit extra attention to make that a good experience for your users.

 

Mark Miller (35:00.578)

So what about the considerations for, I guess, I guess in terms of like feedback loop, are there issues with connectivity or performance, database performance, things like that, that you need to be mindful of and pay more attention to in terms of, and maybe even develop strategies for, right? It might take, this might take a long time or this connection may not be available.

 

Are there thoughts along those lines that impact the UI or the user experience user interface or is that is that not really? an issue

 

Andy Watt (35:39.076)

I think that is an issue. So because we're generally always talking about web apps as well, so it's useful, you know, if there's no internet connection, you generally can't use a web app. So for example, using something like a progressive web app might get you away from some problems with that. If you did have a server go down rather than just showing a 404, you know, there's still certain parts of the application that could work. Because if people don't like your UI, you know, your UI is your product with a SaaS app. It's the only thing you're selling really.

 

And if people don't like it, they will just hit the cancel button and that's it. You've lost a customer and you know, your customer acquisition could be very difficult. Um, so I would say that certainly trying to make sure that it's that the UI continues to be as responsive as possible, no matter what horrible things are happening on the backend is more important because it's directly tied to your revenue.

 

Adam Furmanek (36:31.054)

Does it also mean that when we go mobile, do we need to like stick to the platform or integrate with the platform 100% and because of that, we wouldn't be able to use cross-platform frameworks or there is no relationship like that?

 

Andy Watt (36:48.66)

You mean for the front end, like a cross-platform, you can use something like, for example, React Native that will work for Android or iOS. So you can still do it. This is always a compromise if you're using one of those, you never get quite the power of the full one. So again, it depends on what you think is, on how you think your users are gonna use the application, whether you need to just spend the time to develop two apps.

 

Cross Platform's got a checkered history.

 

Shawn Clabough (37:18.541)

And Blazor has some of that in there too, right? You can build with Blazor and use that.

 

Adam Furmanek (37:18.654)

Yeah, that is true.

 

Shawn Clabough (37:27.086)

platform.

 

Andy Watt (37:27.144)

Yeah, it's, it's what's coming on. I mean, the, the UI story from Microsoft is as ever a little bit murky just now because they've got Maui as well, which is an attempt to cross platform. That's meant to be the successor to Xamarin forms. And then they've got Blazor kind of on the sidelines as well with Blazor server and Blazor wasm. So yeah, it's, it's true. I don't think they've got a very consistent story yet about how they would want to approach that. And I believe

 

Blazor to do something which may work on a mobile app but it's essentially a web platform for now and I know they've got ambitions to integrate it with Maui but I don't believe that's ready for the prime time yet. I think that's still being discussed how they're going to do that.

 

Mark Miller (38:14.866)

Andy, I've got maybe another completely out of bounds question. But one of the things that strikes me as potentially super interesting about a SaaS application is the ability for collaborative creation, right? Where multiple people might be working on a single document, whatever that document is. And even maybe not only people, but maybe also artificial intelligence agents might be working in that space.

 

Andy Watt (38:18.908)

I don't know such thing

 

Andy Watt (38:31.332)

Yeah.

 

Mark Miller (38:44.418)

I guess my question is, is that something that you have any perspective on? Is that something that fits well into this space? Are there special considerations for implementing something along those lines?

 

Andy Watt (39:01.212)

So yeah, that is something which is increasingly common. I think Miro is a very good example of that, the shared whiteboarding application where everyone can just, you can collaborate very, very cleanly on that. And that does sit very, very well with software as a service. You could technically do that. You could all go and buy DVDs with software on it and install it and we could still link up through the internet. And this doesn't require software as a service. But if you think about multiple people logged into the same...

 

version of the same application and what not. It just it makes perfect sense to do it that way. So I think it's a very good use case for it. There are security considerations because if you're allowing people to collaborate on essentially the same asset or however you like to call it on the back end, you need to make sure that people aren't seeing things they shouldn't be or getting access to other people's accounts. But that's true of true of all parts of it. So I think it's a very good use case for a software as a service application.

 

Shawn Clabough (39:57.961)

And the.NET TicTac has great tools for that, with SignalR, to help with that. So I've done that as well as letting multiple people edit a document and see each other's changes and things like that. So it does work well with SignalR.

 

Andy Watt (40:15.776)

Yes, that's a good point actually. That's one that I should have maybe mentioned when you asked about things that.NET does particularly well for it. That is actually an excellent example. SignalR is a very, very powerful tool for exactly that.

 

Shawn Clabough (40:29.397)

OK, so any other questions or Andy, is there anything we haven't covered that we should talk about for SAS applications?

 

Andy Watt (40:38.184)

Oh, I think we've had a good go through it. And there's one other thing that is maybe worth mentioning, which is related to DevOps, which is CI-CD pipelines. I think that's just essential. I mean, you need that for any web application these days, but if you're gonna do software as a service and do it well, you need to have a very, very clean release pipeline that ensures that there's no interruption to service, because as we've said with the UX, for example, any downtime just costs you users. It just hits your bottom line directly.

 

So you really need to think about that upfront. You need to make sure that you've always got that pipeline working. The other sort of big reason for that, and this is one which I think is applicable to all projects is, if you can't, software that's developed but it's sitting in a Git repo, that's not adding any value to any of your customers, you've paid for that as a company, you've paid for the development, and it's just sitting there doing nothing for six months or a year until you get your yearly release out. And that is enough time for your competitors

 

who are using CI-CD to just completely destroy you in the SaaS market. So you need to be able to, in the shortest practical time possible, get the value that a developer's added by updating the product straight into the hands of the customer. And the only way of doing that in a manageable way that I'm aware of is continuous integration and continuous deployment pipelines.

 

Shawn Clabough (41:57.689)

Yeah, and something that just made me think about is, do you recommend using deployment slots so when you are rolling out an update, you don't update everybody simultaneously just to make sure that there's nothing that wasn't caught or doing A-B testing, things like that.

 

Andy Watt (42:18.264)

Yeah, I mean all good ideas. Again, it depends on the customers you've got. If you've got a couple of hundred, you can probably just push it out to everyone and get the feedback. If you've got a couple of million, almost certainly not. You know, building those things takes time. And so as you're growing your application and adding customers, you'll want to start thinking about these things. Let's face it, you'll probably start thinking about them when you release an update that breaks everyone and you might decide you only want to break 10% of people the next time.

 

But yeah, all of these things are great techniques to make sure that this is a smooth process. Because that's the most important thing, is that it's a smooth process. It doesn't cost you money. I think it's true, like SaaS development takes the developers much closer to the business, to like the money flows. Because the actions that you take can very directly affect that.

 

Mark Miller (43:05.382)

Andy, do you see design patterns emerging in this space?

 

Andy Watt (43:17.073)

How do you mean design? Like, what level are we talking?

 

Mark Miller (43:20.33)

Well, in my earlier question, this idea of collaborative work, creating a SAS application that supports collaboration. Well, as I consider that, I think there must be best practices and things to watch out for that similarly impact every single collaboration.

 

piece of software that's written out there, for example, and from the UI perspective, it's a good idea to show a cursor showing where other people are viewing in the document, where other people's attention is, or changes are, for example, and a named cursor. That's an example of something that I might consider a design pattern emerging from that particular focus. And I was just wondering, you know, like in some of, I guess I could call it maybe not design

 

or like best practices that are emerging as you look at this. Maybe that's a better version of the question.

 

Andy Watt (44:23.9)

Yeah, okay. So I think that is very domain specific. I'm sure there are best practices that are emerging for collaboration tools, for example. I've never built a collaboration tool so I can't really speak to that with much technical knowledge. I mean, if you look at the sort of the mega trends with this, the big things that are coming out are like cloud hosting. It's really a focus on DevOps, for example.

 

So you could argue that the whole DevOps movement is a design pattern, if you can call it such, that's coming because of the need to support these types of applications. You could certainly argue that REST is a design pattern that's coming out for this. If you want to start focusing in a little bit, CQRS is something that's very useful. If you've got a lot of requests.

 

and you want to segregate them into reads and essentially reads and writes. That can get you out of trouble if you're if you've got infinitely more reads and writes, if you can, if you can segregate them. But I don't know. I don't know what order I don't know. I don't know what came first, you know, the chicken or the egg in this one. I got these design patterns allowing us to build these apps or these apps requiring these design patterns or is it in a kind of a cycle? I'm not too sure on that one.

 

Andy Watt (45:50.384)

The other big design pattern, again, and maybe I'm a bit too zoomed out here, is the authentication piece, because we're doing that in a very specific way now with JWT and OAuth2 and whatnot. And that's designed to facilitate SAS applications, essentially, secure login and secure access to back end services.

 

Mark Miller (46:15.682)

Thanks, Andy.

 

Shawn Clabough (46:17.093)

Yeah, all right, so go ahead.

 

Andy Watt (46:17.874)

Yeah, does that? Yeah.

 

Mark Miller (46:20.252)

Yeah, great answer.

 

Andy Watt (46:21.696)

Okay. I wasn't sure if we were talking like Gang of Four patterns or what level we're at with that.

 

Shawn Clabough (46:23.049)

T.J.

 

Mark Miller (46:29.734)

Yeah, I was a little bit in that space. I was a little bit there. But the Gang of Four patterns are essentially coming from noticing what we're doing and building the software and how we seem to be doing some similar things and maybe making similar mistakes again and again. And there might be a way out, right? And so these kinds of things can show up all over the place. So yeah, total wide open space, but yes, inspired certainly by the initial work that they did.

 

Andy Watt (46:58.64)

But I'm sure you remember the very first sort of shared collaboration platform was Google Wave. I don't know if everyone remembers that. It came and went rather quickly. Yeah. And that kind of was the start of it. And then after that, they canceled Google Wave and integrated the technology into Google Docs and Google Sheets. So I assume that they must have been learning constantly over the last maybe 10 years or so.

 

Mark Miller (46:58.646)

The question was, I mean...

 

Andy Watt (47:23.972)

but sadly I don't work for Google so you'll need to go and find one of them and see how they've done it.

 

Don't work for Google yet.

 

Shawn Clabough (47:31.353)

Yet, yet, yet. Or Microsoft, yep.

 

Andy Watt (47:35.8)

Well, yeah, maybe I should go for them.

 

Shawn Clabough (47:39.846)

Okay, I think I'm gonna move us into picks then. So Mark, you want to go first? What's your pick for this week?

 

Mark Miller (47:48.35)

You know, I have failed you, listeners. I have not, there's nothing that I've seen or experienced really that's exceeded my threshold for describing it to you, recommending it to you. I've seen Oppenheimer, I thought it was okay. I saw Guardians of the Galaxy 3, came out on video. It looked, there were some visual, technical stuff that was awesome in it, but story-wise, it felt to me short.

 

Andy Watt (48:04.612)

Hehe.

 

Mark Miller (48:16.286)

of the stuff I normally associate with Guardians of the Galaxy. In other words, funny, you know, and quirky, super quirky, that sort of thing. Well, I don't know. I'll say it's you know, I'm in Valencia, Spain, Costa Rica, actually. I'll say Costa Rica then. I lived in Costa Rica for four years, five years. I generally really loved it.

 

Shawn Clabough (48:24.113)

How about places to travel to, Mark?

 

Mark Miller (48:42.274)

The weather was the same every day. No seasons there because you're so close to the equator. Though you can find almost completely deserted beaches not too far from where you are, which is also excellent. And generally everybody there is nice and relaxed. Don't drive there if you can avoid. Avoid driving, avoid driving in Costa Rica for reasons that are maybe too long to explain on the show. But just don't do it. Don't drive if you can.

 

Shawn Clabough (49:11.353)

And you might need power generators. Is that what I've heard?

 

Mark Miller (49:11.814)

Okay, how's that? That was my pick.

 

Yeah, yeah, yeah. When I did my live streaming from Costa Rica, I had a power. I had power, multiple power generators through the house. I had one on my router. I had one for my equipment, another one for my lights. So generally, if we lost power, everything I still had like at least 10 minutes. I didn't have generators. I had UPS, uninterruptible power supplies. So my the cool thing was, is the uninterruptible power supply on the router would

 

be beautiful because you could lose power in Costa Rica for like hours. But that UPS powering only the router, it would go for hours and you could have Internet on your phone, right? In a complete power block out where everybody because the Internet doesn't go out, it's just the power, right? You just have to keep your router up. That's all you had to do. So maybe that's my pick. It's a UPS for your router. That's what it is, kids.

 

Andy Watt (50:08.54)

Hehehe

 

Shawn Clabough (50:12.286)

Okay, all right, Adam, what's your pick?

 

Adam Furmanek (50:16.686)

So my pick for this week is in video. It's a platform that lets you build or prepare videos based on templates. So if you ever seen lovely videos for like your webinars, video logs or whatever other stuff with nice intro and the beautiful outro.

 

The people generally don't do them by hand. I mean, you go, you take a nice template, you fill it with your data and you're off you go. So generally, NVIDIA can help you with that.

 

Shawn Clabough (50:55.545)

All right, cool. Andy, what do you have for a pick?

 

Andy Watt (51:00.016)

Sure, so I'm going quite topical then. It's something that I think would be very helpful if you're doing a software as a service application. So there's a project called Test Containers, which is open source and it gives you like throw away instances of databases, message brokers, web browsers, and anything essentially that you can run in a container. So it takes a lot of the pain out of testing. It can prevent you doing a lot of complex mocking. For example, if you're trying to mock the returns from a web API, as you might very well be.

 

And it leans on Docker, which is one of my favorite topics to discuss. So I think that's a, that's a good one. If you're, if you're approaching, as we've said in this, on this episode, a very complicated topic, which is testing for software as a service test containers.

 

Shawn Clabough (51:42.905)

All right, cool. And also the name of your book that we've been talking about is called Building Modern Software as a Service Applications with C-sharp and.NET. So available on Amazon now. Or other platforms, yep. Yeah, cool. All right, so my pick this week is a show that I found on Max, formerly HBO Max called Warrior.

 

Andy Watt (51:54.459)

Yes.

 

Andy Watt (51:58.364)

Yep, I would say all good bookstores, but just Amazon.

 

Shawn Clabough (52:12.889)

So it's actually a pretty nice series. It's kind of a martial arts series type thing, a lot of Bruce Lee type stuff in it, but it's based in late 1800s San Francisco. So there's competing Chinese gangs, things like that, but then also you have the town of San Francisco with the police and things like that. So...

 

What I've really found interesting about this show is they have very good writers, they have good storylines, things like that. But I will warn you, there is lots of gore in it. So when somebody dies with a sword, you see them, the damage the sword does, and they don't hold back on the gore, and some of the nudity in the show as well. But other than that, it's got good action, good stories.

 

good plots, things like that. They're now releasing Season 3 is out right now. So I'm in the middle of Season 2 that I've been watching and kind of binge watching one or two episodes tonight. So if you like martial arts and people dying by swords and axes and stuff, check out Warrior on Max.

 

Mark Miller (53:35.53)

That's awesome. Okay. If you like to see people dying, it's Adventures in.NET kids!

 

Andy Watt (53:36.732)

Hahaha

 

Shawn Clabough (53:39.901)

Yeah

 

Andy Watt (53:41.724)

Hehehe

 

Shawn Clabough (53:45.485)

Yep, do not let young kids watch this show. No, do not watch it with them in the room. No. Okay. Thanks, Andy. Our listeners, if they wanna get in touch with you, how should they get in touch?

 

Andy Watt (53:59.984)

So it's AndyWatt83, I cross pretty much all the socials so LinkedIn and Twitter is probably your best bet.

 

Shawn Clabough (54:06.325)

Okay, and if they want to catch in touch with the show, they can find me. I am on x slash twitter and Also threads I am at dotnet superhero. So let me know Maybe some things you want to have Uh us cover on the show or guests you want to have us bring on? Just let me know we'll do it Thanks everybody

 

We'll catch you on the next episode of Adventures in.NET.

 

Andy Watt (54:34.204)

Thanks very much.