A modern application is the combination of modern technologies, architectures, software delivery practices, and operational processes that lead teams to deliver value more quickly, frequently, consistently, and safely. These applications typically take advantage of loosely coupled, distributed technologies and focus on event-driven, serverless components that allow teams to offload undifferentiated heavy lifting in order to spend more time on delivering value for their customers. A modern application also takes advantage of operational and security tooling to increase the reliability and consistency of deployments, while making it safe to deploy many times a day. The use of automation of infrastructure, security, and deployments allows the teams that own modern applications to move more quickly than if they were relying on manual processes or more significant operational management.

A modern application is typically built by shrinking the scope of the application to create better agility and simplify operational and risk concerns. Developers of these applications focus on selecting the right tool for the job to ensure the selected architecture appropriately matches the purpose of the application. For example, leveraging relational databases for data that is typically unified to show relationships like your address and your contact information versus a graph database to manage and visualize deep connected relationships like a person and their various groups of friends, family, and co-workers. While it may be possible to build the latter with a relational database, the graph database is best suited for that problem. From there, the goal is to minimize the operational management of the selected tools and leverage AWS building blocks as much as possible. Finally, companies are managing and maintaining modern applications through automation wherever possible. This makes modern applications lightweight, reliable, scalable, and secure, which allows the owners to deliver value more quickly and frequently.

AWS has a breadth of services and features that enable companies to build an inspiring variety of applications. Today, AWS offers a growing set of serverless capabilities like AWS Lambda, AWS Step Functions, Amazon API Gateway, and AWS Fargate that allow developers to offload undifferentiated heavy lifting. The ever increasing and maturing suite of AWS Developer Tools enable DevOps practices through the automation of infrastructure and deployments. There is also a simple environment for serverless development with AWS Cloud9. From build, to commit, to release, AWS offers a full suite of tools to enable continuous delivery with elasticity and without the operational concerns of historical offerings. Finally, AWS was one the earliest adopters of microservices architectures, and we have built a deep reservoir of expertise and tooling to enable organizations to build and manage a microservices architecture.

The most important factors to consider when drawing boundaries around your microservice are scope and dependencies. The goal should be to make the service small enough in scope that a single team (typically 5-10 people) can own, manage, scale, and deploy the service independently from other services or other teams. Boundaries are typically drawn and identified by the context of their capability and typically fall within a single data or business domain. The size of the service is not as important as the ownership and autonomy of the team that owns it. To use an example, a payment microservice that provides the ability to send or request a payment will be made up of storage, integration, and compute components that are bound by a service interface normally referred to as an API. A single team could effectively own and manage this service.