Uploaded byAngelo van der Sijpt
Device deployment
The document provides a high-level overview of Apache ACE, which is a software distribution framework based on OSGi that aims to automate the deployment of software bundles across many devices. It discusses how Apache ACE organizes artifacts into features and distributions, maps distributions to targets, and provides a user interface to interact with its deployment repository. It also describes how Apache ACE uses management agents, deployment administrators, and relay servers to deploy packages from a development to a production environment in a consistent and automated way.
![[Harvard CS264] 04 - Intermediate-level CUDA Programming](https://cdn.slidesharecdn.com/ss_thumbnails/cs264201104-cudaintermediatesharetmpopt-110215180915-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Device deployment
- 1. distribu(ng, managing and monitoring a large number of devices “I really should think of a shorter (tle”
- 2.
- 3. $ whoami $ idkarl_pauls id: karl_pauls: no such user
- 4. $ whoami • Angelo van der Sijpt •CommiAer with Apache ACE • SoDware engineer at Luminis SoDware Development • Buzzwords: Java, OSGi, Agile • angelos@apache.org angelo.vandersijpt@luminis.eu
- 7.
- 21. User soDware: Linux Embedded: ARM
- 22. User soDware: Linux Embedded: Linux ARM
- 23.
- 24. the requirements • Embedded device •Lots of them! • Custom hardware • Remote control • Data collec(on & synchroniza(on • Extensible
- 25. OSGi • Dynamic system •Changing requirements • Changing technology • Changing deployment • Working with hardware • Using hardware • Upda(ng firmware
- 26.
- 27.
- 28. device drivers Bundle-NativeCode: win32.dll; osname=WindowsXP;processor=x86 , liblinux.so; osname=linux
- 29.
- 30. reuse func(onality State Sync Store State Sync Store store u(l Servlet store u(l Servlet
- 31. reuse func(onality Sync client State Sync Store State Sync Store store u(l Servlet store u(l Servlet
- 32. reuse func(onality Sync Sync client server State Sync Store State Sync Store store u(l Servlet store u(l Servlet
- 33.
- 36. • Started in incubator on april 24th 2009 • SoDware distribu(on framework based on OSGi • 12 commiAers • working codebase • hAp://incubator.apache.org/ace/
- 37. !"#$%&'(! +%",-'(! !"#$%&'() +%",-'() !"#$%&'(* +%",-'(*
- 38. !"#$%&'(! +%",-'(! !"#$%&'() !"#$%&'"() +%",-'() !"#$%&'(* +%",-'(*
- 39. now !"#$%&'(! +%",-'(! !"#$%&'() +%",-'() !"#$%&'(* +%",-'(*
- 40. last year !"#$%&'(! *%"+,'(! last month !"#$%&'(! !"#$%&'() *%"+,'(! last week !"#$%&'(! !"#$%&'() +%",-'(! *%"+,'(- *%"+,'() now !"#$%&'(! +%",-'(! !"#$%&'() +%",-'() *%"+,'(- !"#$%&'() !"#$%&'(* +%",-'() +%",-'(* !"#$%&'(* +%",-'(*
- 41. why? • Automate deployment • Insight into who uses what •History of each system • Consistent development, tes(ng, produc(on • Basis for several possible extensions
- 42. Topology !"#$%! 0"&"$%0%&!. "$%&! !"#$%! /2,%&! *#(+,-,(&,&$. 0"&"$%0%&!. &%!'(#) -%#+%# "$%&! !"#$%! 0"&"$%0%&!. "$%&! /(0*(&%&!. #%*(-,!(#1
- 43. High level overview !"#"$!"$%&' !"#$%&'"() ()$)*"("$+ !""#$%&'
- 44.
- 45. Organizing ar(facts • group ar(facts: makes them manageable • two levels: feature and distribu(on •Analogy: IKEA catalog • data is kept in “store repository” !"#$%&'%(#)*"#$+ ,$-./0" 5%/"3$% 1*)"$*23-#4
- 46. Mapping them onto targets • mapping distribu(ons to targets • some(mes done by an external system •data kept in “license repository” !"#$%&$'($)*&"+*,- ."&+,"/01*% 23,4$+
- 47.
- 48. High level overview !"#"$!"$%&' !"#$%&'"() ()$)*"("$+ !""#$%&'
- 49.
- 50. High level overview !"#$%&'"() !"#$%&'"()*+"#%,-)%.& /0.1") 2.3405)
- 51. Deployment Repository &!"-)&' ()"'*+,' !"#$!%&' 1 0/12323 7/12323 4 0/12423 7/12323 8/42323 .!"-)&/0 5 0/12423 8/42323 9/1232: 6 8/42323 9/52323 1 7/12323 9/52323 .!"-)&/7 4 0/12123 7/12321 9/1232:
- 52. Topology !"#$%! 0"&"$%0%&!. "$%&! !"#$%! /2,%&! *#(+,-,(&,&$. 0"&"$%0%&!. &%!'(#) -%#+%# "$%&! !"#$%! 0"&"$%0%&!. "$%&! /(0*(&%&!. #%*(-,!(#1
- 53. Management Agent !"#"$%!%#&'"$%#& *'.#"/0#, '('.# "#10)-2#$34 (/"!340)6 3(*5 !"#$%&'(%)$ "!*')+#,-
- 54. Deployment Admin • deployment packages • versioned set of ar(facts •transac(onal install/update • fix packages provide deltas • signing makes them secure • extensible through resource processors • AutoConfig defines configura(on admin data
- 55. From dependency to deployment !"#$%&'%(#)*"#$+ 6*0%4)%&'%(#)*"#$+ 1%(9#+:%4"&'%(#)*"#$+ ,$-./0" 5%/"3$% 1*)"$*23-#4 + 1*)"$*23-#4 7/$8%" = 7/$8%" ,$-./0"
- 56. High level overview !"#"$!"$%&' !"#$%&'"() ()$)*"("$+ !""#$%&'
- 57.
- 58. Feedback !"#$%! *#(+,-,(&,&$. /"&"$%/%&!. &%!'(#) -%#+%# "$%&! 012,!. 012,!. 3($ 3($ !=#".%@A*?B*-%45(%23-'+*,C%151*%4521- $"#$E%;21-<*%$"%,+533*- !:#". !D#".!"#$"%&'()*+%,+'(+*- $"#$9 !"#$"%&'()*+%,+'(+*- $E#".!"#$.%/+'(01)%23-'+*%4(56%7*(,851%9%+5%: $"#.9 !"#$.%/+'(01)%23-'+*%4(56%7*(,851%9%+5%: $!#".!"#$.%;21-<*%"=%23-'+*- E$#$$ !"#$.%;21-<*%"=%23-'+*- !"#$9%>3-'+*%+5%7*(,851%:%,2??**-*- E9#$$ !"#$9%>3-'+*%+5%7*(,851%:%,2??**-*- !.#$9%&'()*+%,+533*- !.#$9%&'()*+%,+533*-
- 59.
- 61.
- 62.
- 63. “The Wild” Apache ACE Web server
- 64. Development “The Wild” Apache ACE Web server
- 65. Apache ACE “The Wild”
- 66. Configura(on Apache ACE “The Wild”
- 67. Configura(on Apache ACE Feedback “The Wild”
- 68. • Deployment informa(on •No more version numbers to remember! • Remember the addi(onal devices? • SoDware on the fly
- 69. • Some numbers •100 bundles of 10MB total • 300 targets • 4 minutes
- 70.
- 71.
- 72. Apache ACE Relay servers
- 73. Deployment metadata Apache ACE Relay servers
- 74. Deployment Deployment package metadata Apache ACE Relay servers
- 75. Deployment Deployment package metadata Apache ACE Feedback Relay servers
- 76. Deployment Deployment package metadata Apache ACE Feedback Feedback Relay servers
- 77.
Editor's Notes
- #2 \n
- #3 NOTE: I am not Karl Pauls; something came up at the last moment\n
- #4 \n
- #5 \nImage of transformer: http://www.flickr.com/photos/mrbill/2547622226/in/photostream/\nImage of phone: @m4rr5\n
- #6 \nImage of transformer: http://www.flickr.com/photos/mrbill/2547622226/in/photostream/\nImage of phone: @m4rr5\n
- #7 Who recognizes this? It&#x2019;s a bridge rectifier.\nAnd what does it do? It converts AC to DC, but at loss of energy.\nMost devices you own actually don&#x2019;t need AC at all (perhaps only your washing machine); everything else is happy with DC.\n
- #8 Moixa has a vision of putting a Home Energy System in your house, which provides your house with a DC network (USB 3.0 based). Now we have a smart hub in your home, you can control it using your mobile phone, and check your power usage.\n\nVideo: http://www.youtube.com/watch?v=IEENXnp6-Ng\n
- #9 So there we have it: for a greener future, we now have\na box,\nand and idea\nI have not shown it, but possible extensions for now:\n- solar panels,\n- small battery that charges during the night\nand who knows what else!\n\nBackground image: http://www.flickr.com/photos/kylebaker/4511795125/\n
- #10 So there we have it: for a greener future, we now have\na box,\nand and idea\nI have not shown it, but possible extensions for now:\n- solar panels,\n- small battery that charges during the night\nand who knows what else!\n\nBackground image: http://www.flickr.com/photos/kylebaker/4511795125/\n
- #11 So there we have it: for a greener future, we now have\na box,\nand and idea\nI have not shown it, but possible extensions for now:\n- solar panels,\n- small battery that charges during the night\nand who knows what else!\n\nBackground image: http://www.flickr.com/photos/kylebaker/4511795125/\n
- #12 So there we have it: for a greener future, we now have\na box,\nand and idea\nI have not shown it, but possible extensions for now:\n- solar panels,\n- small battery that charges during the night\nand who knows what else!\n\nBackground image: http://www.flickr.com/photos/kylebaker/4511795125/\n
- #13 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #14 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #15 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #16 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #17 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #18 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #19 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #20 From a deployment perspective, it looks like this:\n- You have LED lighting and other peripherals in your home,\n- You connect the HES to this,\n- are able to control it directly using a web interface, e.g. on your phone,\n- and we want to be able to sync this to the internet.\n
- #21 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #22 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #23 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #24 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #25 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #26 The box contains\n- an embedded system based on an ARM processor, and\n- a piece of user software running linux\nThe server runs linux. Or actually, we don&#x2019;t really care.\n\nTime goal: between 10m and 15m in.\n
- #27 Note: we have seen OSGi in the morning, so I only need to highlight the things that are really necessary to understand this context.\n\n
- #28 \n
- #29 \n\n\n
- #30 Working with hardware and device drivers is hard. Actually, we would just like to package these as a bundle!\n\nImages: http://www.flickr.com/photos/squeezyboy/3300595223/\nhttp://www.ikea.com/us/en/catalog/products/50081452\n
- #31 Working with hardware and device drivers is hard. Actually, we would just like to package these as a bundle!\n\nImages: http://www.flickr.com/photos/squeezyboy/3300595223/\nhttp://www.ikea.com/us/en/catalog/products/50081452\n
- #32 Some words about Bundle-NativeCode:\n- package native drivers in your bundle,\n- let the framework decide which one to load,\n- use it as regular JNI.\nThe framework can also dynamically reload your libraries, without need for stopping the JVM.\n
- #33 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #34 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #35 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #36 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #37 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #38 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #39 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #40 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #41 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #42 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #43 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #44 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #45 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #46 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #47 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #48 For instance: we have a data store that represents the state of the device. The store and many peripherals are identical for server and client; only the role in synchronization is really different.\n\nSame thing applies to, for instance, the web ui.\n\nTime goal: Between 15 and 20m in.\n
- #49 \n
- #50 Pilot deployment: show a server and a single device. This didn&#x2019;t last long; very soon, we needed to manage more than one device, and more to the point, we needed to manage them remotely.\n
- #51 Enter: Apache ACE\n
- #52 \n
- #53 Step one: deployment\n\n
- #54 Deployment has a time component\n
- #55 Deployment has a time component\n
- #56 Deployment has a time component\n
- #57 Why?\n- insight into who uses what (and reproduce any config locally)\n- component A is broken, what&#x2019;s the damage/impact?\n- history of what happened to a target/system (&#x201C;no, I did not change anything&#x201D;)\n- integrate into build/test/QA cycle\n- basis for extensions such as: license mgmt, automated (re)install (the server burnt down/my mediabox broke -> minimum downtime)\n
- #58 This is the generic topology for ACE.\nin ACE we only store metadata\nthis avoids having IP in these repositories\nit also allows integration with different component repositories (OBR, Maven, Nexus, anything reachable via a URL)\nREST based interface\n
- #59 \n
- #60 - Organizing Artifacts\n- Mapping those to targets\n
- #61 Components are too fine grained to make sense to non-developers.\nTherefore we group them.\nWe have two levels of grouping: group and license\nAs an analogy, think of this as an IKEA catalog: individual components don&#x2019;t make sense to end users, so we provide them with pre-defined configurations\nAll of this information is kept in the &#x201C;store repository&#x201D;\n\n
- #62 Second part of dependency management is actually keeping track of which licenses are associated with which targets.\nSometimes this information is already available in an external system, so we can simply import it: ACE has an API for that.\nThis information is kept in a separate store, called the &#x201C;license repository&#x201D;.\n
- #63 Both the store and license repository come together in the current ACE web UI.\nHere the user can:\n - import new components from an OBR,\n - create groups and licenses,\n - define associations between them.\nThe way this works is that, like with subversion, the user first retrieves the latest version of the repositories. Then he can start making changes, and once he is satisfied, he can store those changes on the server.\n\n
- #64 \n
- #65 Dependency management was all about making things manageable for users.\nDeployment is about getting the right components to the right targets.\nIt has a different repository, containing:\n - a list of targets\n - a list of versions per target\n - a list of components per version\n\nThe other part of deployment is the actual management agent, which is installed on the target and is in charge of actually installing and updating components.\n
- #66 Targets have a version (for this target), and that consists of components.\nVersions are immutable; this allows replication.\n\n
- #67 Back to topology: we have seen the server, client and touched on the component repository. What&#x2019;s left: the management agent.\n\n
- #68 - The management agent consists of a number of building blocks. Distributed as separate jars, a &#x2018;fat jar&#x2019;, or even embedded in the framework.\n- Scheduler: when to connect to the server? We use a time-based scheduler, but this is pluggable.\n- The deployment task reaches out to the server:\n - it has to know who it is (identification, pluggable)\n - it has to know where to get to (discovery, pluggable)\n- The results of deployment are stored in the auditlog.\n- Finally, we cache our data, so we can e.g. quickly roll back to an older version.\n\nIf you now look at the management agent in ACE, it consists of the following components.\nI will expain how they work by describing the process of checking for updates and installing them.\nThis process starts with the scheduler.\nIt periodically triggers the deployment task.\nThis task then first asks the identification service for its own, unique name. Every target has to have some unique name, and this service actually allows you to implement different schemes for that.\nSecondly, it asks the discovery service for a URL to the server. Again this allows a flexible way of &#x201C;finding the server&#x201D;, the simplest implementation being one that returns a static URL.\nThen the server is actually contacted. The management agent asks which versions are actually available.\nThe server responds with a range of versions, as stored in the deployment repository.\nThe management agent knows its current version, so if the range includes a newer version, it will try to install it.\nAny life cycle changes that occur on the target (framework being restarted, bundles being started and stopped, updates being deployed) are recorded in the audit log which we will revisit a bit later. Finally, anything that gets downloaded can be stored in a cache that can be used to more quickly do things like rollbacks, install older versions, etc.\nSo that explains the different components in the management agent.\n
- #69 Let&#x2019;s now in more detail at the actual update process.\nFor that we rely on a service defined in the OSGi compendium, so it&#x2019;s actually a standard service, available at Apache Felix.\nDeployment Admin defines the notion of deployment packages, and in ACE we define such a deployment package for each target we have.\nA deployment package is a versioned set of artifacts or components.\nThese components can transactionally be installed or updated, so if anything goes wrong somewhere along the line then everything gets rolled back to its previous state.\nThere also is the notion of a fix package, which only contains the delta between two versions.\nYou can sign deployment packages to make them secure, or tamper proof.\nFinally, they are extensible through resource processors. This is actually a very cool feature, because it means that you can install any file type you want. You simply write a resource processor, which is just another bundle that gets deployed alongside the rest, and write some code to actually install and uninstall such a component. The resource processor obviously runs on the target, so you can use it for many different things. One such example, which is actually also part of the OSGi compendium, is the AutoConfig spec, which defines a new file type for configuration admin data, which gets installed in ConfigurationAdmin.\n\n
- #70 &#x201C;From dependency to deployment&#x201D;\n\nThe deployment repository is composed of the store- and license repository. You make all changes in the store- and license repositories, and generate the deployment repository based on that. We can now replicate the deployment repository (versions for targets are immutable, remember?)\n
- #71 \n
- #72 \n
- #73 Now let&#x2019;s look at the last subsystem: feedback.\n- We want to know what happened during deployment; we only know whether a deployment has succeeded if we see it in the audit log.\n- The auditlog basically contains information on framework events (system start, bundle start/stop/update, etc).\n - this gives you detailed information\n- Basis for extensions\n
- #74 Time goal: between 30m and 35m in\n
- #75 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #76 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #77 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #78 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #79 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #80 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #81 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #82 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #83 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #84 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #85 Once we had a few systems, we put ACE on an Amazon machine, and started pushing software to\n- the web server\n- the few devices in the wild, and\n- our own development environment.\n
- #86 As soon as we have a few devices, it&#x2019;s not only interesting to push software to the devices, but also configuration data. The feedback also becomes a very useful mechanism, since you don&#x2019;t &#x2018;see&#x2019; all devices anymore.\n
- #87 As soon as we have a few devices, it&#x2019;s not only interesting to push software to the devices, but also configuration data. The feedback also becomes a very useful mechanism, since you don&#x2019;t &#x2018;see&#x2019; all devices anymore.\n
- #88 As soon as we have a few devices, it&#x2019;s not only interesting to push software to the devices, but also configuration data. The feedback also becomes a very useful mechanism, since you don&#x2019;t &#x2018;see&#x2019; all devices anymore.\n
- #89 As soon as we have a few devices, it&#x2019;s not only interesting to push software to the devices, but also configuration data. The feedback also becomes a very useful mechanism, since you don&#x2019;t &#x2018;see&#x2019; all devices anymore.\n
- #90 \n\n\n
- #91 \n
- #92 The bigger we get, it&#x2019;s actually more of the same.\n\nNew features, like for instance battery control.\n
- #93 Thousands of devices?\n
- #94 Thousands of devices?\n
- #95 Thousands of devices?\n
- #96 Thousands of devices?\n
- #97 Thousands of devices?\n
- #98 Thousands of devices?\n
- #99 Thousands of devices?\n
- #100 Thousands of devices?\n
- #101 Thousands of devices?\n
- #102 Thousands of devices?\n
- #103 Thousands of devices?\n
- #104 Thousands of devices?\n
- #105 Thousands of devices?\n
- #106 \n