avatarNazreen Mohamad

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1184

Abstract

ed to know the full ARN for that table. The ARN would also need to be stored in the application itself either in a hard-coded fashion or as an environment variable. Cloud Map allows you to store the ARN in its registry via a more friendly name. Instead of the long ARN, you can have your Lambda or EC2 ask Cloud Map for the ARN of the service named ‘mainDb’ (the name can be anything you set it to be) and Cloud Map will return the appropriate ARN. This also means that if you need to swap the tables, you don’t need to modify anything on your application side, but just modify the value on Cloud Map.</p><p id="03fa">Now let’s talk about App Mesh. Currently, App Mesh provides you a service mesh (the concept of a service mesh is a general one so I will not elaborate on it in this post.) through which you can setup networking between various compute services such as EC2, ECS (both EC2 and Fargate launch types), and EKS. This list of services is currently the exhaustive list of compute services supported. With App Mesh, you can easily set up ‘nodes’ for a ‘service’ and define the routing for that service. For example, for a service that has two nodes — nodeA and nodeB — reque

Options

sts that go to a that service can be set via routing to have 10% of the traffic to go to nodeA while the other 90% goes to nodeB. Basic healthchecks are also done. Now you might think that this sounds awfully similar to Elastic Load Balancers. Well, in some cases — especially for certain interservice communication within your own VPC — load balancers are not needed and are an overkill. In the FAQ for App Mesh, AWS advises that you use ELBs for traffic coming from the internet while App Mesh is more suitable for services traffic within your internal trust boundary.</p><p id="c642">That’s it. I hope this Quick & Simple post was useful to you.</p><p id="b85c">Also check out:</p><ul><li><a href="https://readmedium.com/use-case-aws-inspector-vs-guardduty-3662bf80767a">Use case: AWS Inspector vs GuardDuty</a></li><li><a href="https://readmedium.com/use-case-kinesis-data-streams-vs-kinesis-data-firehose-74d639214e89">Use case: Kinesis Data Streams vs Kinesis Data Firehose</a></li><li><a href="https://readmedium.com/how-to-run-macos-using-amazon-ec2-mac-instances-cur-d918094f9b65">How to launch a macOS instance on Amazon EC2 (Mac instances)</a></li></ul></article></body>

Use case: AWS Cloud Map vs App Mesh

So what’s the difference AWS Cloud Map and AWS App Mesh? This is a Quick & Simple post.

How they are similar

First, let’s talk about how they are similar.

Both AWS Cloud Map and AWS App Mesh are services that come into play for architectures that involves a large number of services. Sure, you can use them from the very start, but that might be premature optimisation.

How Cloud Map and App Mesh are different

Now let’s talk about how they are different.

The short version of it is that, AWS Cloud Map helps you keep track of your cloud resources better through a registry and discovery while App Mesh is a service mesh that helps you manage networking between services that can span across compute infrastructure.

Let’s go through an example for Cloud Map. Say you have a Lambda function deployed or EC2 instance running. If either of them needed to interact with a DynamoDB table, they’d need to know the full ARN for that table. The ARN would also need to be stored in the application itself either in a hard-coded fashion or as an environment variable. Cloud Map allows you to store the ARN in its registry via a more friendly name. Instead of the long ARN, you can have your Lambda or EC2 ask Cloud Map for the ARN of the service named ‘mainDb’ (the name can be anything you set it to be) and Cloud Map will return the appropriate ARN. This also means that if you need to swap the tables, you don’t need to modify anything on your application side, but just modify the value on Cloud Map.

Now let’s talk about App Mesh. Currently, App Mesh provides you a service mesh (the concept of a service mesh is a general one so I will not elaborate on it in this post.) through which you can setup networking between various compute services such as EC2, ECS (both EC2 and Fargate launch types), and EKS. This list of services is currently the exhaustive list of compute services supported. With App Mesh, you can easily set up ‘nodes’ for a ‘service’ and define the routing for that service. For example, for a service that has two nodes — nodeA and nodeB — requests that go to a that service can be set via routing to have 10% of the traffic to go to nodeA while the other 90% goes to nodeB. Basic healthchecks are also done. Now you might think that this sounds awfully similar to Elastic Load Balancers. Well, in some cases — especially for certain interservice communication within your own VPC — load balancers are not needed and are an overkill. In the FAQ for App Mesh, AWS advises that you use ELBs for traffic coming from the internet while App Mesh is more suitable for services traffic within your internal trust boundary.

That’s it. I hope this Quick & Simple post was useful to you.

Also check out:

AWS
Amazon Web Services
Aws Cloud Map
Aws App Mesh
Microservices
Recommended from ReadMedium