Harnessing Cloud-Native Technologies for Agile Development with Ken Pomella

[00:00:01] Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain Podcast and my goal is to help you create DevOps toolchain awesomeness.

[00:00:19] Hey, do you want to know how to harness cloud-native technologies, agile development, and learn a little bit more about AI? That's what I'll be talking about today with Ken. And if you don't know, Ken is a seasoned entrepreneur with the demonstrated history of leading successful technology-driven ventures. His passion for innovation and relentless pursuit of excellence has been the driving force behind his storied career. With a deep understanding of technology and a keen eye for business opportunities. Ken has consistently created value for stakeholders across various technology sectors and he has a bunch of experience in a bunch of different areas. I'm really excited on the show today. You don't want to miss it. Check it out.

[00:00:54] Hey, if your app is slow, it could be worse than an error. It could be frustrating. And one thing I've learned over my 25 years in industry is that frustrated users don't last long. But since slow performance isn't sudden, it's hard for standard error monitoring tools to catch. That's why I think you should check out BugSnag, an all in one observability solution that has a way to automatically watch for these issues real user monitoring. It checks and reports real user performance data in real time so you can quickly identify lags. Plus, you can get the context of where the lags are and how to fix them. Don't rely on frustrated user feedback. Find out for yourself. Go to bugsnag.com and try for free. No credit card required. Check it out. Let me know what you think.

[00:01:43] Joe Colantonio Hey, Ken. Welcome to The Guild.

[00:01:50] Ken Pomella Hey, Joe. Thanks for having me. Excited to be here today.

[00:01:53] Joe Colantonio Awesome. So before we get it, just a little curious to know why cloud-native? I know a few years ago it seemed to be all the rage is to some you still see larger enterprises trying to move to cloud-native.

[00:02:06] Ken Pomella Yeah, it's probably had a little bit of a different place in the hype curve now with AI being the more exciting new thing. But it's really great concept. I got into this early on when people still kind of didn't really know what it was. Early on in my career, I started working with AWS and they're still my favorite cloud platform, were a partner at RevStar. We did the basics. The table stakes stuff, setting up EC2 instances, RDS databases and still doing a lot of our code deployment the same way we did on prem. And so I was looking for what are better ways to do this? You start to really dig into some of the services that they have. And obviously they've changed over time. But there's better ways to get the elasticity you need, the cost effectiveness that you want that the cloud promised. And so I landed on were going to start building things cloud-native. And I was doing this in my corporate job. And then I decided to go ahead and start RevStar, dive into it more full time. And we started building these types of solutions for many customers.

[00:03:11] Joe Colantonio Awesome. So before we dive into that, I failed to mention RevStar on the bio. So maybe a little shadow. What is RevStar? Why did you just started? What's it a little bit more about what y'all do?

[00:03:19] Ken Pomella Yeah. So right. RevStar really started out as a side thing for me. When I moved down here to Tampa, people found out I could code and they asked me to do little side projects. So I started a company you said was the smart thing to do, right? So I did that for a number of years as a side hustle. Eventually, as I mentioned, I got really passionate about the cloud-native technologies, and I was doing this stuff at work and I said, there's not a lot of people out here that really understand this stuff. Everybody's still putting on EC2 instances and just lifting and shifting you to the cloud. So I want to get out here and help people build new platforms, cloud-native or modernize existing platforms, cloud-native. I got bit by the entrepreneur bug and said, I'm going to take this business that I have and go do this full time.

[00:04:03] Joe Colantonio Nice, in your journeys, why do most companies want to move to cloud-native or why is this such a push to go cloud-native?

[00:04:09] Ken Pomella There's a lot of different reasons, for me early on and why it made sense. And the side hustles that I was doing was I was doing a lot of work for startups, small businesses. We could get platforms built very quickly and very cost effectively. When we're building on Lambda, you're paying pennies per call to a microservice nano service. We're able to set up scripted environments. Yeah. No, this is a DevOps podcast. We're able to do fully automated DevOps, have on demand test environments, this things that you can't do if you're deploying to servers. The cloud-native really makes sense from the cost perspective, the scalability. Once you set it up right, it's very elastic. We don't have to go back and re-engineer things all the time for customers. They scale pretty well from MVP to the full on production product that they'll use for many years. There's a lot of benefits. But for me early on it was just how quickly could we spin up a solution. And for somebody that's on a budget, not spending tens of thousands of dollars a month hosting servers is very cost effective.

[00:05:21] Joe Colantonio Are there any tips on how to set it up rIght because I've actually read articles of companies that might cloud-native, and then they decide to go back to in-house servers to save money. But it sounds like it may have been maybe they didn't have it set up correctly. I don't know, I could be wrong, but any thoughts on that?

[00:05:37] Ken Pomella Yeah, I think most people just take servers and move them to the cloud, which is not cheaper because you're paying. If I have a ten core server on premise with 64GB of Ram, that's way more expensive on the cloud than I buy it once and I'm paying this. You start to put all these servers on the cloud. It's expensive. When we're building solutions, we're using serverless technologies. Things that aren't static running compute units. And so we're not paying for downtime or you're not paying for your server running overnight if it's not being used at night. Finding the right service, there's a lot of different services. They've evolved with time. Early on we did RDS for database. Now they have serverless RDS, which can scale a lot. And when it's not being used, it's a lot cheaper to run. There's always things changing. So looking at what's the best managed cloud service for the workload that you're running is how you have to do it. It takes a little bit of intent to sit and go. Okay, this particular thing that I want to do, I should run it with these technologies versus I'm just going to kind of build this big giant code base and go deploy it on a server and keep throwing hardware added or virtual hardware added as it scales.

[00:06:53] Joe Colantonio Nice. Now, earlier you mentioned, I think three benefits of going to the cloud, scalability, flexibility, and I think you mentioned cost saving. How can cloud-native solutions really help organizations to respond quickly to changing requirements because with DevOps developers need to quickly ship code quicker and faster with higher quality. How does this help them get there?

[00:07:16] Ken Pomella For us, I'll give you an example a client came to us the other day and said, I want to put facial recognition in my app. I didn't have to tell my team to go get some, build something from scratch or go find some different third party libraries. AWS has a service. There's a cloud-native service for it. We're able to spin that feature up quickly. And then, to me the cost is pennies on the dollar from a maintenance perspective because if you build your own, you're always bug fixing or tweaking it. Libraries change. You're offloading a lot of that development cost to them. And again, the service is cheap when you think about it, you're paying most of the time for the compute you're using or per call like we talked about with the Lambda. But it's really is cost effective time. The market's quicker. We can spin that up much faster than trying to build something from scratch or, like I said, trying to piece together third party libraries. That's really the benefit to me is that you can respond to change much more quickly and roll things out and test them out without making this huge investment upfront.

[00:08:18] Joe Colantonio When you work with customers and clients, who's usually involved in the transition? Do developers getting involved, this is more like a platform engineering team. Is it like CTO? Like, how does that work?

[00:08:29] Ken Pomella That's everybody. It depends on the size of the organization. Obviously, early on we talked about most of the time we were doing this for startups. We were dealing with a founder. They normally didn't ask too much about the technologies, like, hey, this is scalable, cost-effective, we'll be able to get this done for you quicker. And they're pretty good with that. Going into an existing business where they're not doing cloud-native, we spend a lot of time educating, walking to existing teams through what we're doing, coaching them so they can take it over and help support it in the long run. It's a little bit different. You have a lot more folks involved the larger the organization because you're kind of changing and uprooting the way things are being done. It's a little bit of an investment. And like I said earlier, it takes a lot of intent to go find the right service for the job. But it's really the flexible, agile way of doing it right. We talk about microservices, whether we're building our own or using this kind of platform as a service, as they call it. It's really just finding the tool that best aligns with the workload you're trying to run.

[00:09:31] Joe Colantonio If someone's a developer, is there anything they need to think of differently when they're developing for a cloud-native type of environment?

[00:09:38] Ken Pomella If you've never done microservice right, or especially not nano service, if you use Lambda the way it's supposed to be used, it's pretty common to sit there and build a code. But I did it right. I pulled up some monolithic code base, like building the pattern like repository. And I deploy it on the backend. That was normal most of my career. Now it's okay, who's working on which service? Do we have to build the service ourselves. How much code are we writing versus leveraging platform as a service. It's just understanding. There's a lot of great certifications out there that AWS offers. There's tons of content on YouTube and places like Udemy. So just understanding all the services and how they work and then also digging into the cost calculator. A lot of people skip past that because sometimes it looks there's a certain combination of tools looks good, but you have to make sure it's cost-effective as well. I'd say learn the platform, learn what the different tools are and then also consider the costs. I think I said just a little bit more intentional. We used to spin up an IDE and just start writing code. You have to sit in with the architecture hat on before you just dive in.

[00:10:48] Joe Colantonio Nice. So are there any other benefits? I know a lot of times teams use cloud environments to spin up and spin down environments, and they check in code. They'll do like a test environment or something, or a pen test environment. Is that something you see or something that you recommend?

[00:11:02] Ken Pomella Yeah, we do that with a lot of customers. It's a save costs. Instead of having a static QA, UAT environment. We'll do that on the fly. So we write all of our infrastructure in Terraform. So we're able to deploy an environment very quickly, run our automated test cases, spin the environment down so that's another one of those huge cost savings. It's tough to do that with physical servers or even virtual machines. You have to write a lot of your own code to spin up and down. So I don't even know how that would work. I wouldn't even try it. It's much easier just to write your stuff in Terraform and use the cloud-native approach.

[00:11:39] Joe Colantonio Absolutely. So are there any catches that you see developers or companies struggling with? I don't like the top three like things that are going to sabotage your migration to cloud-native first type of approach.

[00:11:51] Ken Pomella I think, again not doing that architecture and mapping things out. Maybe not having the understanding of it, not finding a good partner who can help you. If you're not sure. These aren't the kind of standard development practices you'd be used to. They're easy to pick up if you sit down and work on it. But you know how that is. It's tough when you're being told you have to write code, get stuff out for sprints. So you're just tinkering. Definitely, a lot you can do out of the box. That's fairly easy. AWS has a framework called Amplify that helps you spin up apps very quickly and React native, a couple of the ones we use it with languages we use it with. It still takes a little bit of time to go through and learn that. It's just being able to invest the time or finding somebody who can help you on that journey.

[00:12:38] Joe Colantonio Nice. This might be a weird question. If I'm a developer and I'm working on large code base consuming services from third party vendors and other cloud, how do I know when I'm mapping what using what? I mean, is there any like any best practices for knowing what your application is actually using?

[00:12:55] Ken Pomella Good documentation is always a great place to start. Even when we're building, let's say an MVP for a small business or startup, we do a lot of documentation up front to lay out what components we're using on the cloud, what third party services, and how the data will flow between them. These days you use this kind of software supply chain model. It's pretty common now. Go build your own SNS tool. You use Twilio or use something on SNS on AWS cloud. You're not building your own. You only get the 4G 5G modem and put it in your server room. It's fairly common. But again, it takes a little bit of intention upfront to map all that out, but we provide a lot of documentation for that. I know that's always not the most fun part, and when I was coding full-time when I was younger, I used to roll my eyes when somebody said to document something or to land in front of, hey, I just want to write code. I'm here to write code. But that part's really important. And then again, doing the calculations on what is one service cost over another is very important part of that documentation process.

[00:14:02] Joe Colantonio Nice, I know it's pretty rare, but I have seen it. If AWS goes down, do you recommend someone has like a backup, a different cloud provider that they could fill over to? Is that something common that you see?

[00:14:13] Ken Pomella Again, that's depends on your organization. If you do multiple availability zones in AWS that gives you like 99 and four nines. If you do multiple regions, that gives you like 99 and six nines. If you need something above that, maybe you go multi-cloud. But that's not for everybody. It's expensive. It also makes it tough to do cloud-native because if I write something on Lambda, it doesn't. I can't just go deploy that on an Azure Functions. I'd say for most people, a good multi-region redundancy is plenty. I've never seen multiple AWS regions go down. You can set up your multi-region across numerous regions. But yeah, I have null transparency. I have seen our region go to our data center go down for maybe a couple of hours, it's never been a big deal for us. But that's also, you start to get into all this redundancy. It's expensive. Do I go to a startup that's just getting out the gates and say you need a four region redundancy that's going to cost you four times the amount of money. So you have to meet them where they're at to and make recommendations. But yeah, I would say probably be Armageddon before AWS entirely goes down. We would probably be in a lot of trouble if that happens. But if you're a huge at corporate enterprise and let's say you're a financial company that's processing transactions all day, you may want to have that level of redundancy and you probably could afford it at that point.

[00:15:48] Joe Colantonio Nice, when you work with the client, do you always just go to AWS? So there are certain benefits of other cloud platforms. Is there a reason why you would choose AWS over another? Is it just your preference, personal preference?

[00:16:01] Ken Pomella Yeah, we're an AWS partner. I like their platform the best. It has, I think the best cloud-native services. For me, as a cloud-native guy, I'm able to do more with that platform than I am with others. Now, they're catching up microsoft has a lot more cloud-native components now so does Google. And there's some things those do well. If you're really into open AI, obviously Microsoft gonna be your better partner. Google has some really great AI, ML tools and big data tools, but pound for pound, AWS has the best services that we can use to help our clients. And I feel like they're always out ahead. They're always putting out new services and things that everybody else is trying to keep. So that's why we're strategically aligned with them. But I would say anybody who wants to build cloud-native, I'm not going to be mad if you're doing it on Google or something else. I just hope that's a trend that continues and more people adopt it.

[00:16:58] Joe Colantonio Absolutely. I know the question answer is probably it depends. But if an organization is looking to move to the cloud, they already have existing like a monolith type of system. How hard is it to make that transition? Do you go in phases or is it like a big bang or how does that work?

[00:17:13] Ken Pomella Yeah, I'm not a big fan of Big Bang rewrites. I think they never work well, that's where that workload mapping we talked about earlier, I think really makes a big difference. If you can find a feature that you're looking to add, break that off into a micro or nano service and put that on the cloud. That's a great way to do it. You can go through and break up your code base and say, hey, I'm updating. I'm heavily updating these domains of my system. Let's move those into microservices. Again, that's that intent and planning. It's tough if you take it and say, well, I'm going to sit here and and just start doing cloud-native without a plan or a roadmap, you're probably going to get frustrated. So that's my favorite approach. Start breaking things into microservices. Move things that you can easily take and separate from the code base. They're not too intertwined in everything else. But now nowadays with really having very separated front ends and back ends, it makes it a little bit easier. I'm probably dating myself a little bit, but you know, I started out coding like VB 6 and windows apps. And then I got into .Net, we built these, everything was all in one codebase. But now you might have this monolithic back-end and at least have a separate front-end. So it makes a little bit easier to decouple things and start pulling them out in the services.

[00:18:34] Joe Colantonio Nice. When RevStar goes in, do you see the skills that the company currently has? Because maybe you have old school developers, maybe they're not too hip to microservices or serverless computing. Is that something you see, or is that just something that's usually not a concern?

[00:18:48] Ken Pomella That's one of those it depends on the company. And you have to really you have to tread lightly there too, right? Because if you come in with all these radical ideas, people start to feel like, oh my God! I don't want to adopt that or what's going to happen to me, right? So like I said, we spent a lot of time making sure we're tightly aligned on things that exist there. We have one example, we do material front-ends and we work with the customer and they like bootstrap. They've used bootstrap. That's not our standard or our favorite these days. But that's what they're comfortable with why we teach them this whole new CSS grid system. That's just going to add a layer or friction when the real win is we're trying to take a .Net desktop app and put it out in the web. That's the more important part. It's a little bit of a-I think one of those give and take situations, you have to make sure everybody's comfortable with the solution and pick your battles. And what's really important win, which is getting things out of desktop apps into services and web front-ends on the cloud.

[00:19:51] Joe Colantonio Awesome. In your experience from cost savings, is there like an average you normally see companies save? That depends again. But like is that normal like 20% savings probably off the bat if you do it correctly or something like that.

[00:20:03] Ken Pomella Yeah. I mean, just for some perspective, I can run an entire environment for a customer that's just starting out with a new platform for $500 to $700. It's tough to get a the servers for that price. This is data base everything. It's a much lower cost of entry. And then the scale is where you really save money. We have customers that are doing lots of transactions that might be paying 2500 a month, five grand on the high and where they were running all their servers. You're spending ten grand plus is a fairly normal spend. There's some things I get you have to put on a server just as what it is, but having a bunch of custom applications that you're trying to scale vertically with or even horizontally with hardware or virtual hardware, it starts to get expensive. If you have let's say you have this really like ugly long running task that runs all the time, eats up a lot of memory, eats up a lot of CPU, and you just keep going in there and the more data that gets in there, it's on the server. So it's not very elastic. And so you're constantly adding CPUs and memory to your web server and in your database server is starts to add up. And so then you go, okay, I'll get into scaling. Well now I want to manage this scaling myself with load balancing on the servers. It's just more of a management overhead to that where we can put that on a Fargate ECS and Fargate instance and set up auto scaling. Take care of itself when it's not running it'll scale back down. I know I have to go in the machine and change the CPU. That's where the real savings is. And you can save quite a bit and exact numbers depend. But when you start to think about what you're paying for the time you're not running this stuff and nobody's going in there and changing the resources, it adds up pretty quickly.

[00:22:08] Joe Colantonio And something like that could autoscaling hide a potential performance issue? I don't think just scaling affinity is going to solve all performance issues is going to come a point where it just crashes, I would assume.

[00:22:19] Ken Pomella Yeah. I mean, yeah. So you obviously have alerts for billing. If you're starting to see that it's constantly scaling up and doing that fairly often. And also remember it doesn't instantly scale. So many like really bad code that just spikes up the usage. Like immediately when something's running, you'll notice that too. You have to set up the logs. I think a lot of people skip that part. APM tools are still great. So you have to write good code. But it definitely helps when you have these like, hey, we have a SaaS product. We ran a marketing campaign today and got flooded with new users. I didn't have to go in like add more Ram and CPU to my server or add another server into my farm because my marketing team came to me and said they want to run a campaign today. I think that's where the real I think secret sauce is. But yeah, you have to write good code. There's no, I think, amount of hardware or or cloud-native magic you can throw at really bad code.

[00:23:19] Joe Colantonio Right. How about security? I know a lot of companies. I used to work for insurance companies, health care companies. Are there extra things you need to keep in mind from security wise when you go cloud-native, or is there just a different mindset?

[00:23:31] Ken Pomella Yeah, I mean, you have to do the normal stuff, right? Have your firewalls, make sure you're segmenting your different components into networks you don't want to have or access control. Having and using AWS use your IAM to make sure your role-based access control is solid. So you do that kind of stuff where the I think the cloud-native helps is especially if you're using things like Lambda where you don't have static running servers, there's nothing really to happen in that case, I'm not able to get into this server. It runs when only when it's executing. It's a lot harder. I'm not a hacker, I'm sure somebody might be able to figure it out, but it's a lot harder right to do that. These are just by nature, more secure than anything. Letting a server sit there and run. Then the other nice thing is you're offloading some of this responsibility to Amazon. They have SOC certifications high trust all that good stuff. I hate to say it, but they probably have some of the best network and security and infrastructure guys. It's kind of hard to sit here and say, well, ten is probably better at securing infrastructure than the folks Amazon is hiring. So you're offloading a lot of that responsibility at the infrastructure level to really smart people which is another benefit.

[00:24:56] Joe Colantonio You're probably sick of talking about this topic, but have to bring it up. AI, how does AI come into play, if at all with cloud-native? Any benefits you see of it? Overhyped, underhyped? Properly hyped AI, what are your thoughts?

[00:25:11] Ken Pomella I love AI, this is the next internet. I mean, of course we talked about the hype curve a little bit earlier, but that's there. It'll always be there. But this is a technology that's going to change everybody's life one way or another. We're again excited to be partnered with Amazon because of the great model as a service tools that they have. We're able to pick from a number of different models which one fits the best for the job. Take our customer's data that either is in systems that we've built for them or their other systems. Bring it into the cloud and either train models or go with a RAG solution and tie their proprietary data in with the base models and spin up POCs for AI solutions very quickly. That's another one of those situations where it's a lot faster to get something out there to see if it has value because you're using the cloud. Nothing with AI is really cheap right now outside of maybe a ChatGPT for a license, but those costs will come down right as the technology, I think matures. And there's a little more economies of scale there.

[00:26:21] Joe Colantonio Nice. Now, you mentioned, RAG, can you just explain what rag is for people that may not know?

[00:26:25] Ken Pomella Yeah. So it's, retrieval augmented generation. So that's if you want it to take base models and do more just in time enrichment with your own data. And that's really exciting because sitting and trying to train a model is A expensive and oftentimes overkill when you just need some of the power of the base model and to be able to kind of enhance that with your own data so that you get more targeted, meaningful responses.

[00:26:52] Joe Colantonio How hard is it for to get into AI then? What's it's in the cloud, it seems like you have models you can choose from. Any tips from someone that's like, oh, I want to experiment a little bit more. So this is the probably the trend that we're going to be seeing more and more of?

[00:27:04] Ken Pomella Yeah, I'd say, if you're a developer and you're curious. So you go to Facebook, get the Llama model. If you have a decent computer, you can run it on a little bit cheaper. Right now even the cloud services, let's say for someone self-funding out of their own pocket for fun, it's a little bit cost prohibitive. But I know AWS is great too about giving out credits if you do different workshops and things like that, especially if you go out the reinvent, they're usually doing a lot of hands on workshops and give you credits. They try to foster a lot of that. And they also have, if you teacher, if you use the Llama model at home, they have Llama now in the model as a service. So you can take it, learn it and then go apply it at work. I'd say, that's probably the best first start thinker with it on your own. But there's a lot of good information out there. I think everybody is curious about this and trying to help put out information. I know me and a friend of mine, we're starting a side thing doing some online courses and workshops and webinars. We're trying to help out and kind of talk the talk, walk the walk, so to speak, right now and get the information out there as well. But yeah, it's an exciting time to try it out. And there's a lot of ways you can do that.

[00:28:20] Joe Colantonio Nice, are there any other trends you see for cloud-native development over the next few years, or do you think it's going to be focused basically on incorporating AI and machine learning more and more?

[00:28:30] Ken Pomella I think just the how many things as new tech comes out and trends, how many things can we take and put as components that everyone can use. I think it's hard to say. I mean, we have IoT, cloud-native services, AI. I think anytime something new comes out, there'll be some service popping and that's why I love AWS. They're usually way out ahead of that when everybody was talking about just open AI and ChatGPT, they're in the background building these great model as a service offerings where I can get access to different models and not just one. I'm excited to continue to be partner with them. And I think they'll stay on the forefront of that. But yeah, it's hard to guess they'll have cloud-native quantum computing once that's cheaper and a little more mature. But yeah, and anything that comes up, I see them staying on top of it and making sure there's a good offering out there.

[00:29:23] Joe Colantonio Awesome. Okay, Ken, before we go, is there one piece of actionable advice you can give to someone to help them their DevOps cloud-native efforts? And what's the best way to find contact you or learn more about your company?

[00:29:33] Ken Pomella I'd say I like if I'm starting out, learn Amplify on AWS. You don't have to be a DevOps expert. You could build Lambda, you can write apps and deploy them on the cloud all from your own console. You don't have to go write Terraform scripts and do all that. I'd say Amplify is a great place to start if you're interested in AWS, if you want to get into AI, they have Bedrock Studio and you can build directly on the cloud now with AI solution. But like I said, it's a little bit cheaper if you want to just play around on your own, on your computer, at home. But yeah, that's what I would say, start there, start with the basics. Understand how to get your code written in micro nano services and get it out into the cloud. So it's RevStarconsulting.com. That's the easiest way to find me. You can also look me up on LinkedI Ken Pomella the only one that that comes up. I'm easy to find your.

[00:30:28] Remember, latency is the silent killer of your app. Don't rely on frustrated user feedback. You can know exactly what's happening and how to fix it with BugSnag from SmartBear. See it for yourself. Go to BugSnag.com and try it for free. No credit card is required. Check it out. Let me know what you think.

[00:30:46] And for links of everything of value we covered in this DevOps Toolchain Show. Head on over to Testguild.com/p145. And while you're there make sure to click on the Smart Bear link and learn all about Smart Bear's awesome solutions to give you the visibility you need to deliver great software that's Smartbear.com. That's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed in creating end-to-end full-stack DevOps Toolchain Awesomeness. As always, test everything and keep the good. Cheers.

[00:31:23] Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps, and automation professionals in the world, we'd love to have you join the FAM at Testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real-world value that can improve the skills or solve a problem for the Guild community. I love to hear from you head on over to testguild.info And let's make it happen.