Testing AWS Applications Locally and on CI with LocalStack

The full transcript

Japneet (LambdaTest) - Hello everyone, welcome to another insightful session of our Lambda Test Experience (XP) series. XP series features industry experts and business leaders in the testing and QA ecosystem. And we are excited to have you join us. I am host Japneet Singh Chawla, Lead Member of Technical Staff working at Lambda Test. And today we'll be exploring the fascinating world of testing AWS application locally and on CI with LocalStack.

And today's session will be having with LocalStack and open source AWS Cloud Stack platform, enabling developers to build and test cloud application on local machines and HyperExecute by LambdaTest, which will significantly increase the speed of execution of LocalStack tests. To shed light on this and provide valuable solutions, we have Harsh Mishra with us today.

Harsh will be providing live demonstrations, walking us through various scenarios and showcasing advanced features that can immensely boost productivity and collaboration within teams. So without further ado, let's jump straight into the heart of discussion. Over to you, Harsh.

Harsh (LocalStack) - Thank you, Japneet, for the wonderful introduction. So Hi, everyone. I am Harsh. I'm currently working as an engineer at LocalStack. And I'm really thankful to the LambdaTest team for inviting me for this XP Webinar series, where we can just discuss a bit about what is LocalStack exactly and how it is helping the developers to basically build and test their AWS applications.

So I guess I could give a very gentle intro for myself. I'm Harsh working at LocalStack. And previously, I've been working at different companies like Red Hat, Quonsight, Hackerank. And I mostly dabble in with web engineering, Python, DevOps, Cloud Native stuff, and all of these things. So my journey with LocalStack was pretty interesting. I was someone who was looking into testing these AWS applications for my final year college project. And I always used to run into these billing issues, the budget issues, and everything out there, which was quite painful for me to pay as a student. So I discovered LocalStack in this particular endeavor. I figured out that LocalStack is an open source project that basically enables you to run your AWS applications pretty much on your local machine without having a real AWS account.

And I guess I just found it pretty fascinating and this is how I got started with the whole ecosystem. So in this webinar, I will be just walking through what exactly LocalStack is, how it is helping the developers to solve the traditional inner dev loop problem, like how it basically helps you to like revolutionize your entire testing loops directly for your AWS applications, and how LambdaTest basically provides us this hyper-execute environment that allows us to run all our tests right on the cloud itself, and basically make sure that everything is running properly without having to spend a lot upon AWS developer accounts or getting these AWS services up and ready.

Japneet (LocalStack) - Great to hear about your story of that from college to LocalStack and how you can relate to the actual work that you are doing and I think you are like among those few lucky ones who get to know the reason of why they are working actually and how they are like performing in their day to day life. So I think that might also motivates you to like work into that direction.

Yeah. So, so, uh, I have few questions for you that, uh, like with those questions, like we'll be discussing about how a LocalStack is solving the problem. And, uh, like how people are, like, what is the actual problem and how LocalStack and HyperExecute, uh, they are solving the problems. So, uh, the very first thing that I would like to ask you is like, what are the most common challenges developers are facing during testing the cloud or develop? And how LocalStack is helping to mitigate such issues that like you also talked about some of the things in your intro.

Harsh (LocalStack) - Exactly. So I guess this is something that a lot of people who are building on AWS right now can particularly relate to. So in the old days of development, we used to have all of the software components right on our local machine. Like we had the front end, we had the backend, we had the databases, everything right running on our local machine. And there was this concept of inner dev loop that a lot of developers used to challenge. Like every change that you make on your application, it should be reflected on your local development server almost immediately.

You should not basically see a delay. You should not have a very bad developer experience while you're actually building these real-time applications out there. Now, with the introduction of public cloud service providers like there is AWS, there is Azure, there is GCP, there are a lot of cloud-native services that are obviously making our lives easier. But the problem that traditionally associates with these public cloud service providers is how we can basically build and test our applications. Like if I'm a developer today and I'm trying to build out let's say a serverless application. So if you take a look at the normal serverless architecture on AWS, it has a bunch of AWS services. There are Lambda functions, DynamoDB tables, SNS topics, SQLs, like a lot of things running on the site. So how can I basically pull them down to my local machine and basically work them and testing my applications. It perfectly makes sense for me to use these services while I'm pushing my application to the production because that's where my next million users are.

But if I'm just developing and testing within a team, it doesn't exactly make sense for us to be spending such a huge amount of money just to build our application out. And I'm just talking about the whole serverless application aspect of things. Like let's say you are trying to test out some big data components. Let's say you're trying to use some more exotic services like EKS or ECS that actually costs a lot of money to run directly on AWS. So in that case, you will definitely start noticing that there is a huge upshift in the time and the cost that you're actually spending to test on the real cloud itself.

And this is a problem that has not been solved by any of the public cloud service providers. AWS, Azure, GCP, all three public cloud service providers have the same problem. And if you go and check out some of the documentation or some of the reference guides, they will always recommend you to use the real cloud itself. They will always say like, if you're building an application, please prefer to test on the real cloud itself. But that makes sense if you're working in small teams.

But once your application starts scaling out, once it has a lot of complex workloads and components, you definitely start noticing that there is a definite downtrend in how much productivity you're actually driving. Just imagine you're trying to spin up a database on AWS. Let's say it's an RDS Aurora cluster. If you're spinning that up right on the AWS right now, that is gonna take you 10 to 15 minutes of your time. Are you really gonna wait for 10 to 15 minutes for a database to be spinned and actually start testing it out?

On my local machine, I just want to make sure that my database spins up in like a few seconds itself, and I can start testing my APIs with that. The whole developer experience should be improved and that is the point that a lot of developers want to fix. Now, this problem is being solved by a lot of different companies in different manners. There are multiple companies, even within like the whole dev ecosystem right now that are trying to make sure that there is a definite compatibility in your local developer environments and the real cloud.

So that everything that you're working on, on your local machines, it is being deployed in the cloud in real time and you get to see all the changes reflected like right on the local machine itself. So you can actually drop a debugger, you can actually like debug your applications right on the cloud and it's a good experience. But the whole aspect of the cost and the time still remains. We don't want to spend so much just building and testing on the cloud. We also don't want to spend so much of our time just to make sure that our applications are actually working properly.

And if you take a look at these traditional airtight environments, like let's say the banking, the healthcare, not every developer has got access to the cloud. I guess like Japneet, you and me, like we are at a lucky place where we actually have these AWS developer accounts. You can actually experiment with things, break a few things here and there, and actually make things work. But what about those developers who are working in banking and healthcare, or some other sectors who don't have access to the cloud, but now they want to actually build out the applications over there, because cloud eventually drives innovation.

So if these things are not present for them, that's obviously a handicap. And there are like very few solutions that can actually help us to solve them. So this is where people started like using traditional solutions like mocking. So mocking is this one common thing that a lot of people talk about is that every time you're trying to like test a component that you don't have an exact like replica of, you can just mock around it. Like just create some mock classes in your application.

Write some unit tests, and maybe you're done. But as you go forward, you definitely need something more. You want to see the whole end-to-end workflow going on in your local machine. You want to run the integration tests, make sure that all of the components are working reliably and efficiently. And I guess this is where LocalStack comes in. The whole premise of the problem is that we want the developers to run their cloud applications on their local machine without having to spend so much of their time writing some mock test cases just relying upon plain mocking itself. Because trust me, just plain mocking does not solve a lot of use cases for them. So mocking was something that was used by Motu. So Motu is a unit testing library. I guess maybe I can share my screen if that's an option.

Japneet (LambdaTest) - So, I think some of the things when you were talking about the problems, I could totally relate to many things. So one of my experiences like whenever I am developing something and if I don't have access to technology like LocalStack, so the total dev effort and the dev cycle is again huge. So that is, I think that cycle is also being shortened by LocalStack. So if I'm using LocalStack, I can test more quickly and like I don't have to push my code again and again, I can test on my local system only. And that will also save a lot of time for development, even if I just want to test the end to end workflow. And with mocking, I think I can only test in units. So, but for integration and for the complete flow I cannot do that with mocking. So there are some limitations. I can achieve that but that again will require that amount of effort to build a system for that mocking thing. So I think the LocalStack has a very sweet spot here and fits perfectly fine with like talking about some problems.

Harsh (LocalStack) - Hmm. Yeah. So this is what I wanted to display. Motto is one of the most popular libraries out there. That simply allows the developers to mark out their tests on the AWS infrastructure itself. So in fact, LocalStack uses Motto under the hood. So we still work with Motto for a lot of the AWS services that we implement. And slowly, we are moving to more native providers. So we have a bunch of AWS services. And these AWS services are backed by different providers.

So some of these providers are reliant upon Moto. Some of these providers are written by ourselves. So if you're someone who just wants to mock out the test on your AWS infra, I guess Moto seems to hit the perfect spot. It has a great deal of support for a lot of different AWS services. But if you want to go with something more, then obviously LocalStack can be like one really good option.

So as the name pretty much suggests, like it's like a cloud emulator that basically runs on your machine as a Docker container. And it supports over 90 plus different AWS APIs. So among these AWS APIs, like there are various popular services like there is S3, Lambda, IAM, Kinesis, EKS, EC2, I guess one of the favorite services for any AWS developer around.

And you can pretty much run all of these different components right on your local machine. So that's the advantage that LocalStack provides. Now that everything is running on your local machine, you don't have to spend too much running your tests directly on the AWS itself. And the added advantage of using LocalStack is that we do not provide like pretty much production ready services like AWS does. Like if AWS is releasing out a service today, we can pretty much be ensured that, okay, this service can pretty much support like millions and maybe billions of users across the world. LocalStack is not exactly serving production workloads. It is more suited to like development and testing workloads.

And this is where LocalStack hits the right spot. You can basically use the services at a pretty agile speed. You don't have to wait too much on spinning these individual resources right on LocalStack, unlike AWS. And you can pretty much see your end-to-end dev and test loops happening in a matter of few seconds. You won't even have to wait for minutes and hours that you actually happen to see on the real AWS cloud itself.

So LocalStack had a pretty interesting history. Like it started as a open source project at Atlassian. And then it's been out as a separate organization in itself. And like in the past two years and so, like we started building out the whole pro version of Locustack that just supports additional APIs, more advanced new features, some of the development tools that we want the customers to adopt so that it's easy for them to build and test their cloud applications.

And yes, I guess that's pretty much like how LocalStack is helping out the developers to revolutionize their entire dev and test loops on AWS itself. We definitely have plans to shift to other major cloud providers. I guess Azure GCP happens to be one of these good options, but right now we just want to focus on like making sure that the entire AWS developer experience is kind of fixed for a lot of our customers and users.

Japneet (LambdaTest) - That's like the overall case study that the problem that LocalStack is solving is pretty interesting. And I think many developers will be like who are watching this webinar. So they will be really helped with all these things and they might use the free version of LocalStack initially to test out their products.

Harsh (LocalStack) - Exactly. And the free version has a lot of things. So you won't have to complain like some other like dev tools that, hey, free version is pretty much limiting and it has not a lot of features. Within the free version of LocalStack, you get to see like 30 different AWS services. So that's like more than enough for a beginner or a person who is looking to only test some basic components on LocalStack itself. So yeah, definitely try this out and let us know what your experience.

Japneet (LambdaTest) - So the second question that I have is, so I want to know about the examples of how LocalStack improves the dev and test experience for serverless applications specifically.

Harsh (LocalStack) - Yeah, that perfectly makes sense. So maybe I can just share my entire screen so that I can accommodate my VS code as well. So regarding the serverless application development, so for those particular use cases, local Slack already supports a lot of different AWS services. So maybe I can just navigate to my documentation. And if you're in the documentation, you can easily take a look at the Getting Started guide that has a pretty basic installation instruction.

And this will basically walk you through on how you can install LocalStack on your machine, what are the different options that are available to you, and how you can basically get started with the whole thing. So if it's your first time, it's definitely preferable for you to install the LocalStack CLI, because the whole CLI acts as a control plane for managing your LocalStack container and all of your configuration. So LocalStack is shipped entirely as a Docker container.

Like take a look over here. So our Docker container has been pulled almost 180 million plus times, which is pretty much like a good number itself. So you can either run LocalStack as a container itself, but if you just want a management tool that controls your containers and a bunch of different developer tools that are associated with LocalStack, definitely install LocalStack CLI on your local machine. And once you have that, you can just go on your terminal and just say LocalStack start. And I guess that will start the LocalStack server right on your developer machine. So I hope you are able to see my VS code right over here.

Yeah, so if you have installed LocalStack already, you can just go on your terminal or your command line, and you can just say, I want to start LocalStack, and you can just say the LocalStack start option. So this is what we are using. We are using the LocalStack CLI and passing on the start option. And this starts the LocalStack right on our local machine. So you can already see that I have version 2.3.2 installed on my local machine. And you can also see that LocalStack right now is running on port 4566. So this port 4566 is basically the edge port where the LocalStack is running right now. And this is where you can exactly access most of your AWS services running. So not most, like in fact, all of the AWS services are basically being routed through this particular edge port. So all that you need to do is like go on the separate terminal and you can just use the AWS CLI like right over here, I can use AWS endpoint URL, HTTP localhost 4566.

And what I'm basically doing is I'm using the AWS CLI and I'm passing this whole endpoint URL flag and I'm pointing this to localhost 4566. So AWS CLI, in fact, a lot of the AWS SDKs and other infrastructure as code integrations or other toolings, provide you an option of configuring this endpoint you are in. So basically you can instruct your AWS integration to say like, hey, I don't want to send my API request to the production AWS. I want to send it to a local running server. And in this case, it's localhost 4566. And over here, I'm instructing that, hey, I want to create like an S3 bucket and the name of the bucket should be S3 test. Maybe I can change it to Lambda test.

And once I hit enter over here, you can definitely see that a new bucket has been created pretty much on your local machine. So if I go to my terminal over here, you can see that there is a new log message saying that an S3 Create Bucket API has been sent out and the status code is 200. So this is exactly how it works. If you don't want to pass on this whole endpoint URL flag over and over again, you can just use a package called as AWS local.

And what AWS Local is, it's basically like a wrapper over the traditional AWS CLI. And it basically redirects all of the AWS API requests from the live production AWS server to the local running server that LocalStack is providing. So if I do AWS Local S3 LS, you can see that the bucket that I created previously is available right here over now.

So, yep, this is like a very quick getting started guide for LocalStack, I would say, if you're running LocalStack for the very first time. But now coming to the question of how LocalStack is helping out like serverless application developers. So, for serverless developers, we have a lot of different AWS services that we basically emulate. If you want to take a look at the different services, you can just go to the references and then navigate to the LocalStack coverage guide.

And over here, you can search for any given AWS services that we support. Like if I support for, let's say, the Lambda, you can take a look that Lambda is available in LocalStack. It's supported in the community open source version. And you can take a look at the different APIs that we implement and what's the test coverage for each one of that. Like in this case, you can see that the Create Function API is available.

It's available in the Community Edition. It has been validated by the internal test suite, AWS, snapshot testing, and a bunch of different options that we provide. In fact, you can navigate to the particular tests for this particular API, and you can get to see how this exact thing is pretty much working out. So this should give you a very added confidence about any of the serverless architectures or serverless applications that you're trying to build out right now. So in this case, I have a very basic example that I wanted to showcase.

So over here I have, yeah. So I have this whole serverless image resizer application that was built by the LocalStack team. And What this application basically does is like, it has this whole serverless architecture right over here. So as you can see, like we have two Lambda functions. We have three Lambda functions in fact. We have a pre-signed Lambda function. We have a list Lambda function. We have resize the Lambda function. We are integrated with SES to send out any of the field messages. We have a S3 bucket. We have a web client that is deployed by S3 website. And what it basically does is like, it's a very simple web application that allows you to resize your images in a serverless manner.

So it has a basic client and you can basically upload your images over there. And what will happen in the background is that the Lambda will generate a pre-signed URA and it will basically resize the image and it will display that on the client itself. So all of this is happening in a serverless manner and everything's like happening on the direct client itself.

You can either deploy this application on live AWS, but what I will be doing over here is that I will try to deploy this application on my running LocalStack instance. And this will pretty much happen on my local machine itself. I won't be talking to any of the real AWS APIs. And I won't need like I won't even need to have any internet connection, in fact, because LocalStack can work in an offline manner in a limited capacity. So what I'm going to do here is like I can navigate to my VS code. I can first shut down my LocalStack server. And I can restart it to have basically a fresh instance of my LocalStack container. So every time you stop the LocalStack container, all of the resources that you created previously are pretty much gone, they don't exist. So if I go back over here again, and if I try to query the buckets available in my local AWS environment, you will see like there are no buckets. Like in fact, AWS local won't be able to connect to LocalStack right now, because I have shut down the LocalStack container.

So what I'm going to do here is that I'm going to restart LocalStack, but with an extra configuration. And this would be extra course allowed origins. So I guess like as a developer, you might have encountered these course issues quite a long, lot of times. And LocalStack also has strict course policies implemented on its end. And to basically make sure that we can circumvent these kinds of requirements. We have a configuration that basically allows any particular application to connect to the running LocalStack container.

So if you want to know about like further of these operations over here, you can just go to the configuration page. And this will explain like a lot of different configurations that we allow to basically override certain behaviors in LocalStack or just change the whole aspect of like LocalStack as a container. So I can go to the Visual Studio code. I can say like, I'm allowing all of the origins to connect to my LocalStack container. And I can just say like, I want to start my LocalStack container right over here. And this is gonna restart it.

Now, all of my AWS services are pretty much ready. I guess it's also a good time to introduce the web application that we have. So LocalStack acts as a platform as a service, it basically is shipped as a Docker image that runs on your local machine. But we also have a pretty handy graphical user interface in form of a web application that you can basically use to manage and have an overview of some of the AWS resources that you're creating on your local machine.

And it has some extra added advantages. I guess one of the primary advantages that you can see over here is something called Stack Insights. And this is what we call as a standard API telemetry for your LocalStack container. So if I just click upon one of the Stack Insights over here, you can get to see what Stack Insights basically do is, it basically creates a very heuristic dashboard containing all of your AWS API calls, the AWS services that you have been using, the clients that you are using to connect with a LocalStack instance and what sort of API requests have failed and what sort of API requests have passed. So as an AWS developer or someone like who's working on these event-driven architectures and all of these kinds of stuff, this is very, very valuable for me because now I can use this information to basically judge like how is my application actually working out? What's actually happening beneath the hood? What sort of APIs is it calling? What sort of services is it using at the end? So let's go back to the Visual Studio code.

Japneet (LambdaTest) - Thank you.

Harsh (LocalStack) - So as you can see, like my LocalStack container is running right now. I do see like a few of the API statuses right here because I was just navigating through the stack insights. If I just go to my code right over here, you can see like I have a very simple code base. There is a simple front end client created over here using basic HTML and JavaScript. We have our lambda functions, the three lambda functions that I showcased before, the list, the pre-sign and the resize lambda function.

And I have a very handy deploy script right over here. So what I can just do is like, I don't need to like paste a lot of these things over here. I can just go and say like, hey, I want to just run this entire script that deploys a bunch of services, like a bunch of AWS resources right on my developer machine. So what it is happening beneath the hood is like, it's creating like a bunch of S3 buckets. It's creating like SSM parameters, creating some SNS topics, subscribing these topics out.

And then it packages our Lambda functions and starts creating these Lambda functions right over here. So this is exactly what the script does. It basically sets your entire application right on your local developer machine.

Japneet (LambdaTest) - Okay, so I think this is a pretty interesting use case, wherein we can actually see what is actually happening behind the scenes with the web application as well. So I think it is a very interesting way to see and visualize what is actually happening behind the scenes. I think it is very useful for developers and testers who want to see that.

As a developer, I can develop something, but if a tester wants to test it and wants to see that if the resources are properly created or not and if my code is messing up with something, I think that visualization can really help to black box the complete thing and visualize what is required. So I have one more question. So before proceeding to the next question, Harsh, just want to mention if, can you check if your storage is full because I just received a message from Pilverside that the storage is full.

Japneet (LambdaTest) - So I have one more question for you, Harsh, which is related to IAM policies. I think it is a pretty good question and like it is a very important part of developing while developing on crowd that is related to security and all those things. So can LocalStack emulate IAM policies locally as well? And can developers test their IAM security using LocalStack locally on their system before like before pushing something to the cloud.

Harsh (LocalStack) - Exactly. That sounds like a pretty good question. And this is something that a lot of people usually end up asking. So in my last demo, I was showcasing the whole script that I had written, and that used to deploy a lot of AWS resources. So in that particular script, you might have noticed this one thing. So maybe I can just share it all over again. So in this script, I shared this whole aspect that we have this role configured over here, and this is pretty much directing it to this 12 digit IAM account that we have right over here. So it doesn't exactly exist in real. It's just like an account ID that we are just using with LocalStack.

And similarly, we have a pretty much like an IAM rule mentioned over here. So as you might have guessed, LocalStack pretty much mocks the IAM rules and policies on your local developer machine. But with that said, you can actually test out your IAM policies and make sure that they are actually meeting all of those fringe end like constraints before you actually deploy to a live production environment. So in this case, we have pretty good docs over here. So maybe I can just go right here. And you can get to see we have pretty good IAM docs over here. And you can see how you can create your IAM roles, users, and policies right on your developer machine. But unless and until you're using this new feature called as enforcing IAM policies, you exactly cannot test if your IAM policies are policies are exactly adhering to each other.

So to basically make sure that you can test out the whole policies right on the developer machine, you can use this one flag call as enforce IM. You can set it to one. And what this will do is like LocalStack will basically enforce all of the IM policies on your local developer machine. And this means that if you are defining a particular resource with one IM policy, it won't be able to access the other resource unless and until it is explicitly allowed for that.

So to showcase this whole example, I guess I can go back to my sample application that I have and I can just stop the whole thing. And in this case, I don't need to showcase the whole web application, so I don't need to specify this extra setting right over here because I just want to showcase the whole deployment part. And what I can do is I can set enforce im LocalStack start. And what I'm basically doing is I'm enforcing the im policies over here.

If I'm trying to deploy any AWS resource that isn't strictly following the policy requirements that is laid out by AWS, it won't exactly deploy. I can also set up a debug variable, which is basically for verbose logging. I can just click enter. And this will start my LocalStack container with verbose logging. I guess this is the reason you are seeing so many logs over here. But it also enforces the IAM policies running in the LocalStack container right now.

So you can exactly see the IAM policy root generation routes are being added. Now things will get pretty much interesting over here. So I can go back to my second terminal. I can try to rerun the same command that I have shared before. And let me just press Enter. And what you will notice right now is that it is creating a bunch of AWS resources that is working out. But you can start noticing that things have started failing out pretty quick.

So it is mentioned like an error occurred, resource not found exception, when calling the create function URL config. Function does not exist. You can see some other errors that is happening on my local machine. And you can see like most of the commands that I have actually entered have pretty much error out. If I go back to my LocalStack logs, and if I just scroll down, you can see that the same logs are like, like the same logs are visible on my LocalStack logs as well. Resource not found exception an error has occurred when calling the Azure role operation. This particular user is not authorized to perform this particular API on this particular resource. So it basically means that my application is not strictly working out. And this is pretty much understandable because I have not explicitly defined any IAM policies or roles or users anywhere in my particular script. So this is exactly what we call as shifting left on IAM security because there are a great deal of tools, services.

SaaS products built entirely for scanning your policies, your roles, and all of these things out, and basically making sure that these things basically add to all of these strict requirements put forward by AWS. But there is no certain tool that allows you to test this whole setup on your local developer machine. But if you want to exactly test your IAM policies on LocalStack, I guess this is perhaps the best option that you can see if your application stack that has all of the proper roles, policies, and uses to fight.

Is it able to deploy everything on the logistic itself? And if it is, I guess you are pretty much like sitting at the right spot. But if it is not, and if your particular resource is trying to access another resource that it has no strict access to, things are going wrong and it is simply failing to add to all of the shared responsibility model that is put forward by AWS, which basically states that you are responsible for all of the application or the resources that you're creating on the AWS cloud.

So to basically make sure that you don't encounter this issue and you can actually try to fix this issue in like a more elegant manner, there is another config variable that is available. And this is called as the explainable IM. So as a name pretty much suggests, this actually explains what is exactly happening in that background and how you should exactly fix this out in plain, simple language so that you can actually take up the queue and you can try fixing those things out on your local application itself. So I can go back again, I can say enforce im is equal to one and I can also maybe state, I need to refer to the documentation. So yeah, I have got this imsoft mode. This is exactly what allows you to review the logs and access whether these resources have been denied or granted. And I can just put it right over here. Once this is done, I can enable the verbose logging and I can restart my LocalStack container.

And once this is done, I can try to trigger my entire deployment process all over again. In all of this, you might have noticed that it is so easy for me to deploy and redeploy all of my resources over and over again without having to wait for any transient issues or any connectivity issues or something like that. That usually happens while you're trying to deploy something on the Relatedless Cloud. So now that this has happened, I guess I can go back. I can re-trigger the script execution, and this will start the entire deployment process right over again.

Over here, you will notice that the same error messages that you noticed the last time, they are not exactly visible over here, because LocalStack is being instructed that, hey, let these commands actually execute. Let these work out the usual magic on the developer machine. But it will also give the instructions to the developers that, hey, this policy doesn't exist. You're trying to access a resource that you don't have explicit access to. So you can take up these cues, and you can try to fix a few things right on your local developer machine.

So you can see the same issues that you might have noticed previously. So one permission have been implicitly denied. This is a repermission for this particular action doesn't exactly exist. Could not retrieve the resource-based policy for this particular ARN that is available right over here. There is an error like the resource not found exception while you are using the get policy operation. So in a similar fashion, you can take up these cues and you can actually try to like fix your application out and you can make sure that everything is happening seamlessly both on your local developer machine and on the live AWS cloud. So I guess that pretty much explains how you can test out your IAM policies right on your local developer machine itself. I hope that answers the question.

Japneet (LambdaTest) - Thank you. Yes.So when you're actually explaining it, I was thinking about the time when I had, I have done some development and then things are not working and then I'm redeploying and then fixing the policies, but which could have been done with this like a complete setup on the local system only, and we don't have to iterate it again back and forth between AWS deploying again and get, yeah.

Harsh (LocalStack) - Exactly. Yeah. So for normal Dev and Test tubes, I guess it's perfectly all right to not have these explicit IM policies being enforced. But for any of the teams that are that is looking to have more aggressive security posturing, I guess it perfectly makes sense to test out these IM policies right on the developer machine so that you can be sure that if something goes on the cloud, no real mess-ups are happening over there. And there are a great deal of software that basically allows you to test that access the threads, access the vulnerabilities, and all of these things. But you should ideally start right from the developer machine itself.

Japneet (LambdaTest) - And it is like, I think with the high and highly secure applications, I've been talking about the banking software or the industries where in like these policies are actually very important. So I think it is pretty useful tool for that. And like it will short circuit that approval flow for like, if you need approval for multiple policies so you don't have to go one by one you can just have a complete set of actions and you can test it on your system and then you can go for the approvals.

Harsh (LocalStack) - Exactly. The best part about it is like almost every software team is adopting stuff like infrastructure as code or like other third-party integrations. So like your entire application can be packaged by something like Terraform or CDK or CloudFormation. So all that you need to do is like set up a flag just deploy this entire IEC stack on LocalStack itself and it will tell you like Okay, these are the policies that are violating these are the policies like that is simply erroring out And you can take up these queues and you can start fixing them out.

I guess that makes the whole security aspect of your application development pretty much good to go with. And you don't need to have separate people working on fixing your IAM policies or something like that. Developers can happen to see this right on your developer machines.

Japneet (LambdaTest) - So, I think we have this last question. So how seamlessly does LocalStack integrate with HyperExecute, which is an offering from Lambda test or a similar test execution provider and what benefits can team expect regarding testing speeds and reliability.

Harsh (LocalStack) - Exactly. I guess that's like that's like, this is something that I just experienced with Lambda test right now. So I guess HyperExecute was introduced to me by one of my colleagues at LocalStack. I guess he was working with Lambda test to basically drive this whole integration. And we're really thankful to Lambda test for the support that they have provided for our own Terraform modules testing. So I tried out Lambda test for the first time and I was simply mind blown because the whole testing speed it's much, much faster compared to anything that I've experienced before. So in any other execution provider, I don't know any particular SAS or any other toolings over there. I just use these plain, good old CI providers like GitHub Actions or GitLab. But even in comparison to that, I guess HyperExecute just makes the entire testing experience pretty much seamless and quite fast as well. So I actually have one of the HyperExecute files on my developer machine itself.

So I hope it should be visible again. Yeah, so I have this whole HyperExecute file like right on my local project. And I guess like it makes the whole process like quite seamless. Like I'm just like setting up this Linux environment over here, like setting up a pre-install script for installing LocalStack, installing all the dev dependencies, configuring the API keys and just run this script which deploys all of the AWS resources that I require. And the best part is like I can also run my test cases that is associated with this particular application. So I have this HyperExecute script and I have a GitHub action workflow that just executes the whole thing right on the HyperExecute environment. And if I just, let's say I can just go over here, I can maybe go to the script, just make like a random comment.

Let's see, I'm trying to do a pretty dangerous operation of pushing directly to the main branch, but I'm just doing this for testing just a basic thing out. So I can just go back to my Lambda test dashboard. So I did run a few quick tests over here. But I guess one of the best things about, okay, so this will be getting triggered in some time. Let me just go back to my fort that I created before.

Japneet (LambdaTest) - I can see it on the dashboard.

Harsh (LocalStack) - Awesome. Yes, it is available on the dashboard right now. So one of the best things about using something like HyperExecute is that you also have this local execution capabilities. So I'm not sure what's the exact terminology that you use at Lambda test you need. But if I can just say, OK, I want to execute this whole thing right on my developer machine, I guess I should just scrub off the key over here, maybe just rotate it out.

This is one of my favorite features for HyperX. It is like I can just use this entire stuff on my local machine itself without having to push any sort of code and just get to see how well it is exactly working out. And this is something that very few CI providers actually provide. For GitHub Actions, we have something like act. For GitLab, I guess we have got these GitLab CI runners that can act on your local machine.

There is, I guess, Codefresh that basically provides you these local executors to basically run your SIA on your local machine. But it is so good to basically see Lambda test supporting this as well. So I guess if I can just go back to my Lambda test dashboard, so I guess I created just two jobs over here, I can click one of them. And I can see the pre-steps are pretty much successful. OK, it's still running out. So over here, it is setting up the whole thing.

And then it will just start setting up the pre-installed script, which involves installing LocalStack, configuring the deploy script, deploying with the resources and all of these over again. But I guess you'll get the gist. HyperExecute basically allows you to run your AWS application tests using LocalStack right on the Lambda tests, automated execution environment. And I guess this makes a lot of capabilities quite possible.

I guess we have been seeing this whole HyperExecute working out pretty well for us for our own Terraform provider test. And things have been getting really, really fast right over there. So really thankful for all the support you have needed. And I hope a lot of people get acquainted with HyperExecute and start using it for their regular software test execution workflows.

Japneet (LambdaTest) - So I think one thing I would like to add is, so basically what LocalStack has done to AWS, it has made testing easier on the local system. That is something HyperExecute has done to the testing world. So basically it has removed that KVR of testing on your local machine because we have many variables when we are testing locally.

There are like when we say that it works on my machine and not works on someone else's machine. So we remove that kind of thing and like it is very flexible and you can run like any anything that you want on the HyperExecute platform. We basically provide you the entire machine. You can set it up and do all that stuff and like it was very nice to see local staff running even the Terraform scripts on HyperExecute.

Harsh (LocalStack) - Exactly. Awesome. It's running on my local machine as well. I guess this is one of the mind blowing moments when you actually see that there is a text execution platform that also runs on the cloud and that also runs on your local machine. So pretty awesome stuff.

Japneet (LambdaTest) - I think so like with this I think we are towards the end of the session and I think it was a very illuminating session and like people must be enlightened with the knowledge that you have shared and I think most people will be like looking forward to like use LocalStack and HyperExecute like to integrate them all in this all this into their ecosystem.

And to our audience, we hope that you have gained valuable insights into testing AWS applications with LocalStack and apply this knowledge to elevate your cloud development practices. And thanks again for joining the session. So I am Japneesingh Chawla signing off. We'll be back with another episode of LambdaTest XP series. Very soon. Stay tuned with us.