DEV Community: Unmesh Gundecha

[Boost]

Unmesh Gundecha — Fri, 02 Oct 2026 12:02:39 +0000

Unmesh Gundecha

Oct 2

Develop and test locally: introducing Awesome Cloud Emulators

#cloud #aws #azure #gcp

4 min read

Develop and test locally: introducing Awesome Cloud Emulators

Unmesh Gundecha — Fri, 02 Oct 2026 11:02:52 +0000

An engineer needs a cloud account to test a change. Another engineer is already using it. Someone updates a shared resource, a test fails, and the team spends the afternoon determining whether the problem lies in the code or the environment.

Meanwhile, resources left running between test runs continue to add to the bill.

These are familiar problems in cloud development. They are also part of the reason I created Awesome Cloud Emulators: a curated list of cloud emulators and supporting tools for local development and automated testing.

My aim is to make it easier to discover the available options, understand their boundaries, and choose something that fits the work you need to do.

Bring more of the feedback loop closer to engineers

Cloud emulators reproduce selected cloud service APIs and behavior locally. Depending on the tool, you might run one as a container, a standalone server, or an in-process dependency in your tests.

That can give you a dedicated environment to check application interactions with storage, queues, databases, and other supported services. You can create test resources, exercise a workflow, and clean up without coordinating every change through a shared cloud account.

There is a cost benefit too. Moving suitable development and CI workloads locally can reduce repeated provisioning, idle cloud resources, and billable service calls. The savings depend on the workload: local compute, maintenance, and any software licensing still have costs.

For me, the useful question is: which checks can we run earlier, more often, and with less setup?

What you will find in the repository

The list covers AWS, Microsoft Azure, Google Cloud and Firebase, Oracle Cloud, Cloudflare, Snowflake, and tools spanning multiple providers, including European cloud providers.

It separates broader suites from tools focused on individual services. A few examples illustrate the range:

Area	Examples in the list	Focus
AWS	Moto, ElasticMQ, S3Mock	AWS API mocking, SQS-compatible messaging, and selected S3 operations
Azure	Azurite, Azure Key Vault Emulator	Local storage and Key Vault client testing
Google Cloud and Firebase	Firebase Local Emulator Suite, Fake GCS Server, Spanner Emulator	Local Firebase workflows and selected storage or database APIs
Cloudflare	Miniflare	Local Workers simulation and supported storage bindings
European providers	Feint	API emulation for Scaleway, Outscale, and Exoscale

These examples are starting points to investigate. Each entry links to upstream documentation so you can check the operations and requirements that matter to your application.

The repository also includes a selection guide with scenario-based shortlists, a comparison of the entries, and an evaluation checklist.

The supporting tools matter too

An emulator is only one part of a local development workflow. You still need to start it, connect your application, prepare data, and manage its lifecycle.

The supporting tools section includes:

Testcontainers integrations for managing supported emulator containers from tests.
AWS SAM CLI, Azure Functions Core Tools, and Serverless Devs for local function development and execution.
Toxiproxy for injecting network latency and connection failures between an application and an emulator.
Moto Recorder for recording and replaying requests to rebuild test baselines.
CRIU, DMTCP, and container checkpoint tools for exploring capture and restore of prepared environments, subject to compatibility checks.

These tools have different roles. A local function runner does not automatically emulate the services the function calls, and request replay is different from restoring process memory. The descriptions make those distinctions explicit.

Choose based on your test scenario

Before choosing a tool, write down the workflow you need to validate.

For example: an application writes an object, publishes a message, and a worker processes it. That gives you a concrete set of operations and interactions to evaluate.

Then check:

Does the emulator support the API operations your application uses?
Does it work with your SDK or IaC provider version?
Can each test or worker have isolated state?
How do you prepare, reset, and clean up resources?
Which failure paths can you exercise?
What runtime, licensing, and access requirements apply?

For IaC workflows, also distinguish between accepting a resource definition and running the resulting workload. An API simulation may accept a request to create infrastructure without providing a working VM, database, or network behind it.

Keep real-cloud validation in the workflow

Emulation has limits. Passing locally does not establish full service parity or prove production behavior.

Identity and authorization, networking, quotas, consistency, and managed-service behavior can differ. Keep targeted tests in a controlled cloud environment for the guarantees your application depends on.

The value of local testing is a faster feedback loop, paired with a clear understanding of what still needs cloud validation.

Open source first, with transparent licensing

The repository prioritizes open-source tools. Within each section, they appear before other distributions and paid or commercial products.

Commercial tools are included where relevant to help readers compare options. Inclusion does not imply endorsement or a recommendation to purchase.

The list also distinguishes 💰 paid commercial conditions from 📜 vendor-specific terms, because software terms do not necessarily mean a fee is required. Unmarked tools still have licenses, and upstream terms should always be checked.

Help improve the list

I would like this to become a useful community reference for developers, testers, and cloud engineers.

If you use an emulator that is missing, spot an inaccurate description, or know an important limitation, please open an issue or contribute a pull request. The contribution guide explains what to include, such as upstream evidence, limitations, and any affiliation.

Explore Awesome Cloud Emulators on GitHub.

Which cloud dependency causes the most friction in your local development or testing workflow—and what have you found that helps?

If you find this useful, give the repo a ⭐ and share it with your colleagues and network to help more teams discover it.

AWS services for SREs

Unmesh Gundecha — Thu, 27 Oct 2022 04:44:26 +0000

SREs using the AWS platform have access to a wide range of tools for creating, running, and managing systems & services in the cloud. This blog post examines some of AWS's essential services and features that SREs can utilize.

Amazon CloudWatch

Monitoring and observability is a crucial tenets of System Reliability Engineering (SRE). The AWS CloudWatch is a monitoring service available in the AWS platform to SREs for effective monitoring of systems and services. It enables SREs to watch and understand the state of their systems. Monitoring is based on gathering predefined sets of metrics or logs. Observability enables SREs to debug their system actively. AWS CloudWatch is the most popular and essential monitoring solution in AWS.

SREs can monitor and manage on-premises, hybrid, and AWS application or resource with the Amazon CloudWatch. CloudWatch offers data and valuable insights. Instead of keeping track of them separately, SREs can gather and access all of operational and performance data from a single platform in the form of logs and metrics (server, network, or database). Applications, infrastructure, and services can all be monitored with CloudWatch, and SREs can leverage alarms, logs, and events data to automate actions and speed up mean time to resolution (MTTR).

You can find more about AWS CloudWatch here

AWS Systems Manager

Driving Toil out of the system is another key tenet of SREs. The term Toil refers to tedious, repetitive tasks associated with running a production environment. Site Reliability Engineering (SRE) teams strive to minimize or even eliminate Toil to maximize the time spent on engineering and innovation.

AWS Systems Manager enables SREs to automate processes across AWS resources and centralizes operational data from several AWS services. SREs can arrange resources into logical categories, such as apps, various application stack layers, or development and production environments. The resource group's current API activity, resource configuration changes, related notifications, operational alerts, software inventory, and patch compliance status may all be viewed in Systems Manager by selecting the resource group.

You can find more about AWS Systems Manager here

AWS Systems Manager Incident Manager

Performance problems and unplanned outages can happen to systems, online applications, servers, devices, etc., at some point. For SREs, it is anticipated such failures will occur, and they cannot be avoided as a fact. Moreover, these unexpected failures can result in significant revenue losses, a loss of customer confidence, and, depending on the industry sector, possible fines. Therefore, SREs use incident management as one of the fundamental techniques to reduce the disturbance brought on by unforeseen problems.

The AWS Systems Manager Incident Manager service enables incident management for SREs.

Critical application availability and performance issues can be resolved more quickly with the Incident Manager from AWS Systems Manager. Automatic reaction plans that coordinate the appropriate on-call engineers and information aids SREs in incident preparation. For example, when a significant issue is discovered by an Amazon Eventbridge event or an alarm from Amazon CloudWatch, it can automatically respond with Incident Manager. In addition to executing AWS Systems Manager Automation runbooks, Incident Manager links selected chat channels using AWS Chatbot and activate pre-configured response plans to engage responders via SMS and phone calls. By recommending post-event action items like automating a runbook step or adding a new alert, Issue Manager, which was developed at Amazon based on decades of experience in incident response and analysis, aids SREs in increasing service reliability.

You can find more about AWS Systems Manager here

Amazon Managed Service for Prometheus

Prometheus is a popular monitoring tool for microservices, distributed systems, and container workloads.

Amazon offers managed service for Prometheus for monitoring and alerting, offering information and valuable insights for container environments that are widely used. SREs can gather and access performance and operational data from container workloads running on AWS and on-premises using Amazon Managed Service for Prometheus. The well-known open-source Prometheus project from the Cloud Native Computing Foundation (CNCF) is entirely compatible with Amazon Managed Service for Prometheus. As Prometheus is an AWS-managed service, it makes it easier to deploy and set up Prometheus. In addition, it automates many routine operations and maintenance for SREs.

Amazon Managed Service for Prometheus automatically adapts when the container workloads scale up and down to provide cost-effective performance metrics and reliable query response times.

You can find more about AWS Managed Prometheus here

Amazon Managed Service for Grafana

SREs need operational dashboards that connect them with monitoring and observability tools to visualize system performance, key metrics, and alerts.

Based on open-source Grafana, Amazon Managed Grafana is a highly scalable, highly available, and fully managed service that offers interactive data visualization of operational and monitoring data. SREs can view, analyze, and set alarms on crucial metrics, logs, and traces gathered from various data sources in the observability system, including AWS, third-party ISVs, and other resources across environments and applications using Amazon Managed Grafana. By automating scalability compute and database infrastructure as usage demands increase, with automated version upgrades and security patching, Amazon Managed Grafana offloads the operational management of Grafana.

You can find more about AWS Managed Grafana here

AWS Fault Injection Simulator

SREs aim to minimize downtime and ensure that systems operate as planned. One of the critical objectives of SRE teams is to ensure that systems can maintain their Service-Level Objectives (SLOs), which are the particular metrics SRE teams target to achieve the business SLAs, and Service-Level Agreements (SLAs), the system uptime provided to consumers.

SRE teams get important system dependability insights by introducing actual failures within the confines of a chaos engineering experiment. These insights wouldn't be possible through solely theoretical modeling. SREs can apply the real post-incident procedure to real system outputs to acquire a more realistic perspective of the system's condition and capabilities rather than dealing with hidden infrastructure flaws that can lead to incidents—or, worse still, running into them during incident.

AWS Fault Injection Simulator (FIS) is a fully managed service for running chaos engineering experiments to improve an application's performance, observability, and resiliency. FIS simplifies setting up and running controlled experiments across various AWS services so SREs can build confidence in their application behavior.

SREs can use AWS FIS for defining and running Chaos Engineering experiments to build resilient systems and services.

You can find more about AWS Fault Injection Simulator here

How They SRE

Unmesh Gundecha — Wed, 17 Feb 2021 14:07:37 +0000

I’m curating engineering blog posts, videos, and other cool resources on Site Reliability Engineering and DevOps in a GitHub repository:

https://github.com/upgundecha/howtheysre

More Selenium4 Goodies

Unmesh Gundecha — Mon, 14 Oct 2019 14:00:04 +0000

After my previous post on Selenium 4 Relative Locators, I further explored Selenium4 features and found a few more goodies in WebElement and WebDriver interfaces.

Element Screenshots

Yes, now we can capture screenshot of an individual element or group of elements. This is a very useful feature.

The WebElement interface now supports getScreenShotAs() method by implementing the TakesScreenshot interface to capture a screenshot of the element.

This method accepts the OutputType argument and screenshots can be captured as FILE, BYTES or BASE64 string.

Let's try to capture screenshot of a link and the search box displayed on Google Search Home page:

// find the Images link on Google Search home page
WebElement imagesLink = driver.findElement(By.linkText("Images"));

// take a screenshot of the link element
File linkScr = imagesLink.getScreenshotAs(OutputType.FILE);
FileUtils.copyFile(linkScr, new File("./target/linkScr.png"));

We can also capture a group of elements by taking a screenshot of the parent element. Here is a complete example capturing the Images link and the search box:

@Test
public void elementScreenShot() throws IOException {

    // find the Images link on Google Search home page
    WebElement imagesLink = driver.findElement(By.linkText("Images"));

    // take a screenshot of the link element
    File linkScr = imagesLink.getScreenshotAs(OutputType.FILE);
    FileUtils.copyFile(linkScr, new File("./target/linkScr.png"));

    // find the Search box which is a <form> element
    WebElement searchBox = driver.findElement(By.id("tsf"));

    // take a screenshot of the Search box
    File searchBoxScr = driver.findElement(By.id("tsf"))
            .getScreenshotAs(OutputType.FILE);

    FileUtils.copyFile(searchBoxScr, new File("./target/searchBox.png"));

}

The new `getRect()` method

The new getRect() method is introduced in WebDriver interface which is essentially a combination of previous getSize() and getLocation() methods. Here's a difference between previous methods and new the getRect() method which returns a Rectangle object:

@Test
public void elementRectTest() {

    // find the Images link on Google Search home page
    WebElement imagesLink = driver.findElement(By.linkText("Images"));

    // previous getSize() and getLocation() methods
    Dimension elementSize = imagesLink.getSize();

    System.out.println("Element height is " + elementSize.getHeight());
    System.out.println("Element width is " + elementSize.getWidth());

    Point elementLocation = imagesLink.getLocation();

    System.out.println("Element X Pos " + elementLocation.getX());
    System.out.println("Element Y Pos " + elementLocation.getY());


    // new getRect() method
    Rectangle elementRect = imagesLink.getRect();

    System.out.println("Element height is " + elementRect.getHeight());
    System.out.println("Element width is " + elementRect.getWidth());
    System.out.println("Element X Pos " + elementRect.getX());
    System.out.println("Element Y Pos " +  elementRect.getY());

}

New additions in WebDriver

In addition, to maximize() method, the browser window can now be made fullscreen by using the new fullscreen() method:

driver.manage().window().fullscreen();

A new parentFrame() method is added for navigating between frames.

driver.switchTo().parentFrame()

I'm not really sure if this is completely new feature (or maybe I'm too lazy to go through the changes) but we can now create a new empty tab or new browser window by using the newWindow() method.

driver.switchTo().newWindow(WindowType.TAB);
driver.switchTo().newWindow(WindowType.WINDOW);

That's it for now. I'll deep dive into new Selenium Grid features in an upcoming post.

Closing note

These features are in alpha release and subject to change in future. Please use with caution. You can find the complete code example from this post in my GitHub repo https://github.com/upgundecha/selenium4

Gherkin Dialects

Unmesh Gundecha — Sat, 12 Oct 2019 01:47:07 +0000

One of the core principles of Behaviour Driven Development (BDD) is having meaningful conversations to describe the behaviour of the software with concrete examples.

…having conversations are more important than capturing conversations is more important than automating conversations. – Liz Keogh

BDD practitioners have a choice to select a language that is commonly used and understood by the team to describe the behaviour of the software.

Gherkin, the ubiquitous language used by BDD practitioners to describe the behaviour of software, has been translated to over 70 languages.

In order to allow Gherkin to be written in a number of languages, the keywords such as Feature, Background, Scenario, Scenario Outline, Given, When, Then, And, But, Examples have been translated into multiple languages. Find more about the languages supported by Gherkin and keywords translated in these languages at https://cucumber.io/docs/gherkin/reference/#overview

Some of these keywords have more than one translation to improve readability and flow.

Let’s take a personal loan calculator application. The feature and scenario are described in the English language as below:

Now, let’s translate the behaviour of a personal loan calculator in Hindi (one of my native languages):

Automating conversations with Cucumber

Cucumber framework, the widely used tool by BDD practitioners supports Gherkin dialects.

A # language: header on the first line of a feature file tells Cucumber what spoken language to use while generating step definitions.

To automate this feature and scenario, Cucumber will generate step definitions in the selected language. In this example, it uses Hindi as shown in below code:

In this case, both Cucumber and Java support internationalization and example is automated with Selenium WebDriver, navigating to the Hindi version of the personal loan calculator and checking the behaviour of the software.

Along with Java, the Gherkin dialect (i18N) support is available in supporting programming languages such as Ruby, Python, Go, DotNet, etc.

The working example is available in GitHub Repo https://github.com/upgundecha/cucumber-gherkin-hindi

Selenium4 Relative Locators

Unmesh Gundecha — Wed, 02 Oct 2019 14:21:41 +0000

Selenium 4 alpha-3 is released yesterday with much-awaited friendly locators, now called as relative locators feature. These new locator methods will find elements based on their location relative to other elements, visually! You can find the desired element or elements by passing withTagName method along with near, above, below, toRight and toLeft methods. These methods take the relative WebElement or By locator as an argument. The overloaded near method takes the pixel distance as an additional argument. I did a trial run of this cool new feature on a sample app:

In the sample application, to find the input field which is right of the label Hight in Centimeters, we'll first locate the label using the By.cssSelector method. Next, we will use the located element to find the input field. For this we will call the withTagName method along with rightOf method passing the label WebElement as shown in below snippet:

WebElement heightLabel = driver.findElement(By.cssSelector("label[for='heightCMS']"));

WebElement heightInput =  driver.findElement(withTagName("input")
        .toRightOf(heightLLabel));

heightInput.sendKeys("181");

We can also combine the relative locator methods to narrow down the search as shown in below code to find the input field to enter weight. The weight field is below hight input and right of weight label:

WebElement weightInput =   driver.findElement(withTagName("input")
        .below(heightInput).toRightOf(weightLabel));

The new locator methods will be very handy to find elements based on their relative location on the screen.

Selenium uses JavaScript method getBoundingClientRect to find the elements using Relative Locators.

You can find the example test in my GitHub repo https://github.com/upgundecha/selenium4

If you want to know more about these new locators and sample usage, find more details in Selenium test base (tests are living documentation).

Closing note

The relative locators should be used wisely when other methods won't work. The features in alpha releases may change in future releases. Also, these methods may not work well on overlapping elements.

This is not an entirely new concept. There are other tools in both commercial and open-source space offering similar features to locate element based on visual cues.

DEV Community: Unmesh Gundecha

[Boost]

Develop and test locally: introducing Awesome Cloud Emulators

Develop and test locally: introducing Awesome Cloud Emulators

Bring more of the feedback loop closer to engineers

What you will find in the repository

The supporting tools matter too

Choose based on your test scenario

Keep real-cloud validation in the workflow

Open source first, with transparent licensing

Help improve the list

AWS services for SREs

Amazon CloudWatch

AWS Systems Manager

AWS Systems Manager Incident Manager

Amazon Managed Service for Prometheus

Amazon Managed Service for Grafana

AWS Fault Injection Simulator

How They SRE

More Selenium4 Goodies

Element Screenshots

The new getRect() method

New additions in WebDriver

Closing note

Gherkin Dialects

Automating conversations with Cucumber

Selenium4 Relative Locators

Closing note

The new `getRect()` method