Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Micro services

2,501 views

Published on

Presentation based on Sam Newman's book "Building Microservices", Martin Fowler's blog and Devoxx PL 2015 conference talks.

Published in: Software

Micro services

  1. 1. MICROSERVICES Mateusz Bukowicz
  2. 2. In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.These services are built around business capabilities and independently deployable by fully automated deployment machinery.There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- James Lewis and Martin Fowler
  3. 3. …suite of small services… The service can be rewritten and redeployed in 2 weeks -- Jon Eaves, realestate.com.au
  4. 4. …suite of small services… https://queue.acm.org/detail.cfm?id=1142065 If you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you. -- WernerVogels, 2006, interview Web Services
  5. 5. MICRO-SERVICES GROWTH INTIME RealEstate.com.au Noofmicro-services 0 10 20 30 40 50 60 70 3 months 6 months 18 months
  6. 6. gilt.com Noofmicro-services 0 50 100 150 200 250 300 2007 RoR monolith 2009 JVM 2011 Scala 2014 NodeJS MICRO-SERVICES GROWTH INTIME
  7. 7. …suite of small services… “two pizza teams” -- Jeff Bezos,Amazon
  8. 8. …running in its own process… http://martinfowler.com/articles/microservices.html
  9. 9. …built around business capabilities… 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 = software structure reflects organisation structure
  10. 10. …built around business capabilities… UI Business Logic Database frontend devs backend devs DBAs
  11. 11. CROSS-FUNCTIONALTEAMS
  12. 12. CROSS-FUNCTIONALTEAMS I am a designer I am a programmer I am a DBA I develop product X service ownership
  13. 13. Each service has a team associated with it, and that team is completely responsible for the service — from scoping out the functionality, to architecting it, to building it, and operating it. (…) Giving developers operational responsibilities has greatly enhanced the quality of the services. -- WernerVogels,Amazon service ownership Build DeployTest
  14. 14. …independently deployable… You don’t go and have a deep discussion with the Google Maps team just to use their Maps API: it's a reasonably stable API, you are isolated, it's sort of versioned, occasionally it changes and you may want to do things. -- Adrian Cockroft, (2010-2013 Netflix) http://www.infoq.com/interviews/adrian-cockcroft-microservices-devops
  15. 15. …independently deployable…
  16. 16. …bare minimum of centralised management… = decentralise all things
  17. 17. MICRO SERVICES WITH SPRING BOOT $ spring init --dependencies=web micro-service-1 $ spring init --list $ spring init --build=gradle --java-version=1.8 --dependencies=websocket --packaging=war customized-project $ spring run . -- --server.port=9000 $ spring test . $ java -jar target/micro-service-1.jar
  18. 18. MICRO SERVICES WITH SPRING BOOT @RestController public class MicroController2 { @RequestMapping("/service2") public String service2() { return "Hello from service 2"; } } @RestController public class MicroController1 { @RequestMapping("/service1") public String service1() { RestTemplate rest = new RestTemplate(); String response = rest.getForObject( "http://localhost:9002/service2", String.class); return "Response from service2: " + response; } }
  19. 19. ADVANTAGES • cheap to scale • fast to replace • fault tolerant (resilient) • promote modularity • parallelize development
  20. 20. DISADVANTAGES • network is not deterministic • lack of testing end-to-end • complicated deploy and versioning • a lot of new tools • eventual consistency in favour of transactions • more work and bigger dev costs
  21. 21. MICROSERVICESVS SOA Microservices = pragmatic SOA -- Adam Bien
  22. 22. MICROSERVICESVS SOA Fine-grained SOA -- Adrian Cockroft, Netflix
  23. 23. MICROSERVICESVS SOA With SOA, the intent is a layered architecture of co-operating services where SOA focuses on describing the organisation and co-ordination of the services.With micro services, the intent is to describe the nature of the services themselves and not quite so much the organisation and co-ordination of them. -- Jon Eaves, realestate.com.au
  24. 24. MICROSERVICESVS SOA We have gone from building a single ball of mud to orchestrating a lot of shit -- Hadi Hariri
  25. 25. MICROSERVICESVS SOA SOA means too many different things -- Martin Fowler http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
  26. 26. MICROSERVICESVS MONOLITH http://martinfowler.com/bliki/MicroservicePremium.html
  27. 27. MONOLITH FIRST http://martinfowler.com/bliki/MonolithFirst.html
  28. 28. DON’T START WITH A MONOLITH http://martinfowler.com/articles/dont-start-monolith.html
  29. 29. ?!
  30. 30. MICROSERVICESVS MONOLITH If you can't build a structured monolith, what makes you think micro-services is the answer?! -- Simon Brown
  31. 31. YOU MUST BETHISTALLTO USE MICRO SERVICES http://martinfowler.com/bliki/MicroservicePrerequisites.html
  32. 32. YOU MUST BETHISTALLTO USE MICRO SERVICES • DevOps • Continous Delivery no SSH to server realtime monitoring build pipeline click to deploy culture of automation
  33. 33. IS IT WORTH DITCHING THE MONOLITH? • 95% cases: totally not worth it • dvd.netflix.com: monolith for 6 mln users (2015)
  34. 34. MICROSERVICESVS MONOLITH Monolithic deployment of multiple components within a single WAR still remains the simplest possible solution for a mainstream project without any additional requirements. Unfortunately, simplest possible solutions are usually not buzzword- compatible :-). -- Adam Bien
  35. 35. 5% • optimisation madness? Micro-Services Certified • micro-services envy?
  36. 36. MICRO-SERVICES BEST PRACTICES
  37. 37. NEVER ENDING CONCEPTS Loose Coupling High Cohesion
  38. 38. POSTEL’S LAW Be conservative in what you send, 
 be liberal in what you accept -- Jon Postel Request Response
  39. 39. STANDARDISATION HTTP/REST SOAP MySQL PostgreSQL 2xx error codes 4xx/5xx error codes REST verbs REST nouns push monitoring pull monitoring Java/Scala/Groovy Ruby/Javascript/Python Redhat CentOS Dropwizard/Karyon Spring Boot
  40. 40. STANDARDISATION IMPLEMENTATION • exemplary service • service template existing service serving as an example the basis for other services
  41. 41. STRANGLER PATTERN
  42. 42. STRANGLER PATTERN 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 http://martinfowler.com/bliki/StranglerApplication.html
  43. 43. STRANGLER PATTERN CMS/ERP/CRM Recommendation (facade) Service 1 Service 2 Service 3
  44. 44. HIDE IMPLEMENTATION DETAILS API Boundary Sharing implementation details
  45. 45. BREAKING CHANGES API v1 v2
  46. 46. API v1 v2 blue green deployment canary release
  47. 47. CONSUMER-DRIVEN CONTRACT WITH PACT
  48. 48. public class Service2PactTest extends ConsumerPactTest { @Override protected PactFragment createFragment(ConsumerPactBuilder.PactDslWithProvider builder) { return builder .uponReceiving("Request for service 2") .path("/service2") .method("GET") .willRespondWith() .status(200) .body("Hello from service 2") .toFragment(); } @Override protected String providerName() { return "Service 2"; } @Override protected String consumerName() { return "Service 1"; } @Override protected void runTest(String url) throws IOException { Service2Client client = new Service2Client(url); String response = client.callService2(); assertEquals("Hello from service 2", response); } }
  49. 49. <build> <plugins> <plugin> <groupId>au.com.dius</groupId> <artifactId>pact-jvm-provider-maven_2.11</artifactId> <version>2.2.10</version> <configuration> <serviceProviders> <serviceProvider> <name>Service 2</name> <protocol>http</protocol> <host>localhost</host> <port>9002</port> <path>/</path> <consumers> <consumer> <name>Service 1</name> <pactFile>../micro-service-1/target/pacts/Service 1-Service 2.json</pactFile> </consumer> </consumers> </serviceProvider> </serviceProviders> </configuration> </plugin> </plugins> </build> $ mvn au.com.dius:pact-jvm-provider-maven_2.11:verify
  50. 50. SINGLE CORRELATION ID initial request request A: Correlation ID: 1005 request B: Correlation ID: 1005 request C:Correlation ID: 1005
  51. 51. AVOID SHARED DEPENDENCY API Shared model API Boundary
  52. 52. AVOID SHARED DEPENDENCY Don’t violate DRY within a micro service, but be relaxed about violating DRY across all services. -- Sam Newman,“Building Microservices”
  53. 53. ACQUIRING CONSISTENCY 1) distributed transaction INSERT retry2) retry INSERT DELETE rollback 3) compensating transaction Order Shipping placeOrder shipOrder ERROR!!!
  54. 54. PRODUCTION-LIKE ENVIRONMENTS
  55. 55. INFRASTRUCTURE AS CODE
  56. 56. ONE SERVICE PER CONTAINER
  57. 57. Our main focus is system containers.That is, containers which offer an environment as close to possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware. -- linuxcontainers.org
  58. 58. Container in a Container in a Container in a…
  59. 59. CIRCUIT BREAKER closed openhalf-open failure threshold reached timeout timer expired operation failed success count threshold reached always return failure increment failure counter on failure increment success counter on success start
  60. 60. FAIL FAST & GRACEFUL DEGRADATION UI Search find_movie(“Godzilla”) error find_movie(“Godzilla”) return default movies find_movie(“Godzilla”) return default movies circuit timeout find_movie(“Godzilla”) find_movie(“Godzilla”) successreturn search results
  61. 61. https://github.com/nurkiewicz/hystrix-demo
  62. 62. AGREGGATED MONITORING
  63. 63. DROPWIZARD METRICS http://metrics.dropwizard.io/
  64. 64. STORING METRICS Retention policies Noofsamplesper1hour 0 30 60 90 120 Within last 1h Older than 1h Older than 1 day Older than 1 week
  65. 65. CENTRAL SEARCHABLE LOGS
  66. 66. https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html
  67. 67. https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html
  68. 68. http://www.slideshare.net/renzotoma39/scaling-an-elk-stack-at-bolcom-39412550
  69. 69. http://www.slideshare.net/renzotoma39/scaling-an-elk-stack-at-bolcom-39412550
  70. 70. NETFLIXTOOLS netflix.github.io
  71. 71. GOOGLE KUBERNETES
  72. 72. DEIS
  73. 73. ATLAS (HASHICORP)
  74. 74. USEYOUR OWN STACK OFTOOLS
  75. 75. LEARN MORE 11 September 2015 Sopot, Poland incredible book single source of truth

×