Ian McKay: Building CLI Tools to Make AWS Better, More Thoughts on the CDK, and Tight Bonds in the Australian AWS Community

About Ian

Ian is the Cloud Lead at Kablamo, a cloud product development and data consultancy specializing in building applications native to the AWS cloud. He is usually focused on cloud architecture, CI/CD and security, but is always trying out the latest AWS services. He also previously managed infrastructure at Stan, an Australian streaming service.

Between helping clients he loves the chance to build open-source projects with a focus on AWS automation and tooling. Ian built and maintains both the Former2 and Console Recorder for AWS projects, which help developers author Infrastructure as Code templates (such as CloudFormation) from existing resources or while in the AWS Management Console.

Ian also enjoys speaking at meetups, co-hosting podcasts, engaging with the community on Slack, and posting his latest experiences within AWS on his blog.

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

Transcript

Adam: Hey, everyone. Welcome to AWS-FM, a live audio show with guests from around the AWS community. I'm your host, Adam Elmore, and today, I'm joined by Ian McKay. Hi, Ian.

Ian: Howdy. How are you doing?

Adam: I'm doing well. So, I've started most of these episodes the same way, and I want to start the same way with you. And that is, just give us your story, your background, getting into technology, getting into the cloud. Just all of it.

Ian: Yeah. Awesome. So, I got into technology pretty early on, in my university degree. I went into applied as a Java developer, actually. And I'm pretty sure since then, I've never touched Java again, thankfully. I walked into the interview and I said, "Look, I want to have this Java job. This is what I'm doing in university and things like that." But I also talked about, I'm doing these server management on the side. I'm working with VPSs online, I'm doing server configuration, things like that. And what turned out to be my future boss stood up to be, pretty frank, he's like, "I don't think the Java opportunity is good for you. I think we can do you better. I think we can give you this new DevOps position as a DevOps engineer." And I quietly said, "Oh yeah, that sounds great." Well, in the back of my head, I'm going what's DevOps? What does that actually mean? I've never heard that term before. But I quickly found out.

Ian: And so, I joined a software development company and started to configure their server. Take ownership of a small server room that's still managing the on premises services in classic ESXi, VMware style management. And I did that for a while and tried to sort of learn the ropes in technology. It was really good platform to kind of start off on. This is in Sydney, Australia, of course. And at this point AWS wasn't even in the region, but as it landed towards the end of my time there. I was figuring out that this is an interesting platform.

Ian: And I did my first prototype on it, as soon as it landed is in the Sydney region. And that was probably eight years ago now. So I did my little sales presentation, this was on elastic beans stalk. It was so new to Sydney at the time that it failed for half of the configurations, which is give me a flat 500. And I reach out to support, "I'm like, I don't know how to configure this thing." It's like, it's not, you it's us. Don't get that much. Don't get those sort of configuration issues anymore. So that was really interesting.

Adam: Yeah, I'd love to hear more about sort of your perspective, I think from that side of the world, because it is very interesting. We were talking before the call, it's like 5:00 AM my time and it's 9:00 PM your time. It's just kind of wild when you're kind of on the same call at the same time, but it's such a different time of day. And I'm sure your experience with AWS is shaped as well by that. So you're currently at Kablamo. Did I say that right?

Ian: That's right. Yep. Yeah. So Kablamo is a cloud consultancy. They're an AWS partner and they basically build AWS native software obligations and I'm the cloud lead there, officially.

Adam: Yeah and I wanted to kind of talk about your role in terms of like, besides the title, like what you do day to day there at Kablamo.

Ian: I basically do end to end for a software development package. So that might be talking to customers, selling companies, selling our skill sets and then going into architecture. Saying, this is how we will design it in a modern practice. Here's the compromises you're going to make in cost and security and things like that. And if that's okay, then we'll go into implementation. Even though I'm a Dell Ops engineer, I'll tend to jump into the backend and do some coding every time I get a chance and then I'll do that all the way post implementation support. So making sure that things are running smoothly, doing any bug fixes or things like that. And yeah, making sure that our customers are happy. So it's really nice to have that full end to end spectrum.

Adam: It sounds to me like you touch more AWS services then maybe some of my recent guests. It feels like I've had a string of sort of serverless specific guests that are really into that space. Working at a partner like that, an APN partner. Is it less specific? Is it sort of you're using a lot of different types of solutions and technologies at AWS?

Ian: Yeah. We get to touch a lot more than the standard practice. If you were at a single ISB or a SaaS or something like that, you to have a broad range. So we'll touch all the traditional EC2 hosting. We'll do containerization on both ECS or EKS. And then, our preference is still to develop native surplus architectures and things like that, but sometimes that's just not possible or it could be possible, but not for the budget that someone might want.

Adam: Yeah, no, that's, that makes sense. And I guess as part of your work there at Kablamo, you were recognized as an APN Ambassador. Could you speak a little bit about that? I'm not sure if I've had any ambassadors on the show yet. Could you kind of speak about that whole program and, and what that looks like for you?

Ian: Yeah, sure thing. You definitely have had a couple of ambassadors, actually, Ben Breeves is an ambassador. Broan Dell is an ambassador. And, but what that means is that we work for AWS partners and then we were well recognized for our contributions in that space. So you can't be an APN or an Amazon partner network ambassador without working for a, I think it's an advanced here and above partner. So you have to be talking to client, to customers and things like that. And that is a great community because it's one of those very small times that I get to talk to people who have the same passion as me. And we can really jive on very deep technical topics. That, that crew tends to always go out for a few beers before we kind of do the official meeting. And that always turns into a really interesting story time.

Adam: I've had Luke van Dockers go on, he talked about going from a partner to an AWS customer and that maybe AWS it's a different treatment you get. So is it sort of a close band of, I guess his implication was that it's harder to be at a partner, maybe less favorable treatment from AWS. Is that sort of a comradery that you've built up or do you even perceive it that way?

Ian: You can get that way. AWS and even partners are always thinking about the customer. And so we're always gelling in a certain way, but there's this duality where even though Amazon are working with us, they can come in as a competitor sometimes. So there are some engagements that we might be coming in on, and there's a prototyping team from AWS in the same...

Adam: Oh, interesting.

Ian: Running, I guess, for a specific project. So there's that weird duality that you kind of have to hit sometimes, which is an interesting problem that I'm sure not a lot of people have.

Adam: Yeah. It's the other side of the customer obsession. If you're not the customer, then sometimes you can be in the way of that obsession, I guess. And, and you mentioned sort of a band sort of a comradery there with other partner folks and ambassadors. Do you also sort of have a regional? I feel like there's something about the Australian AWS heroes that you guys have kind of a closer knit community. Is that just me assuming so, or is it, do you feel like you're in your own kind of corner of the world there?

Ian: We definitely are in sort of one corner, the ring. As of the last time we checked, we are just still the most person full region. We still have the most members within the NZ region. North America is catching up, but I think we're still on top, and some of that is really because of the evolution of the program. So we can have an earlier program that was called cloud warriors and they changed that up. But, ah, yeah, it's been a very long tail program. I've only been in it for four years now, but it's been going on for quite some time here in the Nzed region.

Adam: Yeah. The, it seems like you guys are just a pretty close group from interacting with each of you. You all bring each other up a lot. So I want to get into some of your sort of open source efforts. And I said before the call, I feel like I shouldn't have you on here. You should be maintaining your mini open source projects. And I don't know how you have time to do anything really, but I want to dive into some of those and maybe starting with, I've seen all of the projects on your GitHub, I've dove into most of them. I'm sure I've missed some of them. Is there like a project that is your primary focus? Is it Former2? Is it something else?

Ian: Yeah, I think the project that I spent the most time on right now is Former2. I've spent the evolution of this is pretty linear. So I could probably go through my major projects one by one.

Adam: Oh, I would love that. I feel like I'm missing something.

Ian: That kind of starts with a console recorder and console recorder was a frustrated project, I guess. It came out of me looking at how to try and describe a Boto call. I'm pretty sure it was me alive and creating a channel and the Boto docs for it were six pages long. And I spent an hour just doing one single call. And I was like, there's got to be a better way to do this. I can do this in the console. I can kind of figure out what the options are, but not quite what's going on. And I'd already had experience with things like robotic process automation, which is recording of the things that happen on your PC in browser specifically. And so I already had that experience to look at the network calls that AWS console is making.

Ian: And I looked at those calls and it's like, this is really detailed. Let's make this into a thing. And so I started to make console recorder, which takes the calls that you make in the AWS console and converts them into a bunch of different outputs. And those outputs might be Boto3 or the JavaScript SDK or clarification or Terraform and things like that. And it's really helpful to not only understand what's going on from the console side of the range, but also to understand the services themselves and how the console does what it does to gather the data that it needs. It goes, you look at the, an EC2 launch wizard and there are so many different get calls to understand what the options that you can choose. That it's fantastic, how much work goes into that, that people don't really see or take advantage of.

Adam: Yeah. And it's something that like most of your projects or things I've wished existed and somehow didn't know, I guess like if I'm out there Googling and I'm not able to find this kind of stuff, what's the best way to track your work or just more broadly projects within the AWS space? Like, I feel like I've been under a rock. Is that unique to me? Or is anyone else sort of expressed, oh, I didn't know. You'd made that.

Ian: Yeah. It's interesting. My work is primarily on my GitHub and I advertise that usually just on my Twitter and things like that. And so generally how that comes out is that we talk about these projects with our small knit communities. And then, you know, it'll get picked up by some of the newsletters. Things like what Cory Quinn is doing or things like what we're talking about right now in these podcasts. And after that, some people start to see what's going on. So that's kind of how they come out.

Adam: I think I've just been living under a rock. I think I'm just, I've not been active in the community enough until pretty recently, and I'm playing catch, but iamlive, that's one that I literally, I told Rowan, I had a Trello card that was like, I have a bunch of cards of ideas of things I wish existed. And like maybe someday I'll build them. And I was so naive to think I would build, iamlive after I've dug into what you've done and how much mapping is actually involved. And I'd like to hear about that project as well. You've got the mapping project, which is open source, the kind of powers iamlive. Could you dive into that one a little bit for me?

Ian: Yeah, absolutely. So iamlive is actually not what I intended to build straight off the bat, surprisingly enough. What I was trying to, to build a, something that I'm working on right now, but I'm actually taking a break because it's hurting my head a little, but essentially how iamlive works is that it generates iampolicies from the AWS calls that you make locally. And that was originally using a nice feature or debugging tool. That's kind of baked into the CLI client inside monitoring. And so what client side monitoring does basically says, oh, okay, let's make this request using the usual endpoints, but let's also just spawn off this little packet for monitoring and debugging purposes. And that contains things like the action that you're making the service that you're making it to.

Ian: And so what iamlive does is pick those up and say, okay, with these sort of calls, this is the iamoutputs that, that really kind of expects. And then later I did a more advanced version where it uses a sort of a man in the middle HBS proxy that's locally. So because I never want to touch that sort of material, but you run it locally. And it basically just intercepts that traffic. And so to actually make that I built my own little custom tool to start the mapping between what a AWS service call does and what the commission is that maps to it. And that was approach desk that took me probably about three months to actually do. And similarly console recorder and form two are also just huge mappings. So they took a similar amount of time to sort of map between, in those cases, the console calls or inform2 case the SDK calls to the various infrastructures codes.

Ian: So I kind of like that though. That's one of those things where it's just, I do enjoy doing that and understanding the challenges and I learn a lot from it as well. I learn about new SDK functions that I've never seen before or weird ARNs, which I did a whole [inaudible 00:00:14:10] on because it was just so much craziness in that space.

Adam: Yeah. I feel like you've seen more of the internals than the average person with those projects. You've had to dive into some of the stuff that makes your brain hurt. I'm sure.

Ian: It's pretty wild.

Adam: Could you share anything about what you're working on now? Is it sort of under wraps? Is it stealth?

Ian: Yeah, sure. So the thing I'm working on right now is a suite of tools and it's called iamfast. And what that's trying to do is like iamlive generate, iampolicies, but instead of doing that from the calls that are being made live on your PC, for example, it's actually trying to look at application code. And so it uses a technological construct called abstract syntax trees, which is kind of like the tokenization and how a compiler might look at a piece of code. And goes through them and looks for patterns and heuristics for SDK calls, even to the point where it's remembering what variables were declared of your on ins sequence and then applying them to the SDK call. And so my ultimate goal here is to go, instead of going building out, let's say a Sam application serverless and designing your application and then going in and figuring out what all the iampolicies were. My ultimate goal is just to go SIM, deploy, dash dash, fix my IAM.

Ian: And what they'll do is just basically go through the application code, find all the SDK mappings and then write at least privilege piece of IAM policy for your application. I don't think this is something that we, as the developers should be responsible for. I think we have the knowhow to figure that out from the information that we have. So let's do it.

Adam: I love it. The impact that could have on the broader community, that's sort of creating that pit of success. Yeah. For, for least privilege. It's really cool stuff. I want to dive into infrastructure is code a little bit. I know that's something your sort of partial to. And I think the first question I have for you is should I ever use the CDK? Cause I feel like I came into starting this show, like as a CDK fan and I've had guests kind of like several of them say maybe think of it a little differently. Could you just share like maybe your thoughts on the space, just all of the infrastructure is code tools that are available and then specifically like is the CDK okay?

Ian: Oh, I think we're about to lose half the viewership. I don't personally think that the CDK is right for my use case. It's definitely right for a subset of people, especially those that are coming from a development background and like those constructs, but for the that don't like CDK, they usually have the same response that I'm about to give is that it's not declarative. That imperative code that is not guaranteed to output in the same way. And that doesn't really potentially have the right exactness to it that you might want is always going to be there. And I think there's some other issues with the way that CDK itself was implemented. I don't personally believe that their opinionated rules and high level constructs were done very well. And even when they weren't done well, they have no concept of versioning.

Ian: So when an opinion change, which does happen over time within the AWS ecosystem, there's no real way to communicate that or to version those opinions within the CDK constructs concept. That's kind of the issue that I have with it. Not to mention the fact that because it is a programming language that you're using, you sometimes have this mismatch between the actual programming language that's used to do your CDK. So CDK is now out for five or six different languages. How do you then cross between those programming is that other people might be used to, especially within different organizations. So myself as a partner, I go into organizations and one might be doing CDK with Java, but then the next one might be doing it with JavaScript or Python or something like that. And so it can get tedious and that's both...

Adam: It may feel like a hot take, but I feel like on this show, that's sort of what everyone has been saying. I think while you were sleeping, if I have the time zones right last night while you maybe were sleeping, Ben Kehoe said a lot of the same things and we had Ben Brits, who's on the call here, say similar things on the show. So I guess, do you recommend, is it just cloud formation or are there other tools, third party tools, anything else that on the infrastructures code side, do you like to leverage?

Ian: Well, I personally use cloudformation, but I think Terraform is equally as good in the space. Yes. It has those various minor issues with state management, but I think they're solved issues. And so, yeah, I think that's an equally valid option, but I personally like rule cloud formation.

Adam: I'll have to get someone from the CDK team or someone who's a big fan to come on and kind of balance the debate here because I feel like I've had a lot of the same opinions. I think I must have just slipped into some kind of pattern with the guests I was bringing on the show. So, testing in the cloud versus testing locally, maybe that's just becoming consensus, but I've had that a lot. We've got Brian La Rue on Tuesday who will, will finally bring the other side of that argument. So I might have to get like Eli from the CDK team, somebody to come on and, and make the case.

Ian: It's probably a bias there. I think a lot of us are really big power users and realistically we don't want other people's opinions. We want our own opinions because we want to do special things and crazy things and things that might not be very necessarily AWS friendly.

Adam: Yeah, yeah, yeah.

Ian: At times.

Adam: So kind of going back to your open source work, I guess one of the questions I have when I look at the body of work and the things that you're doing, my main question is sort of what motivates that work and sort of all of the effort you've taken on to maintain those projects. Are you scratching your own itch or are there other motivations there for you?

Ian: A lot of it is really, like I said, born out of frustration. So I want to solve a problem that problem's solved and I think I can do a better job than, than nothing that's out there. Sometimes it's based on my experience with consulting and what customers are seeing and their issues. And that could kind of drive how I do some of these issue, these projects, but in the end, it's really just, I'm frustrated with an issue. I'm going to go fix it.

Adam: Yeah, no, that makes sense. I feel like we've just touched on a couple of them, but there are so many permissions.cloud. Was there a former one or is that sort of the AWS console recorder?

Ian: Yeah. So Former2 is born out of the Amazon tool, which is called cloud former and I made it significantly different enough. So I wouldn't get the AWS goons sought on me, but cloudformer was terrible. It was a hosted image effectively, just an AMI. It only supported about 40 different resource types. Only put in J cert. It didn't have cross referencing. It really had a lot of different issues with it. After about a year or two of Former2 being out and that being, not to do my own horn, but far superior than what was out there. They just went, no, we're going to deprecate this outright. And so that was nice validation for what was, what was going on there.

Adam: I feel like there's a lot of third party tooling that people are building out and a lot of it open source that sort of fills in and smooths out the rough edges. It's really nice to see the AWS community is just really fantastic. And I just, I guess want to thank you on behalf of the community for all of your effort there, because I know that's not a trivial thing to maintain that many projects and to contribute that much to the community. I want to get into some kind of rapid fire questions, and then we are going to play a couple of games on the show here. So these are questions I've kind of been asking everybody just getting kind of a general sense of each person that comes on the show. The first one is, do you have any role models, any people that sort of inspired you throughout your tech career?

Ian: Yeah, there's been a few. Right now in the AWS space, to be honest, the council of Bens is really cool. So Ben Brits, Ben Kehoe, they're really influential to me. And that's really in the core AWS space and people obviously like Corey Quinn are really dominating in that industry of showing AWS that they're not this big monolith. They can make mistakes and they are con consistently fallible.

Adam: Consistently fallible.

Ian: Yeah. And there's definitely people in the security space that I admire as well. So people like Scott Piper or people like Canne Beday. So those people are, are really fantastic. And they're really passionate about secure environments in AWS and thinking about what good looks like.

Adam: Do you have a favorite AWS service?

Ian: AWS cloudformation by far.

Adam: Oh, look at that. So I don't know if anyone has definitively just answered that question. It's sort of like labored over it. Do you have a least favorite service?

Ian: CodeCommit.

Adam: CodeCommit. Yeah. Does, I mean, does anybody use CodeCommit? Honestly, I'd like to hear from anyone listening to this.

Ian: Not anymore. Not, not anymore.

Adam: People had a bad experience.

Ian: I've banned people from that. No, it's terrible. I think when you start to slow down developers in their authorings phase, I think you've done a terrible job. And so, yeah, I think AWS really needs to pick up their game there because that's not when we should be slowing down developers at all.

Adam: And I kind of want to pick at this a little bit, because this is sort of an underlying theme that I feel like it is there just an issue with all AWS services in terms of visibility. I feel like there are these third party tools Clouddash, this sort of like getting cloud watch logs into your local machine and just easier to navigate than the console. And you've got DynoBase for working with Dyno DB tables. I wonder like, is the problem that, and I feel CodeCommit and really the whole code pipeline, suite of tools. The biggest flaw to me is that like, it's just inconvenient to go find log output or whatever about what's going on when something breaks down in the pipeline or whatever. Is that the issue? Is it just visibility in the console just sucks. And switching accounts and regions and everything is just painful.

Ian: Oh yeah. I think everything, everyone knows that the consult could be better and should be better. Part of it, I think is really that AWS needs to operate a scale where they appease everyone equally. And that means they're an expert at nothing.

Adam: There needs to be like a, I don't know, like you're a consulting partner. This is your view of AWS. And, it's different. Sort of like multimedia tools on like Mac or PC where you've got like different workspace views, like I'm editing, or I'm doing this. It's like a different view of it. This kind of right now, it's all one vanilla experience. I'm just sort of brainstorming here with you trying to figure out what is the root cause of the issue here.

Ian: Absolutely.

Adam: But I definitely feel like anything happening in AWS that you have to go to the console just feels like too much friction. And just trying to kind of unpack what that looks like. Do you have any favorite emerging trends in tech?

Ian: Ooh, that's a tricky one. I would really like for no code to actually work at some point. I feel like a couple people have had really good attempts at it. And I think it's semi possible. Like the work that something like amplify is doing is really interesting. I think it's really getting that time from bootstrapping into completed project reduced a lot more, that doesn't work for huge humongous project with big teams on it, but it's a really good way of prototype. And so what I'd like to see is more of that and more customization that's capable in there. So that's one that I'm sure will get a couple of question marks on, because I'm not going to mention the service that starts with page that no engineers, but yeah, there's a few good other tools out there. Put it that way.

Adam: Yeah, no, I, I have a, a sort of love, hate relationship with amplify because it does feel like superpowers. I've had a couple clients, I do freelance work, and they were using amplify and I kind of came into the projects and there are parts of it that feel like, wow, I can move so much faster in this specific thing, but anytime you start pushing on those boundaries, it, for me as someone who's much more into the cloud formation side and like, I'd rather probably do it myself. It just gets painful. And I feel like I'm losing time on stuff that I just wish. Yeah. The, the sort of boundaries were a little easy year to push on. Do you have any hot takes? Maybe you've already said a couple today. Do you have any, any like, particularly hot takes for me?

Ian: I've said a few today already. Maybe something along the lines of developers should have no barriers to development. And if that means that they get their own sandboxes, if that means they have to break stuff on the way there, then I think that's far more important than focusing on trying to slow down everything from the get go, yes, you need barriers into production. Yes. You need to secure in environments. But I think shifting left is a bit of an overstated thing, but I think we should really focus a lot more on that. We need to move more quickly.

Adam: So there are like on Twitter, there are sub tweets and I feel like this is a, a sub whatever this is sub podcast comment. And I don't understand the reference. Would it be too blatant to have you like expand a little bit more? I don't want to like make you uncomfortable, but I'd also like to know kind of what you're getting at.

Ian: Well, it's more of an environmental thing. So as I'm in consulting, I do see the various shades of what's going on. So in big, large enterprises, things tend to move slower. In small little niches tend to move faster, but it can be a little less secure. So, but making sure that balance is right and making sure that people don't slow down on the bad things and people find to do what their job is, which is to develop applications, to think about their customers and to effectively make money for their own company. And sometimes people haven't maybe lost that idea in their own heads lately.

Adam: So I feel like if we weren't recording, we didn't have a live audience. That would be a little bit hotter and more direct, but I'll take what I got. Yeah. You're welcome. So we're going to play a couple games, kind of shifting gears here a little bit. We're going to play AWS or Amazon where I name off Amazon's services or AWS services. And Ian has to identify whether it is prefixed with AWS or Amazon. So we'll start with that one. And then we're also going to play a game we've been playing with the security minded folk that have been on the show. Ian is definitely one of those, and this is IAM actions real or fake.

Adam: So I'll read off IAM actions and he will have to, to tell me if they're real or fake. I think Ian probably has the best shot at actually knowing some of them with some of the work you've done. You've seen more of them probably, but it's still going to be a 50/50 shot. We'll start with AWS or Amazon. It's going to be a minute on the clock to mean as you can get right. And Rich, you've done this in the past. I'm going to ask if you could be in me how many he gets, right. If you could be my official counter for the Asia Pacific region, that would be fantastic. So, Ian, are you ready?

Ian: Sure. Let's do it.

Adam: Neptune.

Ian: Amazon.

Adam: Work link.

Ian: AWS?

Adam: Direct Connect.

Ian: AWS

Adam: Cognito.

Ian: Amazon.

Adam: Elastic Beanstalk.

Ian: Amazon?

Adam: CodeCommit.

Ian: AWS

Adam: EKS.

Ian: AWS

Adam: Elastic trans coder.

Ian: Amazon.

Adam: FSX.

Ian: AWS.

Adam: Migration hub.

Ian: Amazon.

Adam: Batch.

Ian: AWS.

Adam: Time stream.

Ian: Terrible. Amazon.

Adam: Oh, did the timer actually go off?

Adam: It just binged

Ian: No, I don't get that last one.

Adam: Okay. Yeah. Yeah. I just, I really can't hear my sand effects today. No, I think it was pretty good. I think that was par. It's a 50/50 shot. I feel like there's really not much could do in the time that you have to think through it. So I'll let the official count come in through a DM. If anyone has that and wants to send it my way the judges have weighed in. Oh, and Rich. I feel like he went the extra mile and he gave me how many he got wrong too. So you got six, right? Five wrong. Thank you, Rich. I love it. Okay. So six right. I think you're kind of middle of the pack right now. Because you know, Ben got nine the first time we did it. That record has stood the test of time. Okay. IAM actions real or fake and you'll just be the third person that's done this one. So you're guaranteed third place so far. I don't even remember what the numbers have been. So honestly I'll have to come back later and figure all that out. Okay. Are you ready Ian?

Ian: Yeah, let's do it.

Adam: All right, here we go.

Adam: SSM Describe Document.

Ian: True.

Adam: Cloud Directory, remove facet from object.

Ian: False.

Adam: Support resolve, open case.

Ian: False

Adam: API gateway Git.

Ian: True.

Adam: Artifact Git.

Ian: False?

Adam: Athena delete table.

Ian: True.

Adam: SSO start SSO.

Ian: False.

Adam: Storage gateway list tapes.

Ian: True.

Adam: SNS delete subscription.

Ian: True.

Adam: And the buzzer. Those are tough.

Adam: I'll be at the docs. So I'll, we'll see if Rich was counting on that one. It's a smaller number to get through I think. Eventually we'll sort of make leader boards and we can publish these scores officially. Right now they're all just kind of out there on the podcast. And on that note, a couple of plugs. Join the discord. If you're not on the discord, Ian, I'd love to see you on the discord. Lots of the guests from the show have joined. Some of them just straight up are not going to join. I don't think Binky will be on the discord. He was kind of like, nah, I got a lot of slack workspaces, which I get, but there are a lot of guests from the show. We got a lot of listeners on the show. It's been a good time so far, although I don't know anything about discord and I don't know what I'm doing and we're going to sort that part out.

Adam: As well, if you listen to the show on a podcast platform, Spotify, Apple, et cetera, and they have the ability to rate and review, I would appreciate it. The running thing, I keep saying it on every episode still don't know. And I'm just not going to look it up at this point. I don't know what it means to get reviews. I don't know what it does for you. For me it makes me feel real good. If there's some nefarious reason why people always ask for these, I don't know about it. So I've got a clear conscience. Just give me those five star reviews is because you like me or you like the show. And I love it. I feel good. Every time I see one makes me feel real good.

Adam: So those are my podcast plugs. Ian, it's been so good to have you on. I say that with every guest, but really I love this every time I do it a little bit more. It's just been great. I thank you for taking the time out from a very busy schedule and I guess sleep at this point in your part of the world. Thanks again so much.

Ian: Lovely. Thanks for having me.