SLlides prepared for Cloud Forward 2015 (Pisa)

1. Cloud Forward
2015
Augusto Ciuffoletti
Cloud Forward 2015
Automated deployment of a microservice-based
monitoring infrastructure
Augusto Ciuffoletti
6 ottobre 2015

2. Cloud Forward
2015
Augusto Ciuffoletti
Introducing two topics
The title:
Automated deployment of a microservice-based
monitoring infrastructure
Microservices
Monitoring on demand
Let us see how the two stories merge...

3. Cloud Forward
2015
Augusto Ciuffoletti
Introducing two topics
The title:
Automated deployment of a microservice-based
monitoring infrastructure
Microservices
Monitoring on demand
Let us see how the two stories merge...

4. Cloud Forward
2015
Augusto Ciuffoletti
Introducing two topics
The title:
Automated deployment of a microservice-based
monitoring infrastructure
Microservices
Monitoring on demand
Let us see how the two stories merge...

5. Cloud Forward
2015
Augusto Ciuffoletti
Introducing two topics
The title:
Automated deployment of a microservice-based
monitoring infrastructure
Microservices
Monitoring on demand
Let us see how the two stories merge...

6. Cloud Forward
2015
Augusto Ciuffoletti
Number one: Microservices
A design paradigm for distributed system
a book in O’Reilly "animal series" by S Newman
Principles:
each component in the system is designed to provide
one small, well defined service
each component is a stand alone entity that interacts
with others across a network with a well defined
interface

7. Cloud Forward
2015
Augusto Ciuffoletti
Number one: Microservices
A design paradigm for distributed system
a book in O’Reilly "animal series" by S Newman
Principles:
each component in the system is designed to provide
one small, well defined service
each component is a stand alone entity that interacts
with others across a network with a well defined
interface

8. Cloud Forward
2015
Augusto Ciuffoletti
Number one: Microservices
A design paradigm for distributed system
a book in O’Reilly "animal series" by S Newman
Principles:
each component in the system is designed to provide
one small, well defined service
each component is a stand alone entity that interacts
with others across a network with a well defined
interface

9. Cloud Forward
2015
Augusto Ciuffoletti
Number one: Microservices
A design paradigm for distributed system
a book in O’Reilly "animal series" by S Newman
Principles:
each component in the system is designed to provide
one small, well defined service
each component is a stand alone entity that interacts
with others across a network with a well defined
interface

10. Cloud Forward
2015
Augusto Ciuffoletti
Number one: Microservices
A design paradigm for distributed system
a book in O’Reilly "animal series" by S Newman
Principles:
each component in the system is designed to provide
one small, well defined service
each component is a stand alone entity that interacts
with others across a network with a well defined
interface

11. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

12. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

13. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

14. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

15. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

16. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

17. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

18. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

19. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

20. Cloud Forward
2015
Augusto Ciuffoletti
Reasons to adopt the microservices
paradigm
simplifies maintenance
e.g., upgrade one single component
agility in deployment
e.g., to scale up or down
each component may use a different technology
e.g., for technical or performance reasons
simplifies development
e.g., each component developed by a distinct team
robustness
e.g., if one component fails there is a chance that the
system still works

21. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

22. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

23. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

24. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

25. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

26. Cloud Forward
2015
Augusto Ciuffoletti
Number two: Cloud monitoring
A cloud user wants to have a functional feedback from
cloud sourced resources:
not necessarily to verify service quality
control a scalable resource,
provide feedback to the users,
trigger compensating actions
NIST indicates monitoring as one of the distinctive
features of cloud computing

27. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

28. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

29. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

30. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

31. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

32. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

33. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

34. Cloud Forward
2015
Augusto Ciuffoletti
Our option: on demand monitoring
Provide monitoring as part of the service
Give the user wide possibilities to configure a
monitoring infrastructure
Which metrics are captured and how data are
preprocessed and retrieved
Scale from simple to complex infrastructures
Do not overkill the problem in simple cases
Cope with complex infrastructures
Resource agnostic
Basic functionalities and unlimited pluggable
extensions

35. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

36. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

37. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

38. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

39. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

40. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

41. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

42. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

43. Cloud Forward
2015
Augusto Ciuffoletti
Find a match
Monitoring is by nature split into small components
(remember Nagios)
monitoring probes are small components, possibly
embedded
monitoring data crosses a pipe of processors
(anonymization, aggregation etc)
data is finally published using an endpoint reachable
from the outside (database, web service)
Each component is supported by a specific
technology
e.g., network monitoring vs storage monitoring
The on demand nature requires agility in deployment
the cloud user that obtains a new resource may want
to monitor it
There is a match between
microservices and on demand monitoring

44. Cloud Forward
2015
Augusto Ciuffoletti
Summarizing: a IaaS provisioning
IaaS is just for the example: could be PaaS or
anything else

45. Cloud Forward
2015
Augusto Ciuffoletti
A monitoring infrastructure
Adding a monitoring infrastructure:
probes that collect monitoring data (collectors)
a device that processes monitoring data (sensor)

46. Cloud Forward
2015
Augusto Ciuffoletti
A monitoring infrastructure
Adding a monitoring infrastructure:
probes that collect monitoring data (collectors)
a device that processes monitoring data (sensor)

47. Cloud Forward
2015
Augusto Ciuffoletti
A monitoring infrastructure
Adding a monitoring infrastructure:
probes that collect monitoring data (collectors)
a device that processes monitoring data (sensor)

48. Cloud Forward
2015
Augusto Ciuffoletti
A cloud interface
we need to design an interface
an open standard exists: OCCI

49. Cloud Forward
2015
Augusto Ciuffoletti
A cloud interface
we need to design an interface
an open standard exists: OCCI

50. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

51. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

52. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

53. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

54. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

55. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

56. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

57. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

58. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

59. Cloud Forward
2015
Augusto Ciuffoletti
Open Cloud Computing Interface basics
The interface is REST, therefore web-oriented
The items accessed across the interface are entities
One type of entity is the resource
Another is the link, that connects two resources
A type is characterized by standard features of the
instances
attributes whose values define instances
actions that model dynamic change
The interface is extensible:
a type can be subtyped, thus adding new attributes
to the standard ones
an instance can be modified using mixins

60. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

61. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

62. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

63. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

64. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

65. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

66. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

67. Cloud Forward
2015
Augusto Ciuffoletti
An OCCI model for monitoring
A Sensor is a subtype of the Resource type
A Collector is a subtype of the Link type
Add Mixins to specify the type of activity
Legenda:
the sensor (red) is an OCCI resource
the collectors (blue) are OCCI links
computing boxes and the network are OCCI
resources too

68. Cloud Forward
2015
Augusto Ciuffoletti
How do we do that?
We want to study the big arrow in the figure
How do we implement a monitoring infrastructure starting
form OCCI entities

69. Cloud Forward
2015
Augusto Ciuffoletti
How do we do that?
We want to study the big arrow in the figure
How do we implement a monitoring infrastructure starting
form OCCI entities

70. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

71. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

72. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

73. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

74. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

75. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

76. Cloud Forward
2015
Augusto Ciuffoletti
Vintage programming but...
For an early prototype we selected seasoned
technologies: Java/Unix sockets/Unix Pipes
not bound to specific programming tools
better solutions do exist
As a virtualization platform we selected Docker
demo is easely reproduceable/shareable
efficient to run on a single laptop
upgradeable to a real deployment

77. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

78. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

79. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

80. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

81. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

82. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

83. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

84. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

85. Cloud Forward
2015
Augusto Ciuffoletti
Deploying a demo infrastructure
The minimal architecture (4 dockers):
one HTTP server to host the OCCI entities
descriptions
one dashboard to display monitoring data
one monitored compute resource
one sensor resource
In OCCI view
One compute resource
One sensor resource
One collector link

86. Cloud Forward
2015
Augusto Ciuffoletti
The web server
The web server is deployed (with OCCI docs)
this is part of the cloud infrastructure

87. Cloud Forward
2015
Augusto Ciuffoletti
The web server
The web server is deployed (with OCCI docs)
this is part of the cloud infrastructure

88. Cloud Forward
2015
Augusto Ciuffoletti
The dashboard
The dashboard is deployed (UDP to receive data)
this is on user premises

89. Cloud Forward
2015
Augusto Ciuffoletti
The dashboard
The dashboard is deployed (UDP to receive data)
this is on user premises

90. Cloud Forward
2015
Augusto Ciuffoletti
The computing resource
The virtual computing resource is deployed
the RMI interface is for configuration

91. Cloud Forward
2015
Augusto Ciuffoletti
The computing resource
The virtual computing resource is deployed
the RMI interface is for configuration

92. Cloud Forward
2015
Augusto Ciuffoletti
The sensor
It is the resource that implements the monitoring
uploads the collector across the RMI interface

93. Cloud Forward
2015
Augusto Ciuffoletti
The sensor
It is the resource that implements the monitoring
uploads the collector across the RMI interface

94. Cloud Forward
2015
Augusto Ciuffoletti
GO!
The dashboard receives the probe measurements...
...filtered by the sensor

95. Cloud Forward
2015
Augusto Ciuffoletti
GO!
The dashboard receives the probe measurements...
...filtered by the sensor

96. Cloud Forward
2015
Augusto Ciuffoletti
Conclusions
Microservices are appropriate for distributed
monitoring
The OCCI API is appropriate as the interface
A prototype is available on dockerhub (look for
occimon-live)
BYOD demo on stage tonight at 17:45

97. Cloud Forward
2015
Augusto Ciuffoletti
Conclusions
Microservices are appropriate for distributed
monitoring
The OCCI API is appropriate as the interface
A prototype is available on dockerhub (look for
occimon-live)
BYOD demo on stage tonight at 17:45

98. Cloud Forward
2015
Augusto Ciuffoletti
Conclusions
Microservices are appropriate for distributed
monitoring
The OCCI API is appropriate as the interface
A prototype is available on dockerhub (look for
occimon-live)
BYOD demo on stage tonight at 17:45

99. Cloud Forward
2015
Augusto Ciuffoletti
Conclusions
Microservices are appropriate for distributed
monitoring
The OCCI API is appropriate as the interface
A prototype is available on dockerhub (look for
occimon-live)
BYOD demo on stage tonight at 17:45