Introduction to Microservices
•
21 gefällt mir•20,306 views
by KD Singh, AWS Partner Solutions Architect, AWS
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Introduction to Microservices
Ähnlich wie Introduction to Microservices (20)
Mehr von Amazon Web Services
Mehr von Amazon Web Services (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Introduction to Microservices
- 1. KD Singh AWS Partner Solutions Architect Architecting Microservices on AWS March, 2017
- 2. What to expect from the session? • Review microservices architecture and how it differs from monolithic and service-oriented architectures • Key microservices design principles • Example design patterns for Micro-services in AWS • Demo • Q&A
- 3. Monolithic vs. SOA vs. Microservices SOA Coarse- grained Microservices Fine-grained Monolithic Single Unit
- 4. Okay, let’s start from the beginning…
- 5. First let’s discuss Software Monoliths, a poor approach to software design.
- 6. Break warehouse processes into few big blocks INBOUND • Track products traveling to the warehouse • Receive products • Prepare products to be stored • Store products • Handle inbound defects • … OUTBOUND • Pick customer orders • Prepare shipments • Track shipments • Handle outbound defects • …
- 7. Set up Software Teams INBOUND • Track products traveling to the warehouse • Receive products • Prepare products to be stored • Store products in the warehouse • Handle inbound defects • … OUTBOUND • Pick customer orders • Prepare shipments • Track shipments • Report defects • Handle outbound defects • … Inbound Software Team Outbound Software Team
- 8. Software Teams and Dependencies Inbound Software Team 50+ developers Shared libraries Outbound Software Team 50+ developers Inbound Software Monolith Outbound Software Monolith High software coupling!
- 9. Long Build/Test/Release Cycles Inbound Software Team Outbound Software Team Build Test Release Build Test Release • “I’m constantly having to resolve commit conflicts and merges. This is taking too much of my time!” • “Our last build attempt failed after 4 hours. We don’t know who broke the build as 30 commits were made” Massive builds Long time to run tests Ever growing release binaries
- 10. Problems With Monolithic Software System operation is a nightmare (module X is failing, who’s the owner?) Lack of agility (very long time to add new features) Lack of innovation (team always busy fixing inefficiencies) Long Build/Test/Release Cycles (who broke the build?) Software architecture is hard to maintain and evolve Scalability is compromised (vertical scalability) Slow development pace (developers busy fixing issues) Customers frustrated (new releases take months)
- 11. Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Melvyn Conway, 1967 So, it’s not only about changing the software architecture but also changing the way software teams are organized. … but How? http://www.melconway.com/Home/Conways_Law.html
- 13. What are Microservices? “A software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.”
- 14. The Anatomy of a Microservice Micro-service = Fine-grained Service-oriented architecture + “small” public API Micro-service Software Modules (application code, libraries, etc) Data Store (eg, DynamoDB, RDS, ElastiCache, S3) Public API addProductDetails(ProductId id, ProductDetails details) removeProductDetails(ProductId id) getProductDetails(ProductId id) : ProductDetails
- 15. Web of Microservices Store products in the warehouse Pick products for customers Report defects Track shipments Product Details
- 17. Benefits of Microservices for Amazon Build Test Release Build Test Release • 50 Million Deployments a Year • Software enhancements delivered every second Build Test Release Build Test Release Build Test Release Build Test Release … … … … … … Gigantic Web of Micro-services at Amazon 2-pizza Amazon Development Teams
- 18. Characteristics of Microservice Architectures Do one thing well Independent Decentralized Black box Polyglot You build it, you run it
- 20. public API Principle 1: Microservices only rely on each other’s public API public API Microservice A Microservice B
- 21. public API public API Principle 1: Microservices only rely on each other’s public API (Hide Your Data) Microservice A Microservice B
- 22. public API Nope! Microservice A Microservice B Principle 1: Microservices only rely on each other’s public API (Hide Your Data) public API
- 23. public API Microservice A Microservice B Principle 1: Microservices only rely on each other’s public API (Hide Your Data) public API
- 24. storeRestaurant (id, name, cuisine) Version 1.0.0 public API Microservice A Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!)
- 25. 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 Microservice A Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!)
- 26. 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 Microservice A Principle 1: Microservices only rely on each other’s public API (Evolve API in backward-compatible way…and document!)
- 27. public API public API DynamoDB Microservice A Microservice B Principle 2: Use the right tool for the job (Embrace polyglot persistence)
- 28. public API public API DynamoDB Microservice A Microservice B Amazon Elasticsearch Service Principle 2: Use the right tool for the job (Embrace polyglot persistence)
- 29. public API public API RDS MySQL Microservice A Microservice B Amazon Elasticsearc Service Principle 2: Use the right tool for the job (Embrace polyglot persistence)
- 30. public API public API RDS MySQL Microservice A Microservice B Amazon Elasticsearc Service Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks)
- 31. public API public API RDS Aurora Microservice A Microservice B Amazon Elasticsearc Service Principle 2: Use the right tool for the job (Embrace polyglot programming frameworks)
- 32. Principle 3: Secure Your Services • 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 • IAM-based Authentication • Token-based auth (JWT tokens, OAuth 2.0) • Secrets management • S3 bucket policies + KMS + IAM • Open-source tools (e.g. Vault, Keywhiz) API Gateway
- 33. 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
- 34. Restaurant Micro-service 15 TPS100 TPS5 TPS20 TPS Before we let you call our micro-service we need to understand your use case, expected load (TPS) and accepted latency Principle 4: Be a good citizen within the ecosystem
- 35. …and many, many others! 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 + User-experience metrics Distributed tracing • e.g. AWS X-Ray, Zipkin, OpenTracing, Wingtips Principle 4: Be a good citizen within the ecosystem
- 36. Principle 5: Automate everything AWS CodeCommit AWS CodePipeline AWS CodeDeploy EC2 ELB Auto ScalingLambdaECS DynamoDBRDS ElastiCache SQS SWF SES SNS API GatewayCloudWatch Cloud Trail KinesisElastic Beanstalk
- 37. Example Microservices Design Patterns in AWS
- 38. Simple EC2 based Microservice Architecture
- 39. Example Microservice Architecture on ECS
- 41. Demo
- 42. Questions?
Hinweis der Redaktion
- Siingle application layer within a monolith
- Teams depend on each other’s libraries + other common libraries “We’re blocked as we cannot build our software until you hand us the latest version of your library” Teams depend on each other’s database schema “We’re afraid the changes we’re making to our database schema will break your code”
- Microservices architectures are not a completely new approach to software engineering, but rather a collection and combination of various successful and proven concepts such as object-oriented methodologies, agile software development, service-oriented architectures, API-first design, and Continuous Delivery.
- Talk about implications of replicating data – and eventual consistency
- The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it. Semantic versioning
- The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it. Semantic versioning
- The public API is a contract between your micro-services and its clients and once released will have to be maintained for as long as clients rely on it. ## Semantic Versioning Adapt and implement good versioning strategy such as Semantic Versioning - http://semver.org MAJOR - version when you make incompatible API changes MINOR - version when you add functionality in a backwards-compatible manner, and PATCH - version when you make backwards-compatible bug fixes MAJOR version
- This goes both ways: Service registry Service owners have a responsibility – publish your health, monitor Clients have a responsibility to do exponential backoff – in case there are errors
- This goes both ways: Service owners have a responsibility – publish your health, monitor Clients have a responsibility to do exponential backoff – in case there are errors
- If it moves, it should be tracked and logged Spend more time working on code that analyses the meaning of metrics than code that collects, moves, stores and displays metrics Reduce key business metric latency to less than the human attention span (~10s) Validate your measurement system has enough accuracy and precision. Collect histograms of response time Monitoring systems need to be more available and scalable than the systems (and services) being monitored Optimise for monitoring distributed, ephemeral, 'cloud-native', containerised microservices Fit metrics to models in order to understand relationships (this is a new rule)
- But more important than the technologies are the principles we talked about.