Downloaded 165 times
![76CONFIDENTIAL
76
AFTER HATEOAS
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length:
{
"account": {
"account_number": "9999",
"balance": {
"currency": "usd",
"balance": "1100.00"
},
"links": [
{
"rel": "deposit",
"href": “/v1/account/9999/deposit"
},
{
"rel": "withdraw",
"href": "/v2/account/9999/withdraw"
},
{
"rel": "transfer",
"href": "/v1/account/9999/transfer"
},
{
"rel": "close",
"href": "/v1/account/9999/close"
}
]
}
}](https://image.slidesharecdn.com/microservicesarchitectureoverviewv3-160518155733/85/Microservices-architecture-overview-v3-72-320.jpg)
![76CONFIDENTIAL
76
AFTER HATEOAS
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length:
{
"account": {
"account_number": "9999",
"balance": {
"currency": "usd",
"balance": "1100.00"
},
"links": [
{
"rel": "deposit",
"href": “/v1/account/9999/deposit"
},
{
"rel": "withdraw",
"href": "/v2/account/9999/withdraw"
},
{
"rel": "transfer",
"href": "/v1/account/9999/transfer"
},
{
"rel": "close",
"href": "/v1/account/9999/close"
}
]
}
}](https://image.slidesharecdn.com/microservicesarchitectureoverviewv3-160518155733/75/Microservices-architecture-overview-v3-72-2048.jpg)
Uploaded byDmitry Skaredov
Microservices architecture overview v3
The document provides an overview of microservices architecture, highlighting its necessity due to the obsolescence of traditional linear architectures and the demand for agility. It outlines key principles and values of microservices, such as team independence, resilience, and technology agnosticism, as well as essential architecture patterns including API gateways and service discovery. Additionally, it discusses challenges like fault tolerance, request collapsing, and API versioning, underscoring the complexity of distributed systems.
More Related Content
Similar to Microservices architecture overview v3
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Microservices architecture overview v3
- 1. 1CONFIDENTIAL MICROSERVICES ARCHITECTURE OVERVIEW DZMITRY SKAREDAU,SOLUTION ARCHITECT MAY 17, 2016
- 2. 2CONFIDENTIAL 2 Follow my MicroservicesSeries • Microservices architecture overview • https://epa.ms/TechTalkMicroservices (Oct 08/Oct 16) • Spring Cloud + Netflix OSS overview • https://epa.ms/TechTalkSpringCloud (Mar 30) • Microservices and Domain Driven Design • Cloud Native applications: closer look • CI/CD for Microservices using Docker and Kubernetes • Spring Cloud workshop ABOUT Dzmitry Skaredau Solution Architect @dskaredov • ~15 years in software development • Java Competency Center Expert https://epa.ms/SkillsMatrix https://epa.ms/RnDSaaS https://epa.ms/JavaTechTalks (KB) https://epa.ms/MinskTechTalks (Yammer) https://epa.ms/Microservices (Yammer) https://epa.ms/JavaRadar
- 3. 3CONFIDENTIAL 3 • Why dowe need it • Architecture patterns AGENDA • Microservice • API Gateway • Service Discovery • Stateless/Shared-Nothing • Configuration/Service Consumption • Fault Tolerance • Request Collapsing • API Versioning • Decomposition Recipes • Q/A
- 4. 4CONFIDENTIAL WHY DO WENEED IT
- 5.
- 6. 6CONFIDENTIAL 6 Delivering world-class applicationsrequires an agile, multidimensional approach to architecture. It’s increasingly obvious that the old, linear, three-tier architecture model is obsolete. BECAUSE OF “ „ Gartner Application Architecture, Development & Integration Summit 2014
- 7. 7CONFIDENTIAL 7 Traditional application architecturesobsolete, and digital business demands more agility than ever. BECAUSE OF “ „ Anne Thomas, VP Distinguished Analyst 13 years at Gartner 36 years industry experience
- 8. 8CONFIDENTIAL 8 Users expect millisecondresponse times and close to 100% uptime. And by «user» I mean both humans and machines. Traditional architectures, tools and products such simply won’t cut it anymore. We can’t make the horse faster anymore, we need cars for where we are going. BECAUSE OF “ „ Jonas Bonér Founder & CTO of Lightbend (former Typesafe)
- 9. 9CONFIDENTIAL 9 MICROSERVICES VS MONOLITH Simplecode base Modularity with exact borders Change circles decoupled Efficient scaling Newcomers adopting faster Per service(s) team responsibility No technology lock MONOLITH MICROSERVICES Complex code base Hard to maintain modularity Change circles tightly coupled Inefficient scaling Scaring for newcomers Hard to scale development team Tied to chose technology
- 10. 10CONFIDENTIAL 10 MICROSERVICES VALUES Microservices Values Continues Delivery principles Bounded Context Team and ReleaseCycle independence System resilience Technology agnostic Independent scaling
- 11. 11CONFIDENTIAL 11 MICROSERVICES VALUES VSCOMPLEXITY Team autonomy Time to market Scaling Componentization Technology variation Cross teams communication Continues Deployment Fault tolerance Versioning Maintenance VALUES COMPLEXITY
- 12.
- 13. 13CONFIDENTIAL 13 ARCHITECTURE PATTERNS • Microservice •API Gateway • Service Discovery • Stateless/Shared-Nothing • Configuration Management • Fault Tolerance • Request Collapsing
- 14.
- 15. 15CONFIDENTIAL 15 NOT ABOUT SIZE,BUT RESPONSIBILITY Mario Fusco RedHatter, Drools developer, Java Champion, Milano Jug coordinator, speaker, co-author of Java 8 in Action. A functional mind hosted in an object oriented brain
- 16. 16CONFIDENTIAL 16 BOUNDED CONTEXT Bounded Contextis a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams.
- 17. 17CONFIDENTIAL 17 SIZE OF MICROSERVICE 2pizza size team Ideal Size 7 +/-2 persons
- 18. 18CONFIDENTIAL 18 DECENTRALIZED DATA MANAGEMENT Microservicesprefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence. You can use polyglot persistence in a monolith, but it appears more frequently with microservices.
- 19.
- 20.
- 21. 21CONFIDENTIAL 21 WHAT ABOUT DISTRIBUTEDTRANSACTIONS? In general, application developers simply do not implement large scalable applications assuming distributed transactions. Transactions are fine within the individual microservice “ „ Pat Helland, Software Architect SQL Architecture Team @ Microsoft Bing @ Microsoft Cloud based multi-tenanted file system and database technology @ salesforce.com
- 22. 22CONFIDENTIAL 22 I NEED A“DISTRIBUTED TRANSACTIONS” STILL Implement the Saga pattern and break the service interaction (the business process) into multiple smaller business actions and counteractions. Coordinate the conversation and manage it based on messages and timeouts. How can you reach distributed consensus between services without transactions? “ „ Arnon Rotem-Gal-Oz Author of the SOA Patterns book SAGA PATTERN
- 23. 23CONFIDENTIAL 23 DESIGN FOR FAILURE Distributedsystems are much complex than monolith. When we have more systems there is more chances to fail. If more places when you can fails then more often you can deal with failures.
- 24. 24CONFIDENTIAL 24 GRACEFUL DEGRADATION An escalatorcan never break: it can only become stairs. You should never see an Escalator Temporarily Out Of Order sign
- 25. 25CONFIDENTIAL 25 KEY CONSIDERATION Before yougo into production with a microservices system, you need to ensure that you have key prerequisites in place • DevOps Culture • Rapid Provisioning • Basic Monitoring / Debugging capabilities • Rapid Application Deployment
- 26. 27CONFIDENTIAL 27 MICROSERVICE VS SOA MartinFowler Chief Scientist at ThoughtWorks Subset of SOA Zhamak Dehghani Principal Consultant at ThoughtWorks Style of SOA
- 27.
- 28. 29CONFIDENTIAL 29 API GATEWAY How many microservices couldbe involved here?
- 29. 30CONFIDENTIAL 30 API GATEWAY ~9 How many microservices couldbe involved here?
- 30.
- 31. 32CONFIDENTIAL 32 API GATEWAY: REDUCECHATTINESS
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. 41CONFIDENTIAL 41 STATELESS/SHARED-NOTHING • Store stateat the client • Store state at database • Distributed session • Stateless services
- 40.
- 41. 43CONFIDENTIAL 43 SIMPLE CONFIGURATION http://12factor.net http://12factor.net/config The twelve-factorapp stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard. ENVIRONMENT VARIABLES
- 42. 44CONFIDENTIAL 44 ADVANCED CONFIGURATION • Changinglogging levels of a running application in order to debug a production issue • Change the number of threads receiving messages from a message broker • Report all configuration changes made to a production system to support regulatory audits • Toggle features on/off in a running application • Protect secrets (such as passwords) embedded in configuration COMPLEX CASES
- 43. 45CONFIDENTIAL 45 ADVANCED CONFIGURATION • Versioning •Auditability • Encryption • Refresh without restart NEEDED CAPABILITIES
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50. 52CONFIDENTIAL 52 POTENTIAL DOWNTIME Availability %Downtime per year Downtime per month Downtime per week Downtime per day 90% ("one nine") 36.5 days 72 hours 16.8 hours 2.4 hours 95% 18.25 days 36 hours 8.4 hours 1.2 hours 97% 10.96 days 21.6 hours 5.04 hours 43.2 minutes 98% 7.30 days 14.4 hours 3.36 hours 28.8 minutes 99% ("two nines") 3.65 days 7.20 hours 1.68 hours 14.4 minutes 99.5% 1.83 days 3.60 hours 50.4 minutes 7.2 minutes 99.8% 17.52 hours 86.23 minutes 20.16 minutes 2.88 minutes 99.9% ("three nines") 8.76 hours 43.8 minutes 10.1 minutes 1.44 minutes 99.95% 4.38 hours 21.56 minutes 5.04 minutes 43.2 seconds 99.99% ("four nines") 52.56 minutes 4.38 minutes 1.01 minutes 8.66 seconds 99.995% 26.28 minutes 2.16 minutes 30.24 seconds 4.32 seconds 99.999% ("five nines") 5.26 minutes 25.9 seconds 6.05 seconds 864.3 milliseconds 99.9999% ("six nines") 31.5 seconds 2.59 seconds 604.8 milliseconds 86.4 milliseconds 99.99999% ("seven nines") 3.15 seconds 262.97 milliseconds 60.48 milliseconds 8.64 milliseconds 99.999999% ("eight nines") 315.569 milliseconds 26.297 milliseconds 6.048 milliseconds 0.864 milliseconds 99.9999999% ("nine nines") 31.5569 milliseconds 2.6297 milliseconds 0.6048 milliseconds 0.0864 milliseconds Without taking steps to ensure fault tolerance, 30 dependencies each with 99.99% uptime would result in 2+ hours downtime/month (99.99%30 ≈ 99.7% uptime = 2+ hours in a month) http://techblog.netflix.com/2012/02/fault -tolerance-in-high-volume.html 0.3% means that the one million request will have 3000 failed
- 51. 53CONFIDENTIAL 53 CIRCUIT BREAKER The basicidea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually you'll also want some kind of monitor alert if the circuit breaker trips.
- 52.
- 53.
- 54. 57CONFIDENTIAL 57 FALLBACK DEGRADATION Fallback logicscene involving network access, such as cache access.
- 55.
- 56. 59CONFIDENTIAL 59 REQUEST COLLAPSING In additionto the isolation benefits and concurrent execution of dependency calls we have also need to leverage the separate threads to enable request collapsing (automatic batching) to increase overall efficiency and reduce user request latencies. Collapse multiple requests into a single execution based on a time window and optionally a max batch size. This allows an object model to have multiple calls to the command that execute/queue many times in a short period (milliseconds) and have them all get batched into a single backend call. Typically the time window is something like 10ms give or take.
- 57. 60CONFIDENTIAL 60 REQUEST COLLAPSING: UNDERTHE HOOD In addition to the isolation benefits and concurrent execution of dependency calls we have also leveraged the separate threads to enable request collapsing (automatic batching) to increase overall efficiency and reduce user request latencies. Collapse multiple requests into a single execution based on a time window and optionally a max batch size. This allows an object model to have multiple calls to the command that execute/queue many times in a short period (milliseconds) and have them all get batched into a single backend call. Typically the time window is something like 10ms give or take.
- 58.
- 59. 62CONFIDENTIAL 62 API VERSIONING • Addingauthentication • Adding authorization rules • Removing a service • API contract changes REASONS SOLUTIONS • URL Versioning • Media Type Versioning • Custom header • Hostname • Data parameter
- 60. 63CONFIDENTIAL 63 API VERSIONING One methodfor indicating versioning is via the URI, typically via a path prefix: Twitter: http://api.twitter.com/1.1/ Last.fm: http://ws.audioscrobbler.com/2.0/ Etsy: http://openapi.etsy.com/v2 Some APIs will provide the version via a query string parameter: Amazon Simple Queue Service: ?VERSION=2011-10-01 URL
- 61. 64CONFIDENTIAL 64 API VERSIONING Media typeversioning provides the ability to use the same URI for multiple versions of an API, by specifying the version as part of the Accept media type. The Accept header can provide versioning in two different ways: • As part of the media type name itself: application/vnd.status.v2+json. In this case, the segment v2 indicates the request is for version 2. You can provide the version string however you desire. • As a parameter to the media type: application/vnd.status+json; version=2. This option provides more verbosity, but allows you to specify the same base media type for each version. Many REST advocates prefer media type versioning as it solves the "one resource, one URI" problem cleanly, and allows adding versioning support after-the-fact. The primary argument against it is the fact that the version is not visible when looking at the URI. MEDIA TYPE
- 62. 65CONFIDENTIAL 65 API VERSIONING The abovetwo versioning types are the most common; however, other types exist: • Custom header. As an example, • X-API-Version: 2 • GData-Version: 2.0 • X-MS-Version: 2011-08-18 • etc. • Hostname. Facebook, when migrating from the first API version, switched from the host http://api.facebook.com to http://graph.facebook.com. • Data parameter. This could be a query string parameter for GET requests, as noted above, but a content body parameter for other request methods. OTHER METHODOLOGIES
- 63. 67CONFIDENTIAL 67 API VERSIONING It seemsthat there are a number of people recommending using Content-Negotiation (the HTTP “Accept:” header) for API versioning. However, none of the big public REST APIs I have looked at seem to be using this approach. They almost exclusively put the API version number in the URI.
- 64. 68CONFIDENTIAL 68 API VERSIONING Twitter URI AtlassianURI Google Search URI Github API URI/Media Type in v3 Intention is to remove versioning in favour of hypermedia – current application/vnd.github.v3 Azure Custom Header x-ms-version: 2011-08-18 Facebook URI/optional versioning graph.facebook.com/v1.0/me Bing Maps URI Netflix URI parameter http://api.netflix.com/catalog/titles/series/ 70023522?v=1.5
- 65. 69CONFIDENTIAL 69 API VERSIONING Google dataAPI (youtube/spreadsheets/others) URI parameter or custom header “GData-Version: X.0” or “v=X.0” Flickr No versioning? Digg URI http://services.digg.com/2.0/comment.bury Delicious URI https://api.del.icio.us/v1/posts/update Last FM URI http://ws.audioscrobbler.com/2.0/ LinkedIn URI http://api.linkedin.com/v1/people/~/connec tions Foursquare URI https://api.foursquare.com/v2/venues/40a55 d80f964a52020f31ee3?oauth_token=XXX&v=YY YYMMDD
- 66. 70CONFIDENTIAL 70 API VERSIONING paypal parameter&VERSION=XX.0 Twitpic URI http://api.twitpic.com/2/upload.format Etsy URI http://openapi.etsy.com/v2 Tropo URI https://api.tropo.com/1.0/sessions Tumblr URI api.tumblr.com/v2/user/ openstreetmap URI and response body http://server/api/0.6/changeset/create Ebay URI (I think) http://open.api.ebay.com/shopping?version= 713
- 67. 71CONFIDENTIAL 71 API VERSIONING Wikipedia noversioning I think? Bitly URI https://api-ssl.bitly.com/v3/shorten Disqus URI https://disqus.com/api/3.0/posts/remove.js on Yammer URI /api/v1 Drop Box URI https://api.dropbox.com/1/oauth/request_to ken Amazon Simple Queue Service (Soap) URI Parameter and WSDL URI &Version=2011-10-01
- 68. 72CONFIDENTIAL 72 AVOID BREAKING CHANGES DarrelMiller API Evangelist at Microsoft. Web APIs, Hypermedia APIs, REST based LOB systems are my area of expertise
- 69. 73CONFIDENTIAL 73 SELF-DESCRIBE PROTOCOLS Roy T.Fielding Senior Principal Scientist at Adobe, co-founded Apache, authored the REST architectural style and Web standards for URI, HTTP/1.x, and URI Templates
- 70.
- 71. 75CONFIDENTIAL 75 BEFORE HATEOAS HTTP/1.1 200OK Content-Type: application/json Content-Length: { "account": { "account_number": "9999", "balance": { "currency": "usd", "balance": "1100.00" } } }
- 72. 76CONFIDENTIAL 76 AFTER HATEOAS HTTP/1.1 200OK Content-Type: application/json Content-Length: { "account": { "account_number": "9999", "balance": { "currency": "usd", "balance": "1100.00" }, "links": [ { "rel": "deposit", "href": “/v1/account/9999/deposit" }, { "rel": "withdraw", "href": "/v2/account/9999/withdraw" }, { "rel": "transfer", "href": "/v1/account/9999/transfer" }, { "rel": "close", "href": "/v1/account/9999/close" } ] } }
- 73.
- 74. 78CONFIDENTIAL 78 #1: IF ITWORKS DON'T TOUCH IT
- 75. 79CONFIDENTIAL 79 #2: START NEWFEATURES AS MICROSERVICES ...the team decided that the best approach to deal with the architecture changes would not be to split the Mothership immediately, but rather to not add anything new to it. All of our new features were built as microservices... “ „ Phil Calcado, Director of Engineering, Core, SoundCloud
- 76.
- 77. 81CONFIDENTIAL 81 #4: STRANGLING THEMONOLITH ... gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. “ „ Martin Fowler
- 78. 82CONFIDENTIAL 82 #5: DECOMPOSITION CANDIDATES Startfrom bounded contexts identified within the monolith OR Identify the areas of the monolith’s code that will need to change in order to deliver the changed requirements, and then extract the appropriate bounded contexts before making the desired changes.
- 79. 83CONFIDENTIAL 83 WHEN TO STOP? Themonolith has been completely strangled Cost of additional service extraction exceeds the return on the necessary efforts
- 80.