Guide to Implementing Microservices Architecture on AWS [With Examples]

Relevant Founders Podcast

Listen to our podcast in which tech founders reflect on their journey of building a successful startup and reveal their secrets to success.

Scaling up may be complicated if the product architecture wasn’t designed to be scalable, which is often the case with monolith applications. In that case, you have two ways to go: spend a fortune to throw in more resources and scale vertically or restructure your application using microservices and scale horizontally and cost-effectively. We’d always go for the second option – implementing microservices infrastructure.

Aside from cost-efficiency, going for microservices provides benefits like:

• Shorter time-to-market. When different teams can develop their microservices independently, the whole product has fewer roadblocks, and the overall time-to-market decreases.
• Improved scalability. When the demand for particular features grows or diminishes, you can scale them up and down separately across multiple servers and providers.
• Resilience of operations. As microservices operate independently of each other, one component failing won’t shut down the whole product, like it is with monolithic apps, and the faulty module is easy to reboot.
• Efficiency of management. Modular software products based on microservices are much easier to deploy, update, and manage.
• Ease of product assessment. When monolithic apps are broken into independent pieces, understanding the source code of each microservice is much easier, so developers can assess and update them much faster.

Going for microservices can be of great use for any SaaS provider. But what are microservices, exactly? Let’s explore the benefits of using microservices architecture and how to implement it with AWS. You’ll also find some real cases from Relevant Software’s portfolio below, so keep reading.

What are Microservices?

AWS defines microservices as independent pieces of software that deliver specific functions, run separately from each other, and are owned by smaller, self-contained teams. Any communication between microservices happens over well-defined APIs, allowing polyglot development. This means that software engineers aren’t limited by a single programming language or framework and can select the tools best suited for every function a microservice performs.

Each microservice can be developed, updated, scaled, and managed separately, which tremendously increases the speed of innovation, as well as the cost-efficiency and simplicity of infrastructure management, compared to monolithic app development. Speaking of…

Monolithic vs. Microservices architecture

Monolithic applications run tightly coupled processes that are dependent on each other, so a failure in one process impairs the rest of the application. If the whole process faces a spike in demand, the entire application must be scaled up. Worst of all, with time, the code becomes increasingly complex, and adding new features or updating the existing ones starts costing too much time and effort.

With microservices, all processes are decoupled, run in separate code envelopes (Docker containers), and can be scaled, updated, or rebooted independently. Each microservice performs a single function, and all of them communicate over well-defined interfaces through lightweight, uniform APIs. Most importantly, if over time the microservice code becomes too complex, it can be easily split into more microservices, without affecting the performance of the whole application.

Benefits of Microservices

Microservice-based software development brings various benefits:

• Agility. Each microservice is owned, developed, and run by a single small, self-contained team working within a well-understood context. Thus, every team works at its own pace, bringing more agility across the organization.
• Scalability. As each microservice runs independently, it can be scaled independently to meet the customer demand for the business function it enables. This helps maximize the cost-efficiency of resource allocation and ensure service reliability.
• Deployability. Because every microservice runs separately, it can be easily updated and rolled back if something goes wrong.
• Code reusability. As microservices run as separate pieces of code, each one can be used as a building block for the same functionality in multiple products.
• Fault resilience. Microservices are loosely coupled, so a failure of one module doesn’t impair the whole application, and a faulty microservice can be restarted without affecting the rest of the product.

Microservices are thought to be the best choice for running cloud-based applications, although the ease of implementing them differs from one cloud provider to another. AWS, for one thing, can be a perfect choice for deploying and running a microservice-based application of any scope. 

Why AWS? 

Amazon Web Services (AWS) is one of the best choices for deploying a microservice-based application due to the variety of IaaS, PaaS, SaaS solutions, and SDK packages offered by this cloud platform. AWS provides a vast array of building blocks to support software of any complexity and scale.

• Computing power: AWS EC2 Elastic Container Service and AWS Lambda Serverless Computing
• Storage: Secure Storage (Amazon S3) and Amazon ElastiCache
• Databases: Amazon RDB, Amazon Aurora, Amazon DynamoDB and dozens more
• Networking: Amazon Service Discovery and AWS App Mesh, AWS Elastic Load Balancing, Amazon API Gateway and AWS Route 53 for DNS
• Messaging: Amazon SQS for message queuing and SNS for publishing and notifications
• Monitoring: AWS Cloudtrail for API monitoring and Amazon CloudWatch for infrastructure monitoring
• DevOps and CI/CD: Amazon Container Image Repository (Amazon ECR) and other DevOps tools for enabling CI/CD workflows. 

You can configure the architecture you need and select any required operating system, programming language, framework, database, or other required services. This facilitates migration for the existing applications and allows you to quickly build new applications from scratch.

Microservices on AWS

Going for microservices on AWS was a perfect choice for Relevant Software. We leveraged detailed guides on deploying Java and Node.js microservices on Amazon EC2, building containerized microservices using Docker containers on AWS. This allowed us to follow best practices and build scalable, cost-efficient, and highly performant infrastructures for our customers.

The basic microservice architecture on AWS looks like this:

1. User instances run on AWS CloudFront CDN; static content is stored at Amazon S3.
2. Incoming traffic goes to Amazon Automatic Load Balancer (ALB), which routes it to the Kubernetes cluster with Docker containers running microservices at Amazon ECS.
3. The data is cached by ElastiCache and stored at any database like Aurora, RDS, or DynamoDB.

This workflow ensures unlimited front-end scalability through CloudFront CDN, back-end scalability using ECS, and application resilience with caching and secure data storage.

Implementing microservices on AWS

There is an excellent and very thorough step-by-step guide on microservice implementation on AWS, and here’s the gist to save your time.

Modern web apps often use REST or RESTful APIs for communication between their front-end written using one of JavaScript frameworks, and back-end. Static content is often served through a CDN like Amazon CloudFront, while it is stored at an object storage, like Amazon S3. Thanks to this, end-users experience minimal latency when connecting to an app through the edge node.

To support stable operations of RESTful APIs, AWS provides two main approaches: serverless computing with AWS Lambda and managed Kubernetes clusters with Docker containers through AWS Fargate.

AWS Lambda is a PaaS where you simply upload the code, and AWS does the rest. The key benefit here is that you operate a serverless platform, meaning you do not have to look under the hood and configure the underlying servers. This ensures speed of operations, unlimited scalability, and cost-efficiency of running microservices. 

However, due to architectural limitations like file size limit, process duration limit, etc., Lambda is best used for short-term operations, while it definitely is a very secure and easy to operate tool.

AWS Fargate is a PaaS that provides managed Kubernetes clusters for running Docker containers with your microservices. This requires some technical expertise, yet most of the heavy lifting is still done behind the scenes by AWS. 

By performing API calls, you can manage the cluster, run and stop Docker containers, operate load balancing, security groups, IAM, and other features. AWS ECS and EKS provide simple access to container management or Kubernetes clusters, should you decide to run your microservices implementation using an in-house or remote team (and save money).

The data your microservices process should be stored in a database and cached to decrease latency. While AWS provides six types of relational databases, microservices at scale are best served by NoSQL databases due to their emphasis on persistence.

There are three main ways of reducing operational complexity when designing and implementing microservices architecture using AWS:

• API implementation. API Gateway from AWS allows you to programmatically create and run RESTful APIs without the need to manage servers. It acts as an entrance point for web or mobile applications hosted on Amazon or any other cloud or on-prem infrastructure.
• Lambda implementation. AWS Lambda is designed to work in a duet with API gateway by making synchronous calls, which enables serverless applications composed of microservices.
• Deployment of Lambda-based apps. AWS CloudFormation is the best way to discover, define, and manage serverless apps. Its Serverless Application Model (SAM) used in Local mode lets you emulate AWS runtime locally and test everything before launching your microservices live to AWS production.

Aside from dealing with every particular microservice, you should be prepared to handle various cross-service challenges:

• Service discovery. As microservices are loosely coupled via APIs and can scale up and down independently, the most common challenge is enabling them to discover each other, check the health of resources available, announce new apps and interact with them. This can be done through DNS-based functions, specific software (like HashiCorp Consul, etcd, Netflix Eureka), or service meshes.
• Data management in distributed architectures. While monolithic apps use a centralized relational database, following the same approach would render microservices useless. So, they must work with different data consistency layers. As microservices often span across different business logic units at scale, many microservices might be doing the same operation, resulting in incomplete operations and duplication. Therefore, some control logic and master tools must be implemented to perform periodic cleanups and data deduplication.
• Communication and messaging. To deliver value, microservices must message each other. This can be done through network communication — REST-based communication or asynchronous messaging, using Kafka, RabbitMQ, or Amazon SNS to deliver messages from providers to consumers in a predictable way.
• Infrastructure state management and orchestration. Multiple microservices running in your infrastructure make orchestrating its state increasingly challenging. AWS provides the Step Functions feature, which is a part of its serverless capabilities to help build apps using separate components. Step Functions ease the use of various AWS tools like SageMaker, Glue, Lambda, EC2, or ECS. Alternatively, you can go for Terraform or Pulumi, if your DevOps team is not afraid to get their hands dirty and orchestrate your infrastructure directly.
• Decentralized monitoring. As your app architecture involves multiple microservices that scale separately, monitoring can be challenging. Amazon CloudWatch provides managed monitoring for microservice-based architectures while using Prometheus + Grafana is a popular open-source alternative.
• Centralized logs analysis. While microservices run independently, their logs must be analyzed in a centralized manner to allow your team to measure the impact of every update or adjustment. Amazon CloudWatch Logs and other PaaS tools from AWS help deal with this challenge, while the best open-source alternative is EFK — ElasticSearch, FluentD, and Kibana. The popular choices for logs analysis are using Amazon Redshift + Amazon QuickSight or configuring data visualization using Amazon CloudWatch Logs and Kibana.
• Chattiness. When multiple microservices run in parallel and have to talk to each other, the overall messaging overhead increases greatly. While it might seem simple to consolidate similar services that send messages back and forth, this is not the best way to reduce chattiness. Using lightweight human-readable protocols like YAML or binary ones like Avro helps solve this problem, along with implementing persistent caching solutions with API Gateway or Amazon ElastiCache.
• Auditing. Auditing complex infrastructures composed of multiple microservices is not a trivial task. Amazon CloudTrail helps deal with it, as it records all API calls and sends them to CloudWatch Logs for tracking or S3 bucket for storage. Thus, any configuration update can be either discovered right away or traced back to its origin.

AWS provides all the necessary components for implementing microservices using both managed and open-source solutions.

How we implemented microservices on AWS for Svenn and FirstHomeCoach

Just like we promised, here are some of our examples of building microservices for our clients using AWS.

Svenn

One of Relevant Software’s customers, Svenn, needed an update and modernization of their service to enable integrations with various ERP systems.

Challenges the customer faced:

• Monolithic structure, as a single instance of Svenn’s service contained an implementation of integration with ERP APIs, data processing control, and presentation layer API.
• Complexity of new integrations, as the existing service could not support many particular ERP integrations.
• Error handling, as ERP systems could update their APIs without prior notice, and the existing system couldn’t detect that or handle various other types of errors.
• Data presentation was lacking, though it was necessary for centralized data comparison and analysis.

Microservices seemed like the best approach to handling all of these issues. Relevant Software implemented the solution based on AWS Step Functions, which enabled safe data processing. All services now communicate via a Distributor cluster that acts as a data streaming service.

The results are impressive. AWS Step Functions contains AWS Lambda schedule and rules and provides Lambda configuration. Once the input parameters from AWS Step Functions are delivered to Lambda instance, which contains ERP systems integration logic, they are combined with input parameters from the Transformer service, issue API calls to ERP systems, and send event notifications to the relevant Information topics. This makes adding integration with a new ERP as simple as registering its API within Lambda, and AWS does the rest. 

Transformer service consumes ERP system data from ERP_SYSTEM topics, transforms it into Svenn data, publishes it into relevant information topics, and provides the necessary lambda configuration.

Events messaging is implemented using AWS SQS, which consumes ERP system data, events from Information and Notification topics, and produces notifications to relevant Information and Notification topics to ensure messaging consistency.

FirstHomeCoach

FirstHomeCoach (FHC) is another microservices-based solution we developed for our customer. It has mobile and desktop clients, and microservices enable the necessary isolation between the application server and business processes.

FHC uses CMS for content management, React.js on the front-end, and Node.js on the back-end, which communicates on AWS using Lambda functions, CloudFront, and API Gateway. Users are managed with Amazon Cognito.

Conclusion

Microservices are an excellent choice for building, running, and updating resilient and highly scalable applications. AWS provides a ton of managed building blocks for handling every aspect of microservices implementation and provides all the tools needed to replace these components with open-source alternatives — should you have the necessary expertise at hand and be able to manage your infrastructure using an in-house or remote team to maximize the cost-efficiency of operations.

By the way, Relevant Software has ample experience designing, building, and managing various microservice-based applications for our customers. So if you need our assistance, just drop us a line. We’re always ready to help!