An Introduction to Microservices: An AWS Perspective
Microservices best practices, common questions and benefits. Part of an overview of Micoservices as presented by Abby Fuller, a developer advocate for AWS.
In the February 28th Weave User Group guest speaker Abby Fuller, a Developer Advocate with Amazon Web Services (AWS), provided an overview on microservices.
In this first of a two-part series on microservice best practices at AWS, Abby posed four thematic questions:
- What are microservices?
- Why are companies adopting them?
- How do organizations morph from a Monolith to microservices?
- What are microservice best practices?
What are microservices?
Adrian Cockcroft, Vice President of Cloud Architecture at AWS, captured the essence of microservices in this single sentence: “Service-oriented architecture composed of loosely coupled elements that have bounded contexts.”
Further expounding upon the key components of this definition, Abby pointed out that microservices are:
Service-oriented – They communicate with each other over networks.
Loosely coupled – They can be independently updated; changing one microservice does not require changing others.
Self contained – Updating the code of one microservice does not disrupt the functioning of other microservices.
Why are companies adopting microservices?
When services are loosely coupled and self-contained, developers do not need to understand how each microservice works. With a monolith, changing a single line of code could potentially impair the functioning of an entire system. Microservices, on the other hand, possess autonomous components. This allows a programmer to initiate a localized modification without impairing the functioning of other parts of the system.
Other benefits microservices offer are:
– Rapid feature delivery;
– A more flexible overall system due to component autonomy;
– Enhanced developer velocity.
Transforming Monolith to Microservices
To switch from a monolithic network to one comprised of synergistically functioning microservices, a company will need to transform both its culture and its system’s architecture. This process will not simply be a matter of atomizing the monolithic system into microservices. Service partnerships will be required to effectively manage the added complexities of testing, deploying and operating multiple microservices.
Best practices to deploy microservices include:
Reliance on the public API:
Services need to communicate with each other directly via the public API, and not through the company database. For example, Service A should only talk to Service B via an API, and not directly to the database that is part of Service B. APIs are contracts and should be assigned a version.
Use the right tool for the job
With an API, services are not limited to single task performance. Since the app communicates over an agreed upon API protocol, developers are free to deploy the appropriate tool to write the program, instead being bound to specific language constructs.
Secure your services
Always include security features as part of the application design. AWS offers different security products for microservice based applications. For instance: IAM-based Authentication; S3 bucket policies; API Throttling. Additionally, there is the built-in Defense-in-depth approach of AWS within the Network, Server, and at the application levels.
Be a good microservices citizen
For Abby, a good microservices citizen means a service owner takes responsibility for monitoring and publishing the health of the service, and the service client performs proper retries with exponential backups. Proper monitoring and tracing ensure the user will enjoy improved application performance.
Account for organizational changes
Deployment of microservices requires organizational change. If, according to Conway’s Law, “silo-ed teams lead to silo-ed architecture,” then integrated architecture requires broadly skilled team members capable of focusing on a product, not a project.
2 Pizza Team
Team size should be no greater than about 8 (the number of people that can be fed with 2 pizzas). AWS practices this organizational structure.
Automate over everything (when possible)
AWS offers a few features such as CodeCommit, CodePipeline, and CodeDeploy to automate microservices deployment. With microservices, an application might be composed of 75 to 100 services. Orchestration becomes an important element for easy and consistent deployment.
Luke Marsden the Weave user group with a short talk on microservices and Weave Scope (part of Weave Cloud).
Weave Cloud is a set of tools that can be plugged into an organization’s orchestration framework. Currently, it is deeply integrated with Kubernetes. It also works with Amazon ECS.
Weave Cloud helps DevOps iterate faster in shipping and troubleshooting applications:
Microservices facilitate fast deployment of an application to the production cluster. This is done using the CI/CD pipeline for building and testing. Weaveworks provides tools to make this possible through monitoring, user-friendly networking, security configuration, and troubleshooting.
Weave Cloud is composed of these products:
Weave Scope – Deploy your app in development and production then verify and troubleshoot.
Weave Flux – Connect the output of your CI system into your container orchestrator and automate or gate CI.
Weave Cortex – Collect metrics that matter to you from your application, network and orchestrator with Prometheus-based monitoring as a service.
Weave Net – Define network policy to secure your app and isolate your microservices.
The talk has also been recorded - please see the full video below:
Interested in more AWS ECS2 best practices? Check out the recap and recorded session from our Weave Online User Group: Microservices on Amazon ECS with Abby Fuller (AWS) Part 2.
Or visit our what you need to know page that explains all things Kubernetes on AWS and how we are managing our clusters.
As always, send us your thoughts, suggestions and criticisms -- we love to hear from our users. Ask us anything Slack or join the Weave Online User Group.
