Paul Swail: AWS Freelancing, Serverless Testing, and Digital Gardening

About Paul

Paul has been delivering software solutions to customers across several industries using a wide range of technologies for almost 20 years. He is a full-stack web developer by trade and is passionate about the cloud and web technology, but even more passionate about using software to solve real business problems.

In addition to consulting work, Paul ran an AWS-based SaaS product for seven years between 2014–2021.

Paul lives in Belfast, N.Ireland with his wife and 3 daughters. When he’s not busy working, changing nappies or referring to himself in the third person, he enjoys playing and watching football, particularly the mighty Manchester United.

You can find him online on his website, Twitter, LinkedIn, and GitHub.

Transcript

Adam: Hey everyone, I'm Adam Elmore, and this is the very first episode of AWS FM. AWS FM is a live audio shows. We're live on Twitter spaces. Each episode, I'm going to interview a guest, just basically people that I admire from around the AWS community, and there may be giveaways. Today, we're going to give away a couple of AWS certification vouchers, so associate level vouchers, and we'll make it up as we go. I don't have a lot of concrete plans at this point. It's just an idea, and something that I really enjoy getting on phone calls with the folks that I'm going to be having on the call. These are people that I really admire in the space, and think they have really valuable insights in the world of AWS. So, today's guest, on that note, is Paul Swail. Hi, Paul.

Paul: Hey, Adam. Thanks for having me. Excited to be your first guest here.

Adam: Super excited.

Paul: Getting used to Twitter spaces?

Adam: Yeah, we've done a couple of test spaces where we've gotten on and made sure that mics were working, and I think we've had some guests, some people join in listening to us saying, "Test one, two." But now, we're for real. This is the real thing. It's going to be very conversational and relaxed. I'm not aspiring to be a radio host. It's not in my future. My wife's making fun of me a lot for what I've done so far, but yeah, I think this is just a great space to have a Zoom call with other people listening in, and then repurpose it to the extent that it's helpful to someone else. Today, we're going to talk a lot about AWS freelancing. There are folks, I get a lot of DMs that are interested in pursuing that. We can talk through what that looks like. First, I'd really like to just hear from you, give your intro, tell us about your career to this point, and where you're focused today.

Paul: Yeah, sure. Sure. So, I'm a an independent cloud architect. So I'm based in Belfast in Ireland, and I've been working software professionally for about 20 years, probably now. I've been independent for just over half of that time. It literally happened last month. So, the last, I had my own SaaS product for about seven years running on AWS, just me, but a bootstrapped SaaS product for the automotive space. But the last four to five years, I've been focusing on serverless. I'm doing consulting work, helping clients sort of get started in AWS serverless space. That's in a nutshell.

Adam: You work from home. I mean, I can see you, we're on a Zoom call right now. Has that been recent? Is that through COVID, and all of the pandemic, or have you been work from home for a long time?

Paul: Yeah, I've actually been working from before that. So pretty much since... I'd had some on-premise client gigs, probably about five years ago, was the last time, but since then, I've been generally working remotely. So, I've got quite used to working remotely. COVID was harder with, obviously, kids at home, which wouldn't usually be the case, but I would find it very hard to go back into a client's office at this stage, just [crosstalk 00:03:23].

Adam: Oh, yeah. Things feel like they've changed for good in that regard. And I've been home for a long time, but even for us, and we've just... Our kids are getting older. We've got kids in the house doing schooling, and I know at some point, I want to lead with this, I know we're going to have kids making their presence known probably on this call, and if this ends up as a podcast. So, talk about when you... You're in the AWS freelancing space. That's how we met really, we both do that. I've been independent for just a few months, really, working more traditional job before that, and had a startup before that. When you're taking on AWS freelance work these days, is it homogenous? Is a lot of the same type of work? What does that work generally look like?

Paul: As I say, I'm trying to focus specifically on serverless. I guess my background first, I was doing some ECS container based work with my SaaS product. That was part of my initial experience with AWS, and I did some work around initially building just general EC2 based type apps on AWS, but within the last three years, I'm focusing solely on serverless, or serverless first, I say, so it's generally the vast majority, if not all of it, is using serverless services, AWS or Lambda, API gateway, AppSync, DynamoDB, all those good things.

Adam: And is it generally... Are you coming into greenfield work, are you building new stuff, or is it a lot of migrating?

Paul: Yeah. Generally, yeah, the vast majority are greenfield. I like getting projects, always have, even when I was working in normal employment, just working, getting a project from the start, helping on the product features side as well, but working with the team to build; this is the architecture that you would need to build for that. So yeah, vast majority is greenfield type projects. Generally, more startups than big enterprises, I tend to work with. So, teams which don't have dedicated platform or operations teams. So it's pretty much, the developers are the guys who are actually running it as well. So it's like, we've lots of full stack multi-skilled people who don't specialize in any one area. So, that has probably been one of the bigger challenges, I guess; it's just bringing folks on an application developer mindset to using some of the serverless services, they'd probably have to do a little bit more than what they would have had to have done in the past in some respects, but less with others.

Adam: You're educating the team as you're coming in, getting them up to speed with latest ways of using cloud technology. You're not just building things, you're coming alongside.

Paul: Yeah, exactly. Yeah. I have done, but I'm trying to roll back my being embedded in the actual development team for the lifecycle of, or even to MVP, because I feel like they get the best value. I do a little bit of that, but not on a full time basis. I oversee the architecture, but I want their teams to become self sufficient. So, I might go in and bootstrap the initial code structure, and the initial AWS accounts and get everything, the pipeline, and the initial architecture, all the code for that in place, then working with their developers for them to take it over, and to actually own the actual feature delivery, and the actual daily sprint, if you think like stand-ups, and that level. I try not to get involved at that level, because the end goal is to help the building up, but also to become self-sufficient with the serverless stack.

Adam: And that's something I've said publicly. I think I have a very similar client base, where there's just a lot of these startups that they've raised some money, they're may be, even a series A or earlier, they have 10 engineers, but nobody has any background with cloud technology, so they're all flying blind, and they feel like they have no guidance in their AWS account, trying to manage this application. I feel like there's a huge opportunity in terms of freelancing as the cloud or DevOps person, reaching those startups where they're not really ready to hire that full-time DevOps or cloud hire. One of the questions I get a lot, and I don't know if you get this one, but when people know that you do freelancing AWS work, it's, where do you get your clients? Is that something you'd care to share, really, what the makeup looks like?

Paul: You can always do with more clients, I guess, but there's the feast and famine cycle, which is generally off freelancing, but I guess, my clients, over the years, it's changed. Initially, say, five years ago, it would have been via recruiters, old school. They would register them, and they would give you leads, which is fine. It's great to get started with, but there's limitations with that around the nature of engagements, And there's a middleman, and it's... So, it's tended to move more... I started blogging, I guess, about probably three years ago, and it's a very slow burn, but I went on a few writing spurts of getting a lot of stuff out there, and that, over the long term, has paid. So I'm getting just inbound leads via my website or via blog posts, or things like that. So, they're the good type where they knew a little bit about what you're about, have read about something, they read something. So, it's not a quick way of finding it. It's not something somebody could just go and do tomorrow, but it's definitely [crosstalk 00:09:22].

Adam: But it's effective, right?

Paul: Yeah. And it's a long term asset that you could build, and if anybody listening is doing work just writing blog posts, it's really useful way of getting the leads in the long term.

Adam: So your blog is serverlessfirst.com, and-

Paul: Yeah, that's right.

Adam: We'll get into your public notes later, but your blog, such a helpful resource for me, I know, in my career, and same with your notes. I think if I were hiring a cloud engineer, the authority you portray when you put out that much information, and that your thoughts are well organized, and you're a good writer, it's an effective way. I think that's what we all want. We all want to be seen as an authority, and that's a great way to build that, but it does take time, I would imagine.

Paul: It is, and it's still not to the level that I would like. I don't still don't get as many as I would hope, I guess, through that. I haven't done a lot of conference speaking, and that's the next level of public knowledge sharing, I guess, and I hopefully do more of that, and lots of podcasts like this, which is good for raising people's awareness of your own skills. And I guess with blogs, it's great in one way, if the people actually would be hiring you are CTOs, but they have that authority to do it, that's great, whereas... But a lot of it could also be peers, like software developers who are like, "It's great, it's great, it's great," but you're never really going to go a job, or a gig out of it. But it's still useful, but via secondary word of mouth, it will all come around, I think.

Adam: It is a good point, though. I am one of your big fans, and I haven't hired you to date. I don't really [crosstalk 00:11:13].

Paul: Adam, come on. I'd wish my fee for this was [crosstalk 00:11:18].

Adam: Right, for this podcast. I guess I should pay you for being on here. If you've not heard of it, I think we've maybe talked about this before, but one of the ways that I found a ton of AWS specific work, because I think I'm always trying to shy away from being a full stack web developer, that's something... I know you have that background, and generally, I found, personally, when freelancing the last even just few months, there's a big discrepancy between full stack web work and cloud DevOps work in terms of expectations, and pay, and bandwidth commitment, and I've really tried to shift more into the cloud work. And one way that I found a ton of clients is the AWS IQ. It's under the radar. I know a lot of people have just never heard of it, and the people who are customers, AWS customers that end up on AWS IQ often don't really know what it is either. They're coming on like, "How do I close my AWS account?" Is maybe the most common request you see, or "Someone call me, I have a billing question." But, there are these diamonds in the rough, those startups that we both really enjoy working for, I found several long term relationship type clients through AWS IQ, and it's now open.

Adam: It was US only for, I guess, its entire existence. I don't even know if it's been around a couple of years, maybe. Now it's open in the UK and France. So that's something I think I will continue beating the drum that there are good opportunities on there, even if there's a lot of noise.

Paul: I had literally never heard... Until you mentioned it. I think that's how we met, you had a tweet thread a couple of moths ago, that's how we first met, and I think you mentioned AWS IQ there. That was the first I'd heard of it. At the time, it was still US only, I think, and I think it's just within the past week or two. You said it's open in the UK and France. So, it's something that I will definitely look out for. One thing, I don't have... You have 12 certifications, is that right? 11 on [crosstalk 00:13:27]? So, I think they have a minimum... You need a certification to get in there.

Adam: You do have to get a certification. So that's the first step, I guess. And then once you have certification, you can get on there and submit proposals. Actually didn't even learn of IQ until I was well under way getting the certs, and I was doing it as a personal challenge, but then I learned that IQ has this big emphasis on cert. So your profile displays this number very prominently, and that is something I've also said quite a lot to people. If you're trying to get in database freelancing, and you're passionate about AWS, you have that experience working on AWS, and you just like the clients, if you're based in the US, and now, UK or France, get the certs, and it's this outsize impact. I don't know how much impact certs have outside of a AWS IQ, but it's this fun little place where they mean a whole lot.

Paul: That's sounds a really good reason. It's something I've never... I've always said would be nice to have, but it's never been front and center of my best way of getting more clients in the future, or you can look at that from a marketing point of view or from a pure, just, your own educational point of view, will it help you do better, and will it help you deliver better client engagements? And I've heard people mixed reports on that. Sometimes you get awareness of some services, which might be nice to use in certain Edge cases, and, I think they're-

Adam: It's actually got a lot of stuff you don't necessarily need.

Paul: And you can pick and choose, I don't think.

Adam: No. Right.

Paul: I think there was talk of creating a serverless specific one, because a lot of the ones that the clients that I'm working with, they're... Never did any AWS Cloud at all before, and they're only coming to it now because of serverless. And so, I wouldn't recommend them to do... Well, I guess I don't know enough about them, but if there wasn't one which was just service focused, a lot of the other stuff would just be extra stuff, which is not really important to do their job.

Adam: I know a whole lot of stuff about Direct Connect, and I can guarantee I'll never use that information. I don't plan to. I went through all the certs, never had a question that I can recall about AppSync, one of my favorite services, very little on the serverless side. But just, for anyone who's joined midway here, we are giving away a couple of cert vouchers speaking on AWS certifications. There will be a couple of associate level certs, cert vouchers through Pearson VUE. We'll be giving those away at the end of the Twitter space. So, back on serverless, I think you've specialized in testing serverless applications. You've even run some workshops, I think, educating... Could you speak to, first, what do those workshops look like? You walk through those.

Paul: Yeah, yeah. Well, even just the motivation for the workshops, in the first place, I did, it must be over a year now, I found my mailing list via LinkedIn, I did a survey of a couple of 100 developers using serverless, what are their main pain points, and monitoring and debugability? So, the [inaudible 00:16:44] came first and second. I grouped them together, I should have separated them, but that was first, and second was testing, and I thought, there were a lot of SaaS apps like Thundra, [Eli-migo 00:16:59], Epsagon type services, which are serving that observability monitoring type, or trying to tackle that problem, but there didn't seem to be anything tackling the testing problem, testing... So, that's my motivation around why to dig into testing. The workshops themselves are based, really, on client work that I've done around different how serverless testing is different. A lot of people come in with expectations of best practice for them for testing based on stacks that they've built in the past, like server based stacks, and they don't all necessarily hold true for serverless apps.

Adam: Could you speak to that? Are there common misconceptions, or... Moving from a traditional app into serverless, how does testing change, and what do you see?

Paul: Well, I guess there's two dimensions, I would say, on which they're different, and we'll dig into each one. So, one is your local versus cloud difference. So, do you test everything on the local developers machine or against cloud? That's one area. And then the other area is, what are the categories of tests that you should be writing for, say, each feature you're building, and what would be the balance, or even defining each individual, you're thinking unit tests, integration tests, and TAN tests? So, those are the two broad dimensions on which it differs, serverless testing differs from traditional software engineering testing. We'll tackle the local remote one first.

Adam: Yeah, go for it.

Paul: I'll say this is still... Serverless is a constantly moving space, and it's opinionated. So, there's no de facto best practice, that's a bugbear of mine. This is what I find to work well for me, so I'll just qualify it like that, because I know folks are very pro local testing, but I'm going to say I'm generally advocating for testing in the cloud. So, even in your local development, your local development workflow, your loop, so you write the code, you write the test, you may do it the other way around like TDD style, that's fine, but you run the test, and I generally say run it against, say, the DynamoDB database on the cloud, or talk to the actual services in the cloud. There is a little bit of network latency there, and the biggest, probably the bigger and time-based aspect of it and speed based aspect is the deploying your changes. So that is... It's still not as fast as local, so you still... Whereas local, it's just on your machine, and it will run, but whereas there is a... You need to deploy it, and then run your test against it, but there are tools that make it easier to do. Serverless Framework has a serverless deploy function, SLS deploy function command.

Paul: I think some might have one. I'm pretty sure CDK did something very recently, they added some sort of [crosstalk 00:20:16] change deployment.

Adam: Where they'll basically just push your Lambda code changes, and not go through the whole cloud formation dance.

Paul: And I know tolls like Serverless Cloud, like Jeremy Daly in the serverless team are building... I've seen beta releases of it. They're tackling that issue. And so, their workflow is, you write the change, so it's on. It's like a hot reload if you're doing front end development, you just pretty much save it and it just deploys in the background within a second or two, it's there, and you could have your tests run against it. So, I think that's the way it's going to go, and I'm advocating now for testing remotely, and putting up with this slightly slowerness, but with the view that it's going to get faster anyway.

Adam: And I will say, this is anecdotally, from my perspective, building out stuff, mostly serverless stuff for clients, I've just forgotten that it's even slower. I think once you've done this development, where you're working in the cloud against the dev stack or something, you just get used to it, and I know on the web front end if I'm building something, which I try not to, but... I'm just never good at it. If I'm building a full stack, the front end and everything, you're used to that hot reload, and you still have that, it's just when you're making API changes or whatever, you've got that extra deploy step. And I imagine that it's coming that people are working on this problem, and I did see, I think, Jeremy post about serverless cloud. I think that evolution of just giving us back what we've maybe forgotten we lost, that's very promising, I think, getting into that. I've seen it now with the CDK, and I think SAM does have something similar, just when it has a hot reload experience.

Paul: I'll mention serverless stack as well, so this is the guys who build in C. So I think they're doing something like a... It's something which I haven't tried, but I really want to try, because it looks really, really nice, like a CDK serverless [crosstalk 00:22:15].

Adam: I know they've got the Lambda reload. It's good stuff. I mean, if you go down the route of, "I'm just going to deploy to the cloud, I'm not going to do local emulation," I don't think it's that bad. I know a lot of people feel like you're just killing the dev experience, and we have these expectations coming from a better dev experience with traditional app architectures where you're running everything locally. For me, personally, I found it goes away pretty quickly. My expectations adapt.

Paul: Yeah, yeah. I guess, the benefit, the reason why I'm saying don't use local, local stuff will still be faster, but the reason... They're not the same, they're not... You'll be testing against a DynamoDb local, I guess, by local stack. It will work, but you have to set it up differently. If they write your code differently, you configure it differently to talk to your local, so there's a slightly different way you set it up. And what will work in your local development environment won't necessarily work when it gets into your CICD environment. So, you'll run into those niche servers, like IMs, the classic example of stuff, which if you're testing against a local emulator, it's not going to be doing anything IM. So, those are, with serverless, the nature of the issues. The types of failures that can happen are a lot more about the integration points between services rather than in the actual body of your code. So, that's good. Moving on to the secondary that I've said; the balancing of the different categories of tests.

Paul: So, I don't know if folks are aware, if you... I think it was Martin Fowler, it could have been even someone else, but Martin Fowler made it famous, the test pyramid with unit tests at the base, the wide base where you have more than, and the middle layer had integration tests, which you have slightly less of them, and the top layer you had like end-to-end tests, which are slow running, so you've lasted them again. So, there was an alternative model, I think it was based... It wasn't specifically for serverless, I think it was based on testing microservices. Some guys at Spotify came up with, they called it the... What was it called? The hexa- ... Was it the Hexagon? I'm losing, I've got it [crosstalk 00:24:43].

Adam: I think I know what you're talking... It's shaped like a hexagon if you widen the integration test.

Paul: So it had unit tests, and what it called... It didn't call them end-to-end tests, it called them something different, but it was pretty much tests. It effectively considered these really long running type end-to-end tests against external services, and unit tests, you had less of those, and in the middle are your integration. The wide part was integration tests where... That was where all the integrations between the actual services that you're writing, and the actual between Lambda and DynamoDb, or between Lambda and EventBridge, or between AppSync and the DynamoDb, whatever integrations you're doing. So those are the areas where you're most likely to get something wrong. It could be some YAML that you've configured wrong. There are good static checking tools for your code, like, say, your TypeScript, or your, I don't know, Python, but probably it has to catch to those type of codes, or less for when you write configuration type stuff. There's a lot more that can go wrong there.

Adam: I've definitely seen this in the last few months, a lot of people I look up to on Twitter, and not just in cloud circles, but web dev circles, it's seems that that's the way things are moving, that it's about integration tests with... That's where you're focusing most of your effort, and then sprinkling in the other types of tests.

Paul: Yeah. I've never really liked mocking anyway, even before serverless. It's like, you have to think... It can be confusing for... A secondary benefit of tests is that it acts as a form of document-... Or a new developers onto the project can come and view them, but then if you're seeing all this mocking setup, I know it's the way you write your code as well, that makes it easier to inject things, or passing these parameters, but if you've got a lot of mocking, sometimes working out what the mock should be is half the effort. You're like... But you need to call the real service in the first place to get the response to be able to mock it, and it's... Just doing that whole mock song and dance, just doing that is a lot of time, just even getting it right in the first place, just for the benefit of having faster, being able to run unit tests without a downstream resource. So, that's another reason for opting more for integration tests.

Adam: So you're just deploying a stack into a test account, it's just exactly like the stack would look when it's deployed into your production account, and you're running those integration tests against live database resources.

Paul: That parity between environments, I think, is very important. Back in the day, we would have had... I used to do a lot of .NET development, so your local development environment would have been totally different. You wouldn't have had HTTPS on your web app, you would have had a single clustered database, rather than a multiple... A proper cluster, you'd have a single node running. So, the difference between environments was huge between your development environment, and any testing environments in production. So the great thing with serverless is that, that delta between each environment is a lot less, so the tests that you're doing in your local development workflow, you're going to get a lot more confidence out of them if they pass, and get through, the lot less is going to get through to production. There will always be stuff that gets bugs that goes through to production, but that's just going to be, you're going to catch them earlier, the closer your development environment is to production.

Adam: And do you have any opinions, or do you have experience with testing in production? I know that's another trendy concept.

Paul: Well, I guess, the likes of the [inaudible 00:28:32] engineering and it's not something that I've really done. I read about it, but I've never been involved in companies really who [inaudible 00:28:43] had enough resources to get to that. I would love to get more into it, and the hindsight-

Adam: I just love the idea of, if I could do away with the idea of a staging environment, and it's just like, everything goes to production, and... But that sounds promising. I don't know if that's what it is, or I'm making that up, but...

Paul: Well, I guess, there's the word testing. I think I've seen testing in production, but also just includes our general monitoring or alerting stuff. I think that would be included under some people's definition of testing in production. So that is absolutely... Get all that set up. You can do it out of the box with CloudWatch. There's alarms, but there's other services like, I think, [Lemi-go 00:29:22], Thundra, for serverless apps, which do that really well.

Adam: There's a new one called Cloudash.

Paul: Oh, yes.

Adam: I hope I'm saying that right. So they're coming on tomorrow, we'll have another show. It's the European time slot, it's earlier in the morning, but I'll have the founders from Cloudash on to talk through that. So that's a new entrant into the monitoring space.

Paul: I got to check that out.

Adam: I've downloaded. I'm a paying customer. Corey Quinn, his review, it sold me. I was on the fence and then Corey said good things and I don't see him praise a lot of things.

Paul: Okay. Yeah, must be good.

Adam: You've got these workshops, or do you have any workshops planned for the future on the serverless testing?

Paul: I've no concrete dates at the minute. So, it probably won't be this year. It'll probably be early next year, or the next one. I'm also writing a book on serverless testing. It has been paused for the last 68 weeks, I think, just for just other... Some are personal commitments I've had, but I'll be back on that writing wagon, hopefully, from October. I'll say, I'll give you a link afterwards for... There's a page where if folks want to sign up for early chapters, I'll hopefully be releasing once they're ready.

Adam: So, that's a good segue that you write a lot. So, you've got your blog, which something like... You've got 100-plus articles at your blog, am I misrepresenting?

Paul: Maybe not quite as much as 100, maybe... I don't know. I've never counted.

Adam: But you've got a bunch of them. However many you have more than I have in terms of blog posts, but then you also have these public notes, and I think this is something... I've recently learned, and I've seen this concept out there, I've seen a few other folks doing it, digital gardening. So, you're putting out all of your thoughts into the public... Well, a lot of your thoughts. Can you share a little bit about how you get started with that?

Paul: Yeah, yeah. Yeah. So, I guess, it's going back to the whole desire... I do strongly believe that writing is a great long term asset building for anybody who wants to share their knowledge, and just to get more people trusting them, outside of just having to rely on people referring them, that sort of thing. So, I find there's a lot of friction, though, in doing blog posts all the time. I find, you have to... There's a lot of... Especially when you're starting, this will let you think you've still a lot of polishing... Especially code-based articles, which are very technical. I did a mix of higher level opinionated pieces, I guess, and actual technical tutorials, this is how you should go about doing something. The latter takes a lot of research, and you have to get the code right, otherwise, you get a lot of questions from people, "This didn't work for me."

Adam: You got to give examples, and that's a whole thing.

Paul: The notes came about as, I want to be publishing stuff regularly, but those type of articles are just a big, big effort to do, and I'm not going to be able to do that as frequently as they want. So, the notes were stuff like, I was thinking in my day to day client work, I get asked a lot of questions about things, and there's lots of recurring themes, even some which aren't recurring, they're just the first time, and I may not be able to give the client an answer straightaway, so I just go away and write it up as a note, and I use Obsidian, which is a really good tool. And, it has a publish feature, which you can publish a subset of your notes. So, I just started doing that around just even articles. I was reading people like say, some of the Off-by-none newsletters, or one of the cloud newsletters, or even just general software engineering newsletters, or articles I'd read, take some notes on that, and just put them in a folder, which I may or may not turn into longer form blog posts, but make them public. Just to see if anybody wants to dive in.

Adam: I've enjoyed diving in, and I think your notes have made me look a lot smarter than I am in a lot of contexts, where a client has a question, I can look up Paul's public brain, and get the answer.

Paul: A lot of it is totally... If you read, it's like the sentence just stops midway, because it's not a polished blog post. One of my daughters would run into my room, and I would get called away, and I would forget that there's a half finished sentence there, and then, I have a weekly schedule where I'd just do a quick review of what's new, publish them without any... The review process is not detailed, so I just publish thoughts. So, sorry to anybody who's like, "What's he talking about here? Is he totally confused?" But that's part of the reason why I can publish them more frequently, because we don't go through that, through a vigorous step.

Adam: I think I've told you before, aside from the information and just seeing you lay out all that information that you maybe wouldn't have otherwise in a blog post, it's nice just to read some of your questions that you ask yourself, and knowing that these are questions I've had, and that someone else found those same sticking points, or they're thinking through things the same way. It's validation when you're trying to solve a problem, when you see someone else that solved it, or is in the process.

Paul: I think questions are really powerful way of learning, and generally, I tend to think a lot of especially, AWS docs, is very solution oriented. They don't really deal with the problem, the bigger problem that's been solved here, and it's like, just putting the questions or how it would work in certain contexts, or using something in a different way. So, these are often, as I said, based on client projects that I'm working on, me thinking through what they might need to consider if they're going to use... Let me give an example. This isn't the totally serverless one, but I was doing a thing last week of using step functions with ECS on a container, a Fargate container within ECS, and was... That was totally new, you had to do a lot of research, but just noting down all the questions, how would I.... Just the different integration points, and you end up finding I needed to use... You can use S3 for files, and you need to use EFS, I think, file store as... And going down this rabbit hole of extra services that I made in the [inaudible 00:35:42] on. It's just detailing the question in the first place, it gives me...

Paul: I didn't need to pick it up at the time as well, so that the questions act as a... I guess, they act as a picking up point for whenever I just have to think about decision, I don't have to actually deliver it yet. So, I can then come back to it, revisit it, and flesh out the answers to the questions.

Adam: And do you ever find that... You're writing the notes, you've got things that you end up turning into blog posts, and then you're working on a book, are you able to overlap? Is all that writing separate [crosstalk 00:36:18]?

Paul: Yeah, yeah, yeah, I try... Well, that was the idea of taking the notes, is, some of them, internally, have got a bit nerdy. There's different categories of notes that you can write, is [crosstalk 00:36:27]-

Adam: I like the nerdy stuff, so [crosstalk 00:36:29].

Paul: But it's like, the whole idea of a folder of just... It's not drafts, it's seeds of ideas of blog posts, so just working on them slowly, with no saying... Occasionally I do... I say, I need to write a blog post about this specific article to help some... If I was... Like when I was doing the testing workshop, I deliberately wanted to publish to a certain schedule. I don't generally do that. So, just starting lots of little drafts, with no view to be in a blog post, just really typed around a specific question, or a specific concept, and keep them tight, and then once the idea will form for an article, just pulling from different notes into a proper article. So yeah, it definitely feeds into blog posts, and also to... I've a mailing list as well, so sending out emails to subscribers.

Adam: And I get your newsletter. So, you've read a newsletter as well. I'm going to ask you...

Paul: [crosstalk 00:37:31] blog. It's generally what I'm writing them blog posts, is generally just sharing what I have in the blog posts.

Adam: Okay. So there's a bit of, do it once, share it in different ways. So, for someone like me, I want you to encourage me here, Paul, I've considered starting a blog, or just writing at all in some form, forever, basically, and it's always... There's always something else that's more pressing. Do you recall those emotions, those feelings of, "I'm never going to get to it," and then tell me how you went from there to writing in all these different forms, and give me some pointers, I guess?

Paul: Yeah. Yeah. On your first question, I absolutely did feel like that, especially when you're brought in both. If you're doing client work five days a week, or full-time employment, the very first thing is finding the time for it. So, I was lucky that I was able to... I started to try to pull back my client days to keep days dedicated for what I call business development, just generally writing. So, that was one way of doing it. So, just blocking with the time, or it could be just blocking off an hour in the mornings, especially now folks can work from home, so nobody's going to possibly block off an hour early in the morning, whatever you find... You need to find whatever your most energetic time to write. Sometimes in the evening, it's just not... Doesn't work for me. There's the time aspect of it, and then just the actual, what do you write about? That's the big thing. And, there's the, what do you write about? And, what I'm very... People are afraid of putting stuff out there.

Adam: Sure. That's scary.

Paul: Yeah, but it's just [crosstalk 00:39:14]-

Adam: Because if it's written down, anyone that reads it can tear it apart. If I said something stupid right here live, there's like, some people will hear it, but I don't know. It's intimidating.

Paul: There's always going to be somebody angry on the internet, at you.

Adam: Sure. Yeah. So, that's something I hope to get into. I've always had a reason I'm going to... Whatever. I got to figure out how to make a blog. I don't want to use WordPress or whatever. All the excuses I can come up with.

Paul: Now, there's tools like, I've used Gatsby, but there's even... I've heard people say good things about... Is it Eleventy? I think it's a more modern version. So, keep it simple, keep it as markdown, keep its static, Jamstack, from the technical point of view, but the big thing is, because you're a developer, you'll obsess in those things, don't just pick something and use the default, and the main thing you're doing is writing. So, the writing is the big thing, it's not the getting it looking nice, and using really nice text styles, it's getting it published. I think, if you challenge yourself like that, that's [inaudible 00:40:18] how you do it.

Adam: That goes against my very nature, Paul. This audio show is... I should have focused a lot on having, I don't know, some questions and some things that we're going to discuss, and I put that off the entire time for the last week, completely off. I kept saying I was going to have questions for you, we'll walk through that stuff. Instead, I spent a whole lot of time worrying about the audio, worrying about our Zoom call recording. It's hard to prioritize-

Paul: It's hard not to do that, especially when you're a techie by nature. For sure. But just the last thing to say on writing, treat writing as for yourself, not for, necessarily, the audience. You can, as a way of clarifying your own thoughts. So, even if you don't intend to be a freelancer, or get clients, if you just want to work as just, in a permanent employment, and just being able to explain concepts to your colleagues by writing it down, and it clarifies your own opinions on things, and the way you would explain things to other people. I find in client calls, if I've written about something, it's a lot easier to then explain it to them without making a mess of it, and you know how it gets.

Adam: That makes sense. And that's so much of freelancing, I feel like, getting back to that. I feel like getting on the phone with the client, and making them feel comfortable that you're the person that can help them solve their problems, in my experience, that's why people choose or don't choose you. It doesn't generally come down to, I don't know, facts about your career, did they get on the phone with you and feel good about that conversation? So, the extent that you're more confident because you wrote it down, I think, that would pay dividends.

Paul: Yeah. Yeah, it definitely does. I think there's a minimum bar of technical skills that get you so far in your career, but I think just writing and speaking, they're hard. I'm naturally not good at it, and I haven't been on a lot of podcasts, and the first few hosts, they will say, "This guy is really nervous," and it was hard to be, and it was like, it's something you definitely get better at with practice, both writing and speaking.

Adam: There were some other questions that I get a lot just on the freelancing space. Do you want to talk at all about pricing or billing freelance work? I know it's just a hot topic, [crosstalk 00:42:44] a lot.

Paul: Yeah, yeah, for sure. It's something which is on my mind, a lot of it as well, it's just different. I guess, the way I... I've done a total mixture of different types of ways billing over the years from initial, by recruiters contractors. So that was... Over here in Ireland, in the UK, it's daily rate rather than hourly rate. That's just the cultural way it is, but it's effectively time based. So, that was how I did it for a long time, which is, when you're working for a single client for a long time, with no actual project based goal, did work towards that, works for that model, but I'm trying not to do that. Well, I am not doing that now, so I only do fixed price based project with a fixed scope. Because I just find it focuses me more, and I'm incentivized to get stuff done for the client, whereas if you're working at a daily rates or an hourly rate, if the incentives are misaligned, you're going to be... Takes, I think, longer, but, "I'm getting paid anyway, so there's no rush here." So, that's not really going to work. It focuses my mind if I know like, this both I'm getting the scope down now. That's the hard part. So getting your scope down.

Adam: But that forces out a lot of... It gets ahead of things that can become challenging down the line. If you have to be forced to iron out scope with them front, you learn a lot about the client, and their problems, but it is hard. The only times I ever do hourly billing, or when there's no way to really form coherent thoughts around a scope, and they just need help, it's an emergency or whatever. But I definitely prefer... Go ahead.

Paul: I think just where it does make sense is, as a freelancer, it makes sense if... I do retainer based. I have clients who don't actually do delivery. I don't have actual deliverables to do, but they have new projects. They're an agency, they have new projects starting every month, definitely every month, so they have new questions they ask me related to architecture, or how would you do this for this new project we have? So they want that ability to ask you questions. So that's where like a monthly based fee, I guess, makes sense. But for actual concrete deliverables, I just trying to get away from it, but it's not they've done thing. Even this week, I have had lots of... I get leads on LinkedIn just around asking what's your rate and stuff, which... That's just the way it is. I understand why people do that, because that's still the dominant way freelance business is done still. But it's not the clients interest, and it's not in your interest to do it, so I've just made the decision that I'm only going to do it like that.

Adam: And you've experimented with productizing your services. Is that the right way to put it?

Paul: Yeah, yeah. So, for some things, it makes really clear sense. I have a consulting for somebody just doesn't want anything more, they just have a load of specific questions they want to ask, pay for a call, that's fine, but more a common service that I've done is, at the start of a new project, people want to start using serverless, they've got the project idea, so I work with them on a roadmap session, which is a fixed scope over a week or so, a couple of calls, and I'd write up a report, then we would have a Q&A session afterwards. That fixed scope, architectural design, and they try to offer for published fixed prices, and those repeatable type similar engagements definitely worth... I've decided to put public prices on my website for those. I don't think... Very few people do that, which is... But it cuts down on the... The people, the leads that I do get know what to expect, and it's like, that's what, that's what I do. I'm experimenting with a new one. I haven't actually sold any of this yet, but it is going in and setting up...

Paul: It's something I've done as part of other client work, but in bigger engagements going in, similar to what you do, Adam, just going in around setting up with AWS organizations and multi-account set up for all the different environments, and getting a CICD pipeline in place, and then doing an application spike just with the initial services. Not starting on actual feature development, but say, getting Cognito set up, if they're using Cognito, getting AppSync or API Gateway set up, and everything, talking to each other, and a couple under the testing framework all in place. So you've got your commands you can run for all, running all the different types of tests and deploying through all the environments. So, I'm working on, called it serverless launchpad service to just do all that for clients, but it's only a new thing. I haven't sold any of it yet as a standalone thing, but I'm just working on who to best target it to. Startups, I think, would benefit most from it.

Adam: Yeah. So, you're short of seeding their whole... The repo. You're handing them, at the end of it, "Here is a tied-together repo that the code integrates with the infrastructure." Is that accurate?

Paul: Yeah, it's the repOp and the DevOps side as well, because you... A lot of these startups only have the application developer side, so they could probably do one, they could probably build out, and they can definitely start building the code, but having that... I have a standard structure, which works well for... It allows you to grow, so if you want to move into microservices, this structure would work well for that, but having the deployment pipelines in place already ahead of time, a lot of people leave that to later. They've built out, they [inaudible 00:48:55] manual deployment for a long time. Bring folks like you in to [inaudible 00:48:58], and then retrofit, as he said, CICD pipeline at a later stage. So, getting that in from the start, optimizes for speed time-to-market for folks.

Adam: So we actually did have a question. Somebody sent me a DM, and just asked, what sort of projects are the bread and butter of AWS freelance? We hit on this maybe at the beginning, but do you want to... Is there an ideal project?

Paul: Yeah. Well, for me, no. I generally turn down anything that's not some sort of serverless aspect. I know about VPCs and network stuff, and I've done it in the past, but I just don't want to do it. So, there are, but there's a load of work in just doing those sort of... Like IM, and just getting those things all set up in place for general EC2 based infrastructure, because it is generally a lot more complicated. So, generally, AWS, that's my impression, that those type of projects. Maybe, Adam, with your... You're on AWS IQ, that may be a good...

Adam: Yeah. So, as compared to web development, I would say freelance web stuff, which I've had some experience with, is a lot more consistent. I feel like the projects, as you go from project to project, there's a lot more overlap. I mean, the problem space changes, like the content, what you're building an app to solve, those problems change, but the type of work looks the same. You can use the same stack where you're tweaking your stack each project. Cloud work, for me, has felt way more all over the place, and maybe that's... I'm not narrowing enough, I'm not niching down, and I'm not refusing the VPC stuff. I much prefer working on a greenfield serverless project, but I think the types of work I've done, when I've worked AWS freelance stuff, it's been all over the place. So it's, in some cases, building out isolated internal tools that are serverless, it's doing security work. So setting up a security monitoring account, and all of the various security hub integrated services, and GuardDuty and Macie, and whatever. I've had a few projects doing retroactive CICD, or retroactive infrastructure as code. It's all over the place. I don't know that... And then there's also the web stuff that overlaps with...

Adam: Somebody wants to build out a web application that you recommend, you go the serverless route, and the API for that is very AWS Cloud native, AppSync, or API Gateway and DynamoDb, but you're also building the front end. I've done a few of those projects. I end up regretting every time I take on a web front end, because I spend so much more time doing web work. Maybe someone else would have the opposite experience, but for me, I feel like the cloud work is so much more... It's like, there's a lot less expectation, and when there's a UI, when there's a front end that they're evaluating, there's just so many ways you can either go the wrong way, like make a bad UX choice, or just go a way that they don't prefer. If it's like cloud work, it's so much more black and white in my experience.

Paul: Yeah, yeah. The subjectiveness of any front end development, it's very hard. You're like, "Can you tweak this? Can you change the color?" It's like [crosstalk 00:52:35] the backend code, it's just-

Adam: Exactly. Button colors in AWS.

Paul: That's why it's a... I have done a lot of full stack stuff, and I do like... I still, I do like doing front end, but just as play projects now, try to... It's more... Going back to even the billing conversation we had, because the backend cloud work is more... You can scope it better. You can more confidently predict how much effort it will take you to deliver it, compared to front end web stuff, because, the features as [inaudible 00:53:07], they need to be iterated upon a lot more on the front end.

Adam: Yeah. My wife makes fun of me, because I'll complain about, I took on more web work, and I'm just so slow, but then she knows every side project, everything I end up doing with my free time is building stuff with modern front end technologies. So, she doesn't... And I don't really know if I have a good answer for why I enjoy playing with those things, and staying up-to-date with them, but in a paid consulting or contracting standpoint, it's just been bad news for me. I just spend so much more time. And maybe that's just my personality, maybe it's my skill set. But, I guess to get back to the question, for me, I don't know if there is a bread and butter. I have a much smaller sample size than Paul, in terms of being freelance with AWS, but I feel like if I've done a couple dozen projects over these four or five months, maybe I have two or three repeat type projects, and then the rest of it's all over the place. Is there anything else you wanted to share while we're on the space?

Paul: I don't think so. I'm just excited to hear the rest of your guests. I think I see a few on listening earlier. It's good. That's a good lineup you have. So, excited to see what else is going to come from AWS FM.

Adam: I'm super excited just to get on and learn things from all these people that I admire, and then if someone else can learn those same things, I know that that's the whole point of doing this publicly. So, on that note, tomorrow, we've got a call with the Cloudash founders from Steady, and then next week, we've got Boris Tain and Alex Debris, I think he's on the space. We've got guests three times a week for the next few weeks. It's an experiment. We'll see how it goes. Thank you so much, Paul, for joining and just sharing all of your insights, and thanks everyone that came on to listen. It's hard to keep track of the space. Paul and I are looking at each other talking on a Zoom call here, so thank you to everyone that took the time out and joined us. So, everyone knows where to find... You can find Paul on twitter @paulswail.

Paul: Yes, that's right.

Adam: And your website is serverlessfirst.com. Anywhere else you'd like to point people?

Paul: No, I think those are the main two. Everyone else has linked too, from there.

Adam: Great. So thank you again for joining, and we'll have to have you on again later when I get better at this.

Paul: Well, great. Thank you very much.

Adam: Thanks.