Kevin Huang: AWS San Francisco Startup Day, 9/7/17 Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Kevin Huang
Spring 2017
AWS Startup Day
If when and how to adopt microservices
#AWSstartupday

2. “The Monolith”
Monoliths can be GOOD when you are starting
out
Always build to keep things as simple as
possible
When your application or company grows,
Monoliths begin slowing you down.
Let’s look at the challenges as you grow..

3. Challenges with monolithic software
Long Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing, who’s
the owner?)
Difficult to scale
New releases
take months
Long time to add
new features
Architecture is hard to
maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility

4. Long Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing, who’s
the owner?)
Difficult to scale
New releases
take months
Long time to add
new features
Architecture is hard to
maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
Challenges with monolithic software

5. Long Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing, who’s
the owner?)
Difficult to scale
New releases
take months
Long time to add
new features
Architecture is hard to
maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
Challenges with monolithic software

6. releasetestbuild
delivery pipeline
app
(aka the“monolith”)
developers
Monolith development lifecycle

7. Too much software coupling

8. Shared libraries
Too much software coupling

9. Shared libraries
Shared data
Too much software coupling

12. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)

13. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Services communicate
with each other over the
network
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)

14. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
You can update the
services independently;
updating one service
doesn’t require changing
any other services.
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)

15. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts” Self-contained; you can
update the code without
knowing anything about
the internals of other
microservices
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix)

16. Anatomy of a Microservice

17. Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Microservice

18. Application/Logic
(code, libraries, etc)
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Microservice

19. Public API
POST /restaurants
GET /restaurants
Application/Logic
(code, libraries, etc)
Data Store
(eg, RDS, DynamoDB
ElastiCache, ElasticSearch)
Anatomy of a Microservice

20. Avoid Software Coupling

21. Drivers
micro-service
Payments
micro-service Location
micro-service
Ordering
micro-service
Restaurant
micro-service
Ecosystem of Microservices

23. = 50 million deployments a year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
(5708 per hour, or every 0.63 second)

24. Gilt
Luxury designer brands at
members-only prices

25. Gilt
Luxury designer brands at
members-only prices
.. Sale every day at noon
EST

27. Application Services
API Gateway
Build, Publish and Manage APIs
§ Performance at any scale via worldwide edge locations,
traffic throttling, and API output caching
§ Monitor API activity
§ Integrates with Lambda functions
§ Run multiple versions of the same API
§ Fully Managed

28. Elastic Compute Cloud (EC2)
Virtual Servers in the Cloud
§ Resizable Compute Capacity
§ Complete control of your computing resources
§ Reduces time to obtain and boot new server
instances to minutes
§ Choose from 30+ different instance types
§ Scale as your requirements change
§ Pay only for what you use
Compute

29. EC2 Container Service
Run and Manage Docker Containers
§ A high performance container management service
for running Docker containers on EC2 instances
§ Use the built in scheduler, write your own, or use a
third-party scheduler
§ Integrates with other services like ELB and EBS
§ No additional charge
§ EC2 Container Registry
Compute

30. Lambda
Run Code in Response to Events
§ Runs code in response to triggers such as S3
upload, DynamoDB updates, Kinesis streams,
and API Gateway requests
§ Automatically scales
§ You only need to provide the code; there is no
infrastructure to manage
§ Pay only for what you use
Compute

31. DynamoDB
Predictable and Scalable NoSQL Data Store
§ Fast, fully-managed NoSQL Database Service
§ Capable of handling any amount of data
§ Durable and Highly Available
§ All SSD storage
§ Simple and Cost Effective
Database

32. Microservices Architecture
Internet
Mobile
Apps
Websites
Services
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2
/ECS
Amazon Elastic
Beanstalk
Any other publicly
accessible endpoint
Amazon
CloudWatch
Monitoring
Amazon
API
Gateway

33. Principle 1
Microservices only
rely on each other’s
public API
“Contracts” by NobMouse. No alterations other than cropping.
https://www.flickr.com/photos/nobmouse/4052848608/
Image used with permissions under Creative Commons license 2.0, Attribution
Generic License (https://creativecommons.org/licenses/by/2.0/)

34. Micro-service A Micro-service B
public API public API
Principle 1:
Microservices only rely on each other’s public API

35. public API public API
Micro-service A Micro-service B
Principle 1:
Microservices only rely on each other’s public API
Hide your data!

36. public API public API
Nope!
Micro-service A Micro-service B
Principle 1:
Microservices only rely on each other’s public API
Hide your data!

37. public API public API
Micro-service A Micro-service B
Principle 1:
Microservices only rely on each other’s public API
Hide your data!

38. Principle 1:
Microservices only rely on each other’s public API
storeRestaurant (id, name, cuisine)
Version 1.0.0
public API
Micro-service A
Evolve API in backward-compatible way .. And document!

39. Principle 1:
Microservices only rely on each other’s public API
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.0.0
Version 1.1.0
public API
Micro-service A
Evolve API in backward-compatible way .. And document!

40. storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
storeRestaurant (id, name, arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.0.0
Version 1.1.0
Version 2.0.0
public API
Micro-service A
Evolve API in backward-compatible way .. And document!
Principle 1:
Microservices only rely on each other’s public API

41. Principle 2
Use the right tool for the
job
“Tools #2” by Juan Pablo Olmo. No alterations other than cropping.
https://www.flickr.com/photos/juanpol/1562101472/
Image used with permissions under Creative Commons license 2.0, Attribution
Generic License (https://creativecommons.org/licenses/by/2.0/)

42. public API public API
DynamoDB
Micro-service A Micro-service B
Embrace polyglot persistence
Principle 2:
Use the right tool for the job

43. public API public API
DynamoDB
Micro-service A Micro-service B
Amazon
Elasticsearch
Service
Embrace polyglot persistence
Principle 2:
Use the right tool for the job

44. public API public API
RDS
Aurora
Micro-service A Micro-service B
Embrace polyglot persistence
Principle 2:
Use the right tool for the job
Amazon
Elasticsearch
Service

45. public API public API
RDS
Aurora
Micro-service A Micro-service B
Amazon
Elasticsearch
Service
Embrace polyglot programming frameworks
Principle 2:
Use the right tool for the job

46. public API public API
RDS
Aurora
Micro-service A Micro-service B
Amazon
Elasticsearch
Service
Embrace polyglot programming frameworks
Principle 2:
Use the right tool for the job

47. Principle 3
Secure Your Services
“security” by Dave Bleasdale. No alterations other than cropping.
https://www.flickr.com/photos/sidelong/3878741556/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

48. • Defense-in-depth
• Network level (e.g. VPC, Security Groups, TLS)
• Server/container-level
• App-level
• IAM policies
• Gateway (“Front door”)
• API Throttling
• Authentication & Authorization
• Client-to-service, as well as service-to-service
• API Gateway: custom Lambda authorizers
• Token-based auth (JWT tokens, OAuth 2.0)
• IAM-based Authentication
• Secrets management
• S3 bucket policies + KMS + IAM
• Open-source tools (e.g. Vault, Keywhiz)
API Gateway
Principle 3:
Secure your services

49. Principle 4
Be a good citizen
within the ecosystem
“Lamington National Park, rainforest” by Jussarian. No alterations other than cropping.
https://www.flickr.com/photos/kerr_at_large/87771074/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)

50. Hey Sally, we need to call
your micro-service to
fetch restaurants details.
Sure Paul. Which APIs you need to
call? Once I know better your use
cases I’ll give you permission to
register your service as a client on
our service’s directory entry.
Micro-service A Micro-service B
public API public API
Principle 4:
Be a good citizen within the ecosystem

51. Distributed monitoring and tracing
• “Is the service meeting its SLA?”
• “Which services were involved in a request?”
• “How did downstream dependencies perform?”
Shared metrics
• e.g. request time, time to first byte
Distributed tracing
• e.g. Zipkin, OpenTracing
User-experience metrics
Distributed monitoring, logging, and tracing
Principle 4:
Be a good citizen within the ecosystem

52. It’s a journey…
Expect challenges along the way…
• Understanding of business domains
• Coordinating txns across multiple
services
• Eventual Consistency
• Service discovery
• Lots of moving parts requires
increased coordination
• Complexity of testing / deploying /
operating a distributed system
• Cultural transformation

53. Long Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing, who’s
the owner?)
Difficult to scale
New releases
take months
Long time to add
new features
Architecture is hard to
maintain and evolve
Lack of innovation
Frustrated customers
Lack of agility
Challenges with monolithic software

54. AWS resources:
• Microservices without the Servers
https://aws.amazon.com/blogs/compute/
microservices-without-the-servers
• Microservices with ECS:
https://aws.amazon.com/blogs/compute/using-amazon-
api-gateway-with-microservices-deployed-on-amazon-ecs/
• Serverless Service Discovery:
https://aws.amazon.com/blogs/developer/
serverless-service-discovery-part-1-get-started/
• ECS Service Discovery:
https://aws.amazon.com/blogs/compute/
service-discovery-an-amazon-ecs-reference-architecture/
• Serverless Webapp - Reference Architecture:
https://github.com/awslabs/lambda-refarch-webapp
• Zombie Microservices Workshop:
https://github.com/awslabs/aws-lambda-zombie-workshop
Additional Resources

55. Assets Usage
Please use only the follow graphics