Download as PDF, PPTX
Uploaded byEberhard Wolff
How Small Can Java Microservices Be?
The document discusses the concept of nanoservices and how they compare to microservices. Nanoservices are defined as being smaller than microservices, with independent deployment units that use more lightweight technologies. Examples discussed include Docker containers, AWS Lambda functions, OSGi bundles, and Java EE applications. While nanoservices aim to allow for smaller services and local communication, technologies like OSGi and Java EE have challenges with independent deployment and scaling. Serverless technologies like AWS Lambda provide stronger support for nanoservices through features like independent scaling, isolation, and technology freedom.
How Small Can Java Microservices Be?
- 1. How Small CanJava Microservices Be? Eberhard Wolff Fellow, innoQ @ewolff
- 2.
- 3.
- 4.
- 5.
- 6. Microservices: Definition > Noconsistent 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.
- 9.
- 10. Online Shop Elasticsearch Spring Batch Oracle SpringMVC MongoDB Order Catalog Search Billing
- 11.
- 12. Docker > Linux (soonWindows) > Shared kernel > Filesystem just stores diffs > Extremely light weight > Can run in cluster (e.g. Kubernetes, Mesosphere etc)
- 13. Spring Boot > Onebuild 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 = FatJAR + Java EE programming model possible!
- 15. Ideal size ofa Microservice Team size Modularization Infrastructure Distributed Communication No absolute value! Replaceability Microservice Size
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. Ideal size ofa Microservice Team size Modularization Infrastructure Distributed Communication No absolute value! Replaceability Microservice Size
- 23.
- 24.
- 25. Nanoservices use more lightweight technologies
- 26.
- 27. Serverless > Deploy afunction > Pay per call > Example: Amazon Lambda > Similar: Google Cloud Functions > Azure Functions > IBM OpenWhisk (Open Source)
- 28.
- 29. Amazon Lambda > Servicein 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 + APIGateway = 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.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 50. Amazon Lambda > Canadd any other Amazon Service to complete the system > i.e. Beanstalk PaaS, EC2 IaaS … > Or databased (DynamoDB, RDS...)
- 51. Send out slides viaemail!
- 52. Lambda Function Simple Email Service SMTP Simple Email Service Event calls Audience Cost:SES 0,10$ per 1000 EMails Lambda free
- 53. > Developed inPython > In the browser > ”Save & test” > Includes monitoring & alarm > Setting up SES was the hardest part…
- 55.
- 56. OSGi: Bundles > Partitionsystem 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 > Bundlescan 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.
- 60.
- 61.
- 62. Java EE > JARse.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.
- 66.
- 67.
- 68. Independent Deployment > THE featureof 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.
- 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 > Callwithout network stack > Docker Fat JAR : -- > Amazon Lambda: -- > OSGi: ++ > Java EE: --
- 73.
- 74. Independent Scaling > Startmore 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 > Usingdifferent technologies > Docker Fat JAR: ++ (whatever) > Amazon Lambda: + (Java, JavaScript, Python) > OSGi: -- (Java) > Java EE: -- (Java)
- 78.
- 79.
- 80.
- 81. Conclusion > Nanoservice technologiescompromise > …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 andJava 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.