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.

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

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…

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.warCustomer

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