Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How Small Can Java Microservices Be?

How Small Can Java Microservices Be?

If you compromise you can make Java Microservices small - using technologies like Serverless (Amazon Lambda), OSGi or Java EE Application Server.

2350801025b8e8592dbaa8dd98a24cbb?s=128

Eberhard Wolff

September 16, 2016
Tweet

Transcript

  1. How Small Can Java Microservices Be? Eberhard Wolff Fellow, innoQ

    @ewolff
  2. http://continuous-delivery-buch.de/

  3. http://microservices-buch.de/ http://microservices-book.com/

  4. http://microservices-book.com/primer.html FREE!!!!

  5. Microservice Definition

  6. Microservices: Definition > No consistent definition > Microservices are modules

    > Independent deployment units > E.g. processes, Docker container > Microservice owned by one team
  7. Microservices: Definition Server / Container Server / Container Micro Service

    Micro Service
  8. Components Collaborate Micro Service Micro Service Link Data Replication REST

    Messaging
  9. Online Shop Order Catalog Search Billing Customer HTML / HTTP

  10. Online Shop Elasticsearch Spring Batch Oracle Spring MVC MongoDB Order

    Catalog Search Billing
  11. Microservices Stack

  12. Docker > Linux (soon Windows) > Shared kernel > Filesystem

    just stores diffs > Extremely light weight > Can run in cluster (e.g. Kubernetes, Mesosphere etc)
  13. Spring Boot > One build file > One Java class

    > = REST service + embedded Tomcat > Deploy: One Java Fat JARs > Alternatives: Dropwizard, Wildfly Swarm… > https://github.com/ewolff/spring-boot-demos
  14. Microservice = Fat JAR + Java EE programming model possible!

  15. Ideal size of a Microservice Team size Modularization Infrastructure Distributed

    Communication No absolute value! Replaceability Microservice Size
  16. Nanoservices

  17. Nanoservices?

  18. Nanoservices? #SRSLY?

  19. #SRSLY? YES!

  20. Nanoservices!= Microservices

  21. Nanoservices< Microservices

  22. Ideal size of a Microservice Team size Modularization Infrastructure Distributed

    Communication No absolute value! Replaceability Microservice Size
  23. Microservices= Independent Deployment Units

  24. Nanoservices= Independent Deployment Units

  25. Nanoservices use more light weight technologies

  26. Serverless

  27. Serverless > Deploy a function > Pay per call >

    Example: Amazon Lambda > Similar: Google Cloud Functions > Azure Functions > IBM OpenWhisk (Open Source)
  28. Serverless vs. PaaS

  29. Amazon Lambda > Service in the Amazon Cloud > Allows

    you to install individual functions > Java, JavaScript, Python
  30. Amazon Lambda vs. PaaS > Commercial model: Pay-per-call / RAM

    / processing time > Fine grained (e.g. database trigger, HTTP GET) > First million requests / 400.000 DB seconds FREE! > Can edit Python / JavaScript functions in the browser
  31. Lambda Function Command Line S3 Event Kinesis Stream DynamoDB SNS:

    Simple Notification Service SES: Simple EMail Service Cognito CloudWatch CloudFormation API Gateway (e.g. REST) Scheduled Events
  32. Amazon Lambda adds e.g. trigger to DynamoDB.

  33. Amazon Lambda + API Gateway = REST services.

  34. public class Main { public String myHandler(int myCount, Context context)

    { LambdaLogger logger = context.getLogger(); logger.log("received : " + myCount); return "Hi"+myCount; } }
  35. Deploy

  36. Deploy

  37. Deploy

  38. Deploy

  39. Deploy

  40. Deploy

  41. Deploy

  42. Invoke

  43. Invoke

  44. Invoke

  45. Invoke

  46. Invoke

  47. Invoke

  48. None
  49. None
  50. Amazon Lambda > Can add any other Amazon Service to

    complete the system > i.e. Beanstalk PaaS, EC2 IaaS … > Or databased (DynamoDB, RDS...)
  51. Send out slides via email!

  52. Lambda Function Simple Email Service SMTP Simple Email Service Event

    calls Audience Cost: SES 0,10$ per 1000 EMails Lambda free
  53. > Developed in Python > In the browser > ”Save

    & test” > Includes monitoring & alarm > Setting up SES was the hardest part…
  54. None
  55. OSGi

  56. OSGi: Bundles > Partition system into – "bundles” > Bundles

    can be installed, started, stopped, uninstalled and updated > ...at runtime
  57. OSGi: Code Sharing > Bundles can export and import packages

    > Updating code requires other bundles to start fresh
  58. OSGi: Services > Bundles can publish services… dynamically! > Service

    = Java Object > Service Registry allows other bundles to consume services > Services come and go at runtime > Quite easy with OSGi Blueprints or OSGi Declarative Services
  59. Calling Bundle Bundle (interface code) Bundle (implementation and service) Service

    Package (interface code) Package (interface code) Update to service in running application
  60. (Almost) Independent Deployment Units

  61. Java EE

  62. Java EE > JARs e.g. for EJBs > WARs e.g.

    for web application > EARs for JARs and WARs > Completely separated code > …unlike OSGi
  63. Java EE > Relevant: Deployment model > i.e. application server

    > Not programming model
  64. Java EE Nanoservices? > Local calls not possible > No

    shared code e.g. for interfaces
  65. Tomcat Java EE Server order.war customer.war catalog.war Customer

  66. (Almost) Independent Deployment Units

  67. Comparison

  68. Independent Deployment > THE feature of Micro-/Nanoservices > Simplifies to

    put new features in production > Docker Fat JAR: ++ > Amazon Lambda: ++ > OSGi: + Restart the whole JVM? > Java EE: + Restart the whole JVM?
  69. Benefits of Nanoservices

  70. Effort per Service > How hard is it to create

    another service? > All: Create another project/JAR/WAR > Amazon Lambda: ++ > OSGi: ++ > Java EE: ++ > Docker Fat JAR : - (Docker container etc)
  71. Cost per Service > Hardware, software cost > Amazon Lambda:

    ++ > OSGi: ++ > Java EE: ++ > Docker Fat JAR: -- (need Docker container etc, separat JVM Heap)
  72. Local Communcation > Call without network stack > Docker Fat

    JAR : -- > Amazon Lambda: -- > OSGi: ++ > Java EE: --
  73. Challenges of Nanoservices

  74. Independent Scaling > Start more instances of a single service

    > Docker Fat JAR: ++ > Amazon Lambda: ++ > OSGi: ? > Java EE: --
  75. Isolation > CPU / Memory consumption/crash influences other services >

    Docker Fat JAR: ++ > Amazon Lambda: ++ > OSGi: -- > Java EE: --
  76. Resilience & Isolation > Resilience: System can handle crash of

    other services > Needs isolation > Problem for OSGi/Java EE
  77. Technology Freedom > Using different technologies > Docker Fat JAR:

    ++ (whatever) > Amazon Lambda: + (Java, JavaScript, Python) > OSGi: -- (Java) > Java EE: -- (Java)
  78. Conclusion

  79. Nanoservices!= Microservices

  80. Nanoservices< Microservices

  81. Conclusion > Nanoservice technologies compromise > …to allow smaller services

    > …to allow local communication > OSGi and Java EE deployment model don’t fully support independent deployment > …might therefore not be “true” Nanoservices
  82. Conclusion > OSGi and Java EE weak concerning > Independent

    scaling > Isolation > Technology freedom > Amazon Lambda a lot stronger
  83. Might also consider… > Vert.x: polyglot, distributed, module concept >

    Erlang: support update to running system and processes in other languages
  84. Thank You! @ewolff http://microservices-buch.de/ http://microservices-book.com/primer.html http://aws.amazon.com/lambda/getting-started/ http://www.heise.de/developer/artikel/ Nanoservices-kleiner-als-Microservices-3038541.html