4 min read

AWS Microservices Architecture Diagrams

October 13, 2022

AWS Microservices architecture diagram

If you have adopted a micro-services approach to application development, you'll understand the benefits of diagrams showing the status and connections of the configured services.

If you are not entirely familiar with this application development approach here's a quick run down of the methodology.

Micro-services aren't a thing you can log into your cloud provider console and order, they are an approach where you segment software applications into small self contained services and call them as they are required. Micro-services are typically controlled using well defined APIs and are made up of code you write that is placed into containers or functions that are called when needed.

The major benefit of the micro-service approach is that applications are made up of individual components that run an application process as a service. Services can be individually scaled when in high demand, instead of scaling the entire application. Each service can be updated and deployed independently of the other application functions.

The micro-service approach somewhat simplifies complex applications, in that each service can be coded to do a specific task within the application, like say the payment processing in an e-commerce application. As individual micro-service code starts to evolve and become larger and more complex, it can be broken up into yet smaller services.

Micro-services offer flexible scaling options in that you can scale just the services that have increased demand. They can be easily deployed within a CI/CD framework and as you try out new things, if they don't work out you can roll back the individual micro-service without affecting the entire application.

Micro-services also provide the flexibility to use different tools, code and methodologies on a per service basis. You might find a specific tool better helps solve a problem with single micro-service solution, so you are free deploy against a single service without affecting or having to adopt the technology in all your micro-services.

There is also a better chance of using code from a micro-service as a building block for similar functionality. With the small independent self contained code found in micro-services it is easier to take code and reuse it to create new application capabilities without having to start from scratch.

Finally another advantage micro-services have over monolithic applications is the ability for applications to persist should an individual component fail for any reason. For instance if the create new account micro-service within an e-commerce app fails, existing users would be unaffected and could still add items to cart and checkout without being affected. In monolithic applications, such a failure could crash the entire application.

From an AWS perspective the majority of services used to create micro-services are supported by Hava and will be automatically detected and placed on diagrams.

The AWS compute services predominantly used to run micro-services are ECS Elastic Container Service that hosts docker containers that run on a managed cluster of EC2 instances and the other serverless approach is to utilise AWS Lambda. With Lambda you upload your code into Lambda functions and use API calls or environment triggers to execute the function.

AWS_Environment_with_Attribute_Pane

Micro-services will often require the ability to write and access stored data and the all the AWS database and storage services are available to ECS containers or Lambda functions. Database services like DynamoDB, Amazon RDS, Amazon Aurora, Elasticache and object storage in Amazon S3 are all mapped by Hava.

The performance services that can be utilised by applications built using micro-services will also be discovered and mapped by Hava. Elastic load balancers, network load balancers, API gateways and Route 53 dns are all currently diagrammed, with SNS pub/sub messaging and SQS not far away.

If your micro-services have been deployed using Lambda, then your VPC diagrams will look like the diagram above. If you choose docker and ECS containers to deploy your application, then you will get a visualisation similar to this:

hava-container-view 

This diagram shows you each container cluster and the run status of the micro-service tasks, so you can tell at a glance the health of the running, starting or stopped tasks.

All the diagrams automatically generated by hava.io are interactive which means that clicking on a resource on the diagram changes the side panel attribute pane to display all the known metadata and settings related to that resource.

aws_diagram_resource_instance_selected

 Hava periodically polls your cloud account console config settings looking for changes. When changes like a new resource are detected, Hava will generate a new set of diagrams and place the superseded ones into version history. This means you have an audit trail of all your network and application resource changes that you can use to troubleshoot or answer tricky compliance audit questions.

You can choose flexible subscription to cover the number of cloud accounts and team members you have and the functionality you require.

All plans start as a free 14 day trial of the fully featured Teams plan without the need to enter credit card details so you can experience everything Hava has to offer. 

You can view The differences between plans and pricing here.

Or jump straight into a free trial, learn more using the button below.

 

Topics: aws
Team Hava

Written by Team Hava

The Hava content team

Featured