Harnessing Cloud-Native Technologies for Agile Development with Ken Pomella

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. Hey, do you want to know how to harness cloud native technologies for agile development and learn a little bit more about AI? That's what we'll be talking about today with Ken. And if you don't know, Ken is a seasoned entrepreneur with a 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 has a bunch of experience in a bunch of different areas. So I'm really excited to have him on the show today. You don't want to miss it, just check it out.

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 the 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 detects 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.

Hey Ken, welcome to the Guild.

Hey Joe, thanks for having me. Excited to be here today.

Awesome. So, before we get into it, just a little curious to know why cloud native? I know a few years ago it seemed to be all the rage. Is this something you still see large enterprises trying to move to cloud native?

Yeah, it's probably at a little bit of a different place in the hype curve now with AI being the more exciting new thing, but it's really, you know, it's a really great concept. I got into this early on when people still kind of didn't really know what it was. You know, early on in my career I started working with aws and they're still my favorite cloud platform. We're a partner at Revstar and so we, you know, we did the basics, right, the table stake 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, you know, 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, we're going to start building things cloud native. And so 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.

Awesome. So before we dive into that, I failed to mention Revstar in the bio. So maybe a little shout out, what is revstar? Why did you start it? What's it a little bit more about what you all do? Yeah.

So Revstar really started out as a side thing for me. So 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 because it was the smart thing to do. Right. So I did that for a number of years as a side hustle. Eventually, as, as I mentioned, I got really passionate about the cloud native technologies and I was doing this stuff at work and I said, you know, there's not a lot of people out here that really understand this stuff. Everybody's still putting you 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. So 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.

Nice. So, you know, in your journeys, why do most companies want to move to cloud native or why is it such a push to go cloud native?

There's a lot of different reasons. You know, for me, early on, and why it made sense in 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. Right. So when we're building on Lambda, you're paying, you know, pennies per call to a microservice nano service. We're able to set up, you know, scripted environments. I know this is a DevOps podcast. Right. So we're able to do you know, fully automated DevOps have on demand, you know, test environments just things that you can't do if you're deploying to servers. Right. So 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, you know, full on production product that they, they'll use for many years. So there's a lot of benefits. But for, 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, you know, very cost effective.

Right? Yeah. So are there any tips on how to set it up? Right. Because I've actually read articles of companies that went cloud native and then they decided to go back to, you know, in house servers and 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?

Yeah, I think most people just take servers and move them to the cloud, which is not cheaper. Right. Because you're paying, you know, if I have a, a 10 core server on premise with 64 gigabytes of RAM, that's way more expensive on the cloud than I buy it. Once 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, right? Things that aren't static running, you know, compute units. And so we're not paying for downtime. Right. You're not paying for your server running overnight if it's not being used at night. So finding the right service. There's a lot of different services, right? They've evolved with time. You know, early on we did rds, right. For database. Now they have serverless rds, right. Which can scale a lot of. And when it's not being used, it's a lot cheaper to run. Right. So 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.

Nice. Now earlier you mentioned, I think three benefits of going to the cloud. Scalability, flexibility. I think you mentioned cost savings. So how can cloud native solutions really help organizations to respond quickly to change in requirements? Because with DevOps developers need to quickly ship code quicker and faster with higher quality. How does this help them get there?

So 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, you know, my team to go get some, build something from scratch or go find some different third party libraries. You know, AWS has a service, right? There's a cloud native service for it. We're able to spin that feature up quickly and then you know, to me the cost is pennies on the dollar from a maintenance perspective. Right? Because if you build your own, you're always bug fixing or tweaking it. Libraries change, right? Where you're offloading a lot of that, you know, development cost to them. And again this, the service is cheap, right? 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 you know, it's really is cost effective time to markets 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. So that's really the benefit to me is that, you know, you can respond to change much more quickly and roll things out and test them out without making this huge investment up front.

Nice. So when you work with customers and clients, who's usually involved in the transition? Do developers get involved? Is this more like a platform engineering team? Is it like cto, like how does that work?

It'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 when 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. So it's a little bit different. You have a lot more folks involved, the larger the organization, right? Because you're kind of changing and uprooting the way things are being Done. So it's a little bit of an investment. 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.

If someone's a developer, is there anything they need to think of differently when they developing for a cloud native type of environment?

So 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 base. You know, I did it right. I pulled up some monolithic code base, like building the pattern, like repository, you know, and I deploy it on the back end. Right. That was normal most of my career. Now it's okay, who's working on which service, which, you know, can we do? We have to build the service ourselves. How much code are we writing versus leveraging platform as a service. So it's just understanding there's a lot of great certifications out there that AWS offers. There's tons of content on YouTube and, you know, places like Udemy. Right. So just understanding all the services and how they work and then also digging into the cost calculator. Right. A lot of people skip past that because sometimes it looks a certain combination of tools looks good, but you have to make sure it's cost effective as well. So I'd say learn the platform, learn what the different tools are, and then also consider the costs. Like I said, just a little bit more intentional. We used to spin up an IDE and just start writing code. You have to sit and put the architecture hat on before you just dive in.

Nice. So are there any other benefits? I know a lot of times teams use cloud environments to spin up and spin down environments. When they checking 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?

Yeah, we do that with a lot of customers. So to 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. Right. You have to write a lot of. You'd 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.

Absolutely. So are there any gutches that you see developers or companies struggling with, like the top three like things that are going to sabotage your migration to cloud? A native first type of approach?

I think it's, you know, again, not doing that architecture and mapping things out, maybe not having the understanding of it, not finding a good partner who could help you if you're not sure. You know, these aren't the kind of standard development practices you'd be used to. So 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 the right code, get stuff out for Sprints, right. So you're kind of just tinkering. So there's definitely, you know, 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 in React, React Native or a couple of the ones we use it with, languages we use it with. But you know, it still takes a little bit of time to go through and learn that. So it's just being able to invest the time or finding somebody who can help you on that journey.

So 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 clouds. How do I know when, when I'm mapping what's using what? I mean, is there any best practices for knowing what your application's actually using?

Good documentation is always a great place to start. So 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, right? Every if you don't go build your own SMS tool, right, you use Twilio or use something on sns. On AWS cloud, you're not building your own Echo to get the 4G 5G modem and put it in your server room. So it's Fairly common. But again, it takes a little bit of intention up front 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 plan it in front of, hey, I just want to write code, I'm here to write code. Right, but that part's really important. And then again, doing the calculations on what is one service cost over another is a very important part of that documentation process.

Nice. Now 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 fail over to? Is that, is that something common that you see?

Again, that depends on your organization. So if you do multiple availability zones in AWS, that gives you like 99 and 4 nines, right? 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. Right. Because if I write something on Lambda, it doesn't. I can't just go deploy that on Azure functions. So 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 no transparency. I have seen our region go, our data center go down. So for maybe a couple of hours, it's never been a big deal for us. But that's also, you know, you start to get into all this redundancy, it's expensive. So do I go to a, you know, 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 too and make recommendations. But yeah, there's, I would say it'd probably be Armageddon before us entirely goes down. We'd probably be in a lot of trouble if that happens. But you know, if you're a huge corporate enterprise and you know, let's say you're a financial company that's processing transactions all day, you may want to have, you know, that level of redundancy and you probably could afford it at that point.

Nice. And when you work with the client, do you always just go with aws? Are there certain benefits of other cloud platforms. Is there a reason why you would choose AWS over another? Is it just depressed preference, personal preference?

Yeah, we're an AWS partner. I like their platform the best. It has, I think the best cloud native services. So 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 OpenAI, obviously Microsoft is your better partner. Google has some really great AIML tools and big data tools. But pound for pound, AWS has, you know, 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 up with. So that's why we're strategically aligned with them. But you know, 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.

Absolutely. So I know the questions 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? Is it like a big bang? How does that work?

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. So 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, you know, I'm heavily updating these domains of my system. Let's move, you know, those into microservices. So again, that's that intent and planning, right. It's tough if you take it and well, you know, I'm going to sit here and, and just start doing cloud native without a plan or a roadmap. Probably going to get frustrated. So that's my favorite approach. Start breaking things into microservices. Move things that, you know, you can easily take and separate from the code base. They're not too intertwined and everything else. But you know, 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 and like VB6 and Windows apps and then I got into net, we built these, everything was all in one code base. But now you might have this monolithic backend and at least have a separate front end. So it makes it a little bit easier to decouple things and start pulling them out into services.

Nice. When Revstad 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 with microservices or serverless computing. Is that something you see or is that just something that's usually not a concern?

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

Awesome. So in your experience from cost savings, is there like an average you normally see companies save is that depends again, but Is that normal 20% savings? Probably off the bat if you do it correctly or something like that.

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, you know, get a servers for that price. Right. This is database everything. So it's a much lower cost of entry and then the scale is where you really save money. So we have Customers that are, you know, doing lots of transactions that might be paying, you know, 2,500amonth, five grand on the high end where they were running all their servers, you're spending ten grand plus. Right. Is a fairly normal spend. So there's some things I get you have to put on a server just is what it is. But having a bunch of custom applications that you're trying to scale, you know, vertically with or even horizontally with hardware or virtual hardware, it starts to get expensive. You know, 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 a server, so it's not very elastic. And so you're constantly adding CPUs and memory to your web server and your database server starts to add up. Right. And so then you go, okay, I'll get into scaling. Well now I want to manage this scaling myself with load balancing on, on the servers. Right. It's just more of a management overhead to that. Right. Where we can put it, you know, we can put that on a Fargate, you know, the Fargate ECS and Fargate instance and set up auto scaling. So take care of itself when it's not running, it'll scale back down. I don't have to go in the machine and change the cpu. So that's where the real savings is. And you can save quite a bit. You know, exact numbers depend. But when you start to think about what you're paying for the time you're not running this stuff and no one's going in there and changing the resources, it adds up pretty quickly in something like that though.

Could auto scaling hide a potential performance issue? I don't think just scaling affinity is going to solve all performance issues. There's going to come a point where it just crashes, I would assume.

Yeah, I mean, so you obviously have, you know, alerts for billing. So 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 any like really bad code that just spikes up the usage like immediately when something's running, you'll notice that too. So you have to set up the logs. Right. I think a lot of people skip that part. You know, APM tools are still great, so you have to write good code. But you know, it definitely helps when you have these like, hey, we, you know, we have a SaaS product. We ran a marketing campaign today. It got flooded with new users. I didn't have to go and like add more RAM and CPU to my server, 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 cloud native magic you can throw at really bad code.

Right. How about security? I know a lot of companies I used to work for, insurance companies, healthcare 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?

Yeah, I mean you have to do the normal stuff, right? Have your firewalls and make sure you're segmenting your different components into networks. You don't want to have poor access control. So having using like an 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. Right? In that case, I'm not, you know, 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 so I'm sure somebody might be able to figure it out. But it's a lot harder, right, to do that. These are just, you know, by nature more secure than, you know, letting a server sit there and run. Right. And the other nice thing is you're, you're offloading some of this responsibility to Amazon, right? You know, they have SOC certifications, hipaa, High trust, all that good stuff, right? 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, you know, Ken 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. Right? Which is another benefit.

Now 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, under hyped, properly hyped AI. What are your thoughts?

I love AI. This is the next Internet, right? I mean of course we talked about the hype curve a little bit earlier, but you know, 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. So we're again excited to be partnered with Amazon because of the great model as a service tools that they have. Right. So we're able to pick from a number of different models which one fits the best for the job. Take our customers data that, you know, either is in systems that we've built for them or their other systems, bring it into the cloud and you know, either train models or go with a RAG solution and tie their proprietary data in with the base models and it spin up, you know, POCs for AI solutions very quickly. So 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. You know, nothing with AI is really cheap right now outside of maybe a ChatGPT Pro license. But those costs will come down right as, as the technology I think matures. And you know, there's a little more economies of scale there.

Nice. Now you mentioned rag. Can you just explain what RAG is for people that may not know?

Yeah, so it's a retrieval augmented generation. So that's if you want to take base models and do more just in time enrichment with your own data. And that's really exciting because you know, 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.

So how hard is it to get into AI then once it's in the cloud it seems like you have models you could choose from. Any tips for someone that's like, oh, I want to experiment a little bit more because this is probably the trend that we're going to be seeing more and more of.

Yeah, I'd say if you're a developer and you're curious, maybe go to Facebook, get the Llama model if you have a decent computer you can run it on. It's a little bit cheaper right now. Even the cloud services, I'd say for someone self funding out of their own pocket for fun, it's a little bit cost prohibitive. But you know, I know AWS is great too about giving out credits. If you do different workshops and things like that, especially if you go out to reinvent, they're usually doing a lot of hands on workshops and give you credits. So they try to foster a lot of that. And they also have, you know, if you teach your, if you use the Llama model at home, they have Llama now in, in the model as a service. So you can take it, learn it and then go apply it at work. So I'd say, you know, that's probably the best first start tinker with it on your own. But it's, you know, there's a lot of good information out there. I think everybody is curious about this and is trying to help put out information. I know me and a friend of mine were starting a side thing, doing some online courses and workshops and webinars. We're trying to help out and kind of, you know, 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.

Nice. So any other trends you see for cloud native development over the next few years or do you think it's just going to be focused basically on incorporating AI and machine learning more and more?

I think just how many things as new tech comes out and trends, how many things can we take and put as components that everyone can use? Right. So I think it's hard to say. I mean we have IoT cloud native services AI so I think anytime something new comes out, there'll be some service popping up. And that's why I love aws. They're usually way out ahead of that. When everybody was talking about, you know, just OpenAI and chat GPT 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. So I'm excited to continue to be partnered with them and I think they'll, they'll stay on the forefront of that. But yeah, it's hard to guess they'll have, you know, cloud native quantum computing once that's cheaper and a little more mature. But yeah, anything that comes up, I see them staying on top of it and making sure there's a good offering out there.

Awesome. Okay Ken, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps Cloud native efforts? And what's the best way to find contact you or learn more about your company?

I'd say I like, you know, if I'm starting out learn amplify on AWS. You don't have to be a DevOps expert. You can build Lambda, you can run, write apps and deploy them on the cloud all from your own console. You don't have to, you know, go write Terraform scripts and do all that. So 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 you can build directly on the cloud. Now an 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 you know how to get your code written in Micro Nano services and get it out into the cloud. So it's revstar consulting.com that's the easiest way to find. You can also look me up on LinkedIn Ken Pamela I'm the only one that comes up, so I'm easy to find.

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

And for links of everything of value we covered in this DevOps toolchain show, head on over to test guild.com P145 and while you're there, make sure to click on the Smart Bear link and learn all about Smart Bears awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed, creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. 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@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'd love to hear from you. Head on over to test guild.info and let's make it happen.