Blog

How to improve microservices-based application availability and engineering productivity with AWS Cloud Map

Jul 16, 2019 | Announcements, Migration, MSP

Does your business need to innovate faster to remain competitive? To accelerate the pace of innovation, have you implemented modern microservices-based applications running in containerized environments? Do you want to improve the availability of those applications and enhance engineering productivity? If so, this blog is for you.

The dynamic challenge of microservices

Microservices are implemented using dynamic resources such as containers and communicating over APIs. The number and network location of instances change dynamically based on service terminations, autoscaling, failures, and upgrades. Each service needs to be able to quickly find the location of all the infrastructure resources on which it depends in order to function. Therefore, application availability depends on efficient service discovery of these dynamically changing resources.

AWS Cloud Map improves application availability and engineering productivity

AWS Cloud Map is a fully managed cloud resource discovery service that increases application availability by maintaining the updated location of dynamically changing resources. Application resources – such as databases, queues, microservices, and other cloud resources – are registered with custom names, enabling AWS Cloud Map to continually check the health of resources and ensure locations are up to date.

With this single registry for all your application services, your engineering teams don’t have to manually store, track, and update resource name and location information or make changes directly within the application code.

Use case

In the past, have you wanted more control over monitoring services and centralizing multiple applications, beyond what was possible using AWS Application Load Balancer (Amazon ALB)? With Amazon ALB, you can specify only one port for target groups, and Amazon ECS clusters and services. Amazon ALB maps the listener port to a random port in the target group and the target group registers a new container with a random private IP in the Amazon ECS cluster, making it impossible to know where that container is located. In that case the container can only be accessed by the load balancer. What if you need to access an additional port?

Here’s a real-life example of that dilemma, and why AWS Cloud Map is so cool. An nClouds client needed to expose a service, a Jenkins master running as an Amazon Elastic Container Service (Amazon ECS). The Jenkins master was using slave workers inside an AWS ECS cluster for their CI/CD process. In this case, Jenkins slaves could not find the Jenkins master server. Amazon ECS could expose only a single port (8080) and we needed to expose the port for slaves (50000). So, we used AWS Cloud Map not only to find the server where the Jenkins master was located but to also provide access to the extra port.

AWS Cloud Map endpoints

Below is a comparison of how endpoints are handled without and with AWS Cloud Map. As you can see, with AWS Cloud Map, endpoints are dynamically located, instead of being statically coded into the application.

Source: Amazon Web Services, Inc. Cloud Map – Service discovery for cloud resources.
https://aws.amazon.com/cloud-map/

How to locate an AWS Cloud Map endpoint:

  1. Create a namespace (a logical group of services that share the same domain name) where you can easily manage your services in a centralized manner.

  1. Start registering services under your namespace with different types of queries (API, private DNS, and public DNS) for each type of resource for which you want to locate endpoints and indicate if you wish to perform health checks.
  2. Important note: When you create a service, you can also choose whether and how you want to check the health of the resources that service instances point to:
      • No health checking: AWS Cloud Map or Amazon Route 53 returns service instances regardless of the health of the corresponding resources.
      • Route 53 health check (available only for public DNS namespaces, responds to DNS queries only with records for healthy resources): Sign in to the AWS Management Console and open the Route 53 console at https://console.aws.amazon.com/route53/. In the navigation pane, choose Health Checks. To update an existing health check, select Edit Health Check. To create a health check, choose Create Health Check. Associate the health check with one or more Route 53 records.
      • Custom health check (not required for API services): Use a third-party application (or create your own, using a shell script or python script and a cron job) to determine the health of your resources, then send UpdateInstanceCustomHealthStatus requests to AWS Cloud Map to update the status of the service instances.

     

  3. Once you have the service available in AWS Cloud Map, you can register service instances with each service by using the AWS CLI API or by doing it manually.
  4. Now your app can query AWS Cloud Map by namespace and service ID to get a worker instance available for the application to be used.

Deep integration with AWS container services

Services and tasks managed by Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Service for Kubernetes (Amazon EKS) can be registered automatically and updated in AWS Cloud Map. As Amazon ECS launches tasks for your service, it automatically registers them as resources with AWS Cloud Map, and they are discoverable within five seconds.

  • Integrating Amazon ECS Cluster with AWS Cloud Map

    The diagram below shows how we use the service discovery option to access Docker container workers outside a target group port, using a namespace and service to access the container with our worker. Services are built using Amazon Elastic Compute Cloud (Amazon EC2) instances and Amazon ECS tasks. Amazon Route 53 manages the routing queries.

     

  • Integrating Amazon ECS Cluster with AWS Cloud Map

    The diagram below shows how we utilize the Amazon EKS cluster as a backend. This backend is connected to a namespace of AWS Cloud Map with the configuration of Kubernetes’ cluster-internal DNS server, ExternalDNS. In this case, the frontend can easily connect with the workers through each service specified in the namespace.

     

In conclusion

If your business is accelerating the pace of innovation, needs to improve the availability of microservices-based applications running in containerized environments, and wants to enhance engineering productivity, consider using AWS Cloud Map.

Need help with implementing AWS Cloud Map? The nClouds team is here to help with that and all your AWS infrastructure requirements.

Contact us

nClouds Insights

Join thousands of DevOps and cloud professionals. Sign up for our newsletter for updated informaion and insights

nClouds
nClouds is a cloud-native services company that helps organizations maximize site uptime, performance, stability, and support, bringing out the best of their people and technology using AWS