Before we dive into the details of building agents, let’s review what we consider an “agent”. Referencing Anthropic’s Building Effective Agents blog, we can think of an agent as a system that uses an LLM to take actions toward a goal, often by reasoning over context, making decisions, and interacting with external tools or data sources.
Anthropic highlights a distinction between:

Workflows — Prescriptive sequences where the LLM follows a predefined, often linear path. They are structured, predictable, and tightly scoped.

• A backfill workflow may process a very specific type of support ticket with a fixed series of steps (identify impacted customers, issue refunds, send notification emails.)
• A daily briefing workflow may review all of your email, check your meeting schedule, determine the highest priority items on your agenda, and generate a summary for you.

Agents — More flexible, adaptive systems that can decide what steps to take next based on evolving information, user input, or intermediate results. Agents can be highly autonomous or lightly guided, but the defining trait is their ability to choose actions dynamically rather than strictly follow a static script. Examples:

• A support agent may process any ticket in a queue, and decide whether to execute some mitigation, escalate the ticket to a human, or gather more data before responding.
• A coding agent (Cline/Cursor/Q CLI) may take a prompt from a user, and decide whether it can immediately write code, or read files from the existing project, or do research on the web, or write a design before implementing anything.

Why Developers Build Agents

From a developer’s perspective, there are a few compelling reasons to build an agent instead of (or alongside) more traditional workflows:

1. Dynamic Problem Solving
   Agents excel in environments where the “right” sequence of steps can’t be fully determined in advance — for example, debugging an unfamiliar error, triaging customer issues, or planning a multi-step research task.
2. Integration with Tools and APIs
   Agents can call APIs, run code, query databases, and trigger actions in other systems.
3. Adaptability and Context Awareness
   By keeping track of state and re-evaluating as they go, agents can pivot mid-task if new information changes priorities.

Why Use AWS Strands to Build Agents?

While you can build agents with various frameworks, AWS Strands offers distinct advantages for developers:

• Simplicity: Build functional agents with minimal code. No complex framework setup or boilerplate required.
• AWS-Native: If you’re already running in AWS, you can easily leverage native services like Bedrock, Lambda, and CloudWatch.
• Extensibility: Easily integrate custom tools and services. The tool decorator pattern makes adding new capabilities as simple as writing a function.
• Scalability: Deploy the same agent code from local development to production-grade infrastructure including AWS Lambda and Fargate.
• Observability: Built-in support for tracing, logging, and monitoring agent performance via OpenTelemetry (and X-Ray if you’re running in AWS.)

Getting Started: Step-by-Step Guide

Prerequisites

Before diving in, ensure you have the following:

• Python 3.10 or higher: Strands requires Python 3.10+.
• AWS CLI + AWS Account with Bedrock Access
• Make sure your account has enabled access to the desired models via Amazon Bedrock. Strands will use Claude Sonnet 4 in us-west-2 by default.
• See https://strandsagents.com/latest/documentation/docs/ for details.

Environment Setup

You’re welcome to do this in an IDE, but I’ll outline the steps explicitly via command line to keep it as simple as possible.

Create a Project Directory:

mkdir strands_agent_demo
cd strands_agent_demo

Set Up a Python Virtual Environment:

python3 -m venv venvsource venv/bin/activate

Install Strands Agents SDK:

pip install strands-agents strands-agents-tools

Create Your First Agent

Create a Python File:

touch agent.py

Add the Following Code:

from strands import Agent
# Create an agent with default settings
agent = Agent()

while True:
    # Get user input
    user_input = input("\nYour question: ")
    if user_input.lower() in ["exit", "quit", "bye"]:
        print("Goodbye!")
        break
    # Send the input to the agent, which will automatically print the response
    print("\nThinking...\n")
    agent(user_input)

Run the Agent:

python agent.py

Upon execution, the agent will ask for your input and process your query using the default model.

Try a question that’s difficult for LLMs to answer, like long division: “What is 123,456,789 divided by 123?” Notice you’ll get an answer that’s close, but not quite correct.

Add a tool that the agent can use as needed

from strands import Agent, tool

@tool
def calculator(expression: str) -> str:
    """Evaluates simple math expressions.
    This docstring is used by the LLM to understand the tool's purpose.
    """
    result = eval(expression)
    return f"The result is: {result}"
# Create an agent and add the calculator tool
agent = Agent(tools=[calculator])
while True:
    # Get user input
    user_input = input("\nYour question: ")
    if user_input.lower() in ["exit", "quit", "bye"]:
        print("Goodbye!")
        break
    # Send the input to the agent, which will automatically print the response
    print("\nThinking...\n")
    agent(user_input)

Run the agent again, and ask it what tools it has access to:

Now try the math question again. Watch as the agent determines that it should use the tool to solve the problem.

Try some of Strands’ built-in tools

Reference full list of provided tools. Examples:

• Want your agent to be able to execute python code? Import the tool and add it to your agent:

from strands_tools import python_repl
agent = Agent(tools=[calculator, python_repl])

• How about general command line capabilities? Use the shell tool:

from strands_tools import shell
agent = Agent(tools=[calculator, shell])

See a Pattern?

You’re not defining explicit logic to enable new capabilities, you’re only providing the agent with additional tools, and letting it reason on how to use them to meet the goal you provide in your prompt.

Next Steps

With your first agent up and running, consider exploring some more advanced patterns:

• Want to expose an agent as a tool? Just wrap it in a function with a tool decorator, and add that tool to your primary agent. This is a common method of context engineering — keeping your primary agent’s context window focused on what’s important to it, and delegating sub-tasks to sub-agents.

CODE_AGENT_PROMPT = """
You are an agent that writes Python code using best practices in Python.
Only output the Python code and nothing else.
"""

@tool
def code_generator(task: str) -> str:
 “””
 Generates Python code from a task description
 Args:
 task: Given task by user
 Returns:
 Generated Python code
 “””
 try:
   agent = Agent(system_prompt=CODE_AGENT_PROMPT)
   result = str(agent(f”Complete the task: {task}”)).strip()
   return result or “Could not generate code. Please provide more context.”
 except Exception as e:
   return f”Error generating code for task ‘{task}’: {e}”

• Want to use an MCP server? It’s very straightforward to initialize the MCP client, fetch the tools, and add them to the agent. In this example, we add all the tools to the agent, but you can also pick and choose only those that you need (don’t forget, each MCP tool consumes tokens in your context.)

from mcp import stdio_client, StdioServerParameters
from strands.tools.mcp import MCPClient

# Connect to an MCP server using stdio transport
your_mcp_client = MCPClient(lambda: stdio_client(
 StdioServerParameters(command="uv", args=[
 " - directory",
 "/directory_your_mcp_server_lives_in",
 "run",
 "name_of_server"])))
 
# Create an agent with MCP tools
with your_mcp_client:
 # Get the tools from the MCP server
 tools = your_mcp_client.list_tools_sync()
 
 # Create an agent with these tools
 agent = Agent(tools=tools)

Additional Resources:

• Strands Agents Examples
• Quickstart Guide

What is MCP, and why should you care?

If you’re a software engineer trying to integrate generative AI into your workflow, you’ve probably experienced the frustration of constantly switching between tools like Claude, Word or Docs, local files, your IDE, and Google — endlessly copying and pasting prompts and outputs along the way. With new AI tools popping up daily, it’s tough to know which ones genuinely simplify your workflow.

Enter Model Context Protocol (MCP).

MCP simplifies how your applications interact with large language models (LLMs) by providing a standardized way to manage prompts, context, and responses. Think of MCP like REST for language models: it offers a single, consistent way to communicate with any LLM, abstracting away complexity so you can spend less time context-switching and more time coding.

Here’s an example to illustrate the value. Let’s say you have workflow where you:

• Use Claude to help break down a large project into incremental stories
• Take each story and add it to a JIRA project
• Search a wiki for relevant context for each task and append it to the JIRA story.

Between each step there is manual effort. Without MCP, you could try to string this all together programmatically, but you’ll need to manage multiple API integrations and write a lot of code.

With MCP, you can expose an MCP server that wraps integration with these tools, and then use plain text prompts like the workflow above and the LLM will leverage the tool integrations naturally during the conversation. Let’s get hands-on and quickly build an MCP to get a better understanding of how this works.

Build an MCP Server in 5 minutes

Prerequisites (running on macOS):

Install uv (Python package and project manager)

• brew install uv (preferred, requires homebrew)
• If you don’t use homebrew, you can run the following command to install uv, but I had trouble getting the Claude Desktop App to launch the MCP server with this method: curl -LsSf https://astral.sh/uv/install.sh | sh

Install Python (minimum version 3.10, I’m using 3.12)

• uv install python

Open your favorite terminal app and follow the commands below to create a new python project and add the official python MCP SDK as a dependency.

# navigate to your preferred working directory
cd ~/workplace

# create the project
uv init mcp_demo
cd mcp_demo

# add the MCP package as a project dependency
uv add "mcp[cli]"

We’ll build a simple server to enable an LLM to access a local text file on your machine and append ‘todo’ items.

Open main.py, delete the contents, and replace with the below code. Feel free to edit the hard-coded filepath to your liking:

from mcp.server.fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("Demo")


# Add a tool to append TODO items to a local file
@mcp.tool()
def append_todo(todo_item: str) -> str:
    """Append a TODO item to a local markdown file."""
    filepath = "/Volumes/workplace/mcp_demo/todos.md"
    try:
        with open(filepath, "a") as file:
            file.write(f"- [ ] {todo_item}\n")
        return f"Successfully appended TODO: '{todo_item}'"
    except Exception as e:
        return f"Failed to append TODO due to: {e}"

From the same directory in your terminal (~/workplace/mcp_demo in my case), run mcp dev run main.py to launch the official MCP Inspector app (this is a great tool that simplifies testing MCP servers.) Navigate to http://localhost:6247 in your browser, and you should see this screen:

Click Connect, then Tools, then List Tools. You should see the append_todo tool that we created; click on it, and you’ll get the option to enter text and run the tool. Give it a try by entering some text and cliking ‘Run Tool’

You should see a successful response:

And as you invoke the tool to add notes, you should see them appear in your local file system:

Next, we’ll use this server in a more natural integration with Claude.

Integrate your server with the Claude Desktop App

If you don’t have it, install the Anthropic Claude desktop app and use the menu bar to navigate to Settings -> Developer:

Click the Edit Config button to view the empty MCP server config file:

Back in your terminal, still operating within your project directory, run mcp install main.py — this will update the Claude MCP configuration to include your server.

View the updated configuration; this tells Claude where your server is, and how to launch it.

Restart the Claude Desktop App, and you should now see a hammer icon; hover over it to see your newly available MCP tool. Click on it for more details.

Now let’s see it in action:

Note how you don’t have to explicitly reference MCP or tool use; Claude gets the description of the tools available from the MCP server, and naturally uses them as part of the conversation.

Next Steps

Think about what sites, APIs, or tools you’d like your LLM to be able to interact with on your behalf. Experiment with building tools for your personal use.

If there’s a use case you are interested in integrating your LLM with, like interacting with your GitHub repos, check the internet. There may already be an official MCP server provided by that company, or a popular open source server. Make certain to vet that the MCP servers you use are secure, especially before feeding any confidential or personal information to them.

Picking up from Part2, we’re going add the final component of our application — a message queue. The specifics of this example will seem bit contrived, but the goal is to decouple our publisher and worker, use Docker to launch a RabbitMQ container, and use Docker Compose to orchestrate the system. And of course, go line by line through the changes required to accomplish these tasks.

Why use a message queue?

Microservices are all the rage in today’s distributed systems. But an unfortunate side effect of breaking down monolithic applications into multiple single-purpose services is high coupling between the new services. What appears to a client as a single RESTful API call may actually become many calls between interdependent services behind the scenes. If one critical service goes down, the negative effects (latency and more failures) will quickly be felt throughout a highly coupled system.

This is where message queues come into play. Instead of direct HTTP connections between services, we introduce a middleman. Services can publish messages to a queue, and consumers will pull messages from that queue and process them. This can allow asynchronous communication for long-running tasks (enqueue and forget), or the caller can enqueue the message and wait for a consumer to return a response (Remote Procedure Call pattern). Either way, we’ve decoupled the two services, in the sense that if one goes down, the message still persists in the queue, and as long as we’ve scaled horizontally (multiple copies of the services) on both sides of the queue, we don’t have a single point of failure (besides the queue itself, but there are ways to ensure the queue is highly available).

Let’s write some code!

We finished Part2 of this series with two applications running in Docker containers and orchestrated with Docker-Compose. Our ‘worker’ app calls our ‘publisher_api’ app via RESTful web service, and prints the response. Our next goal is to modify the program so that when we post a message from the worker to the publisher, instead of receiving an immediate response, we’ll simulate a situation where the server needs more time to process the request. The worker will not wait synchronously for the response to each request; it will fire off messages, and then poll our message queue awaiting responses.

Hopefully you’ve completed part 2 of the tutorial so we can pick up right where we left off. If you need the code for a starting point, look for the v2.0 tag in the Github repo.

To get started, we’re going to add a rabbitMQ container to our project by modifying docker-compose.yml. Here’s the updated file:

What we’ve done above is tell docker-compose to add a new service to our application, named rabbitmq. It pulls an existing image (rabbitmq:3-management) from the public Docker repository.; this image includes the message queue and the management console that you can access in a web browser. We’ve also exposed the ports RabbitMQ operates on and told our other services to always restart on shutdown or failure. Docker-compose doesn’t manage the startup order of services terribly well, so we’ll just keep restarting our worker/publisher until the queue is in place.

Next, we want to modify our code to use the message queue. Let’s import the NuGet package for the RabbitMQ client. Navigate to the publisher_api directory in a command prompt, and run the following command:

Now we will create a class to post messages to RabbitMQ, Create a new folder inside the publisher_api directory called services, and a new file there called MessageService.cs. Here’s the file:

Let’s walk through the code. You’ll first note that we import the RabbitMQ.Client package, and that we define a namespace to hold our project’s services (publisher_api.Services). Next, we declare an interface (IMessageService)that our new class (MessageService) implements. Interfaces are valuable in .NET Core because they make it easier to create unit tests against your classes, and because they allow other classes in your application to depend on abstractions rather than concrete types (more about this when we discuss dependency injection later.)

Our actual MessageService class only implements a single public method — Enqueue. But there’s some setup that takes place in the constructor. We create a ConnectionFactory object to establish and return a connection to the RabbitMQ server. Then we use a channel to send and receive messages over that connection. The end result is that we invoke the QueueDeclare method on our channel — this will create a queue named “hello” if one does not already exist, and establish a connection to it.

In our Enqueue method, we create the string we want to return to our client (“server processed” plus the original message), and invoke BasicPublish on the channel. We’re not specifying an exchange, so we leave that parameter as an empty string, and our routingKey is the name of the queue we’re sending the message to (“hello”.)

Now, we want to modify the POST handler in ValuesController.cs to publish to our message queue. But how do we access MessageService from ValuesController? We don’t want to create a new instance of MessageService every time a POST request comes in — that’s not going to scale well. This is where we need Dependency Injection. In short, Dependency Injection is a pattern that allows you to decouple pieces of your application and helps us achieve the Dependency Inversion Principle (higher-level modules should not depend on lower-level modules, and modules should depend on abstractions rather than on concrete details.) My colleague Chris Tanghere has put together a deep dive on Dependency Injection if you want more info.

To configure our application to access MessageService via Dependency Injection, we have to modify Startup.cs. Add a using directive to reference Publisher_api.Services to the top of the file. Then look for the ConfigureServices method, and add the following line to the end of the method, after AddMvc is invoked:

What we’re doing is basically telling our program that if anyone requests an instance of type IMessageService, they will be given a reference to a singleton MessageService object. This means our MessageService class will only be instantiated once, no matter how many times it is referenced.

Now let’s modify ValuesController.cs to take advantage of Dependency Injection and enqueue our message via our MessageService. Again, add the using directive for publisher_api.Services to the top of the file. Then, modify the class and it’s constructor to inject an instance of IMessageService, and store a reference to it in a private member variable:

All we have to do now is modify the POST method to invoke Enqueue on our MessageService member variable:

Publisher_api is complete. If you want to test the application now, you can run “docker-compose up — build” from our solution directory, and you should see output similar to this:

The key items there are:

• rabbitmq_1 container completes initialization successfully
• worker posts a message to the publisher
• publisher_api receives a message and publishes it to RabbitMQ

Once we verify that works, let’s kill the docker-compose process (Ctrl-C) and modify the worker to poll our message queue for responses. We’ll need to import the NuGet package for the RabbitMQ client, just as we did for the publisher_api. Navigate to the worker directory in a command prompt, and run the following command:

Now let’s get into the code. In worker/Program.cs, add a couple of using directives from the RabbitMQ package:

Our PostMessage method will remain the same, we’ll just modify the Main method to post 5 messages, then listen to our MessageQueue and await the responses:

The Wait() call at the start of the function is a hack to give the RabbitMQ container more time to initialize before we start sending messages. Then we loop, sending each of our test strings to the publisher_api. After that, it’s time to poll the message queue and retrieve the responses.

First, we set up a connection to the queue, in the same fashion that we did for the publisher_api. The major difference is that we set up an EventingBasicConsumer object. This class exposes RabbitMQ’s message handling functions as events. We add a handler to the ‘Received’ event where we retrieve the message body and print it to the console. Then we call the BasicConsume method on our channel object, supplying the name of the queue to poll and the EventingBasicConsumer object we just created.

Head back to the cmd prompt and docker-compose again (don’t forget the build flag to ensure your containers include the code changes you just made.) Your output should be similar to:

You should see the publisher_api receive five POSTs, and the worker consume the message queue, printing out five messages it retrieved. Another way you can verify the queue is functional is to visit the RabbitMQ Management Console by visiting localhost:15672 in your web browser. This site will only be accessible while your docker-compose is running because it is hosted in the RabbitMQ container.

Once you login to the site with name: guest and password: guest (defined when you created the queue in MessageService.cs), you should see some statistics. The clearest indication of activity is the message rates graph; as you can see below, there was a small spike in activity when our worker posted the five messages.

That’s the end of this series — to recap, we built .NET core applications, containerized them, decoupled them using RabbitMQ, and used docker-compose to orchestrate all the pieces of this project. You can find all of the code in the Github repo. Please share any feedback, and also any ideas you’d like to see explored in future articles. Thanks!

Interested in joining our team at Trimble Maps? Click here!

Getting Started with .NET Core, Docker, and RabbitMQ — Part 3 was originally published in Trimble Maps Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Picking up from Part1, we’re going to be containerizing the application we’ve built. Containerization is an approach where an application and its dependencies are packaged together and and run in an isolated environment. A VM (or physical machine) runs the container host, instead of running our applications directly. The container host, in turn, runs our containers. Each container is isolated from the others, and can even run a different operating system than the VM.

In this project, we’ll be using Docker, an open-source project for automating the deployment of applications as portable, self sufficient containers that can run almost anywhere. Before we start, let’s walk through some of the benefits of containerization.

Consistency & Portability

How do you replicate the software you’ve built on your local machine somewhere else, perhaps on another physical machine or on a virtual machine in the cloud? Are all the run time dependencies (including any specific version requirements) in place? When dependencies change, how do you apply that change across all relevant machines and environments? A frequent symptom of this problem is when you hear “it works fine on my machine” or “why does it work in QA but not in Production?”

Once a container is created, you can run it basically anywhere and it will behave the same way. Because the application and all of its dependencies (including the OS) are encapsulated within the container, there will be no difference in execution between your local machine, another physical machine, or a virtual machine in the cloud. This approach also helps to simplify deployments.

Isolation & Efficiency

Another common problem is VM utilization. To maximize efficiency and minimize cost, you may want to host multiple apps on a single VM. In that scenario, there is no logical boundary between the apps. Containers isolate each application, preventing dependency conflicts. Containers also allow resource limits to be set for each service, preventing a service on a shared VM from consuming all available RAM and starving other critical services. These silos provide more security because your applications aren’t running within a shared operating system.

A container also requires fewer resources than a virtual machine (containers don’t have any direct interface with hardware, for example). This enables them to launch faster, and allows your application scale quickly in response to heavy traffic.

We’re going to modify our project to run the webAPI and console app within individual containers, and then use a tool called Docker-Compose to launch them together. Hopefully you’ve completed part 1 of the tutorial so we can pick up right where we left off. If you need the code for a starting point, look for the v1.0 tag in the Github repo. The only additional software you need installed is Docker Community Edition. I’m working on a Windows machine, so that’s Docker Desktop for Windows. Follow the installation guide and then we can get started.

The first step in introducing Docker to our project is to add a Dockerfile. A Dockerfile is a text file that contains all of the commands that will be executed to create a Docker image. An image is basically a package with all the dependencies and information needed to create a container. Images are composed of layers; you typically start with an operating system (maybe your container will run linux or windows server core), then install dependencies (such as the .NET Core SDK), and then install your application.

Let’s start with the publisher_api project. Add new file called Dockerfile (no file extension) to the publisher_api directory (publisher_api/Dockerfile). You can copy the content below, and then we’ll get into what each line is doing.

The first line declares the base image we’re building our new image from; in this case, it contains the .NET Core SDK and is optimized for local development and debugging. Line 2 declares our working directory within the container (future COPY and RUN commands will execute within this directory).

Lines 5 and 6 copy our project file into the WORKDIR, and then execute a dotnet restore to pull down required dependencies. Lines 9 and 10 copy the rest of the files in our project directory into the WORKDIR, and then actually build the application.

On line 13, it looks like we start over, building an image from a different base image. What we’re actually doing here is taking advantage of a Docker feature called multistage builds. The short of it is that we want to build and run our application in a container, but building the app requires a lot more overhead than running it. So what happens here is that when we declare another FROM statement in our Dockerfile, we’re starting the next stage of our build from a clean image. But we still have access to all of the artifacts from the previous stage. So the final image will only contain the results of the last stage of the build.

So getting back to line 13, we‘re creating a clean image from Microsoft's .NET core ‘runtime’ image (it’s leaner than the image we used for the first stage of the build). Line 15 declares our working directory in this image, and line 17 copies the binaries from our build image into this new image.

Line 19 declares the ENTRYPOINT for the container, which basically allows the container to run like an executable; when the container launches, it will launch the process declared here.

That’s all we need to containerize our publisher_api application. What we’ve done is actually more complex than the most basic example we could create, because we are using a multistage build. Let’s test it out!

Navigate to the publisher_api directory in a command prompt, and run the following command:

You should see output similar to this:

You can use docker image ls to view your new image:

And docker run my_publisher_api to start the container:

Next, we’ll follow the same exact steps for the console app (adding a Dockerfile, building the image, and running the container.) The only difference in the new Dockerfile is the name of the DLL in the entrypoint:

Navigate to the worker directory in a command prompt, and run the command to build the image:

And go ahead and test it with docker run my_worker to launch the container:

Our container launched as — but there’s an error. Our container ran as we expected, but since we’re not running the publisher_api, our POST request fails. Luckily, there is a way we easily run both of our containers at the same time; using a tool is called Docker-compose.

Docker-compose is basically orchestration for containers. It allows you to define and run multi-container applications. Create a docker-compose.yml file in our root directory (at same level as our worker and publisher_api folders.) The contents of our implementation are below; copy them into your file and then we will get into the details.

First we define the version of docker-compose that we’ll use (3 is the latest major version.) Then we declare our services; a service is basically a single container, encapsulating an isolated piece of our application. We have two services - one for our webAPI and one for our console app.

The first service, which we’ve named publisher_api (the same as the project, although that’s not required), is pretty straightforward. All we have to do is specify the build context, which is the directory where the Dockerfile for that project can be found.

The other service is exactly the same, except we express the dependency between our services using depends-on. We don’t want the worker to start up until the publisher_api is running.

Our docker is complete. However, if we run our app, we’ll still see an error. Try it by executing the following command from the root directory of our project. The build flag specifies that we want to rebuild our containers to pick up the latest changes to our code or configuration.

You should see output similar to the below image. Our containers are built, the publisher_api launches and start listening for HTTP requests, the worker launches and tries to post a message but fails with an error.

Currently, the worker sends a POST to http://localhost:5001/api/Values, and this worked because we were running both the webAPI and the worker on our local machine. But now that they are in separate containers, we need a way for the worker to discover and communicate with the publisher_api.

Since we’re using docker-compose to launch our application, by default a single network is created for our application. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.

Understanding docker-compose networking, we need to modify the URL the worker is trying to reach. Replace localhost with the desired container name (publisher_api) and change the port to 80 (5001 was where Visual Studio Code hosted the debugger).

Launch the app again using the same command as before (make sure you use the --build flag so our code changes are picked up.) This time, the worker should successfully reach the publisher_api, and the response (success:true) should be logged to the console.

To recap, we took our existing .NET core application, containerized each of the two components, and then used docker-compose to launch our multi-container application. Stay tuned for Part 3 of this series, where we’ll use RabbitMQ to decouple our client and server and experiment a bit more with docker-compose.

Interested in joining our team at Trimble Maps? Click here!

Getting Started with .NET Core, Docker, and RabbitMQ — Part 2 was originally published in Trimble Maps Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.