Wednesday, 14 October 2015

TechRepublic: Samsung Architecture for Multimodal Interactions -> IoT + JVM

Samsung Wants to Help IoT Speak a Common Language

TechRepublic: What does SAMI stand for? Is it an acronym or something?
Dubreuil: SAMI is an acronym for Samsung Architecture for Multimodal Interactions. It’s our shorthand for what we call a data-driven platform with simple open APIs and SDKs to send and receive diverse data. We’ve tried to make it dead simple for developers to execute REST API calls to SAMI or set up WebSockets to receive data in real time.
It’s based on three big ideas critical to success in the cloud: users always own their own data, it’s a fully open ecosystem, and it’s data and device agnostic.
TechRepublic: What is Samsung’s goal with SAMI in IoT?
Dubreuil: Many developers are coming up with brilliant ideas for new devices that digitize our physical world and to capture existing or new signals that have never been available in digital form. But they carry the burden of always having to create new, complex back-end systems for receiving and processing device data from diverse sources.
Besides the time required to build the full stack from device to cloud to data services—and ensure privacy and security—too often, the end result is a device with its own proprietary cloud interfaces and siloed data.
And that is an IoT solution that has isolated itself from opportunities to correlate and fuse data with other IoT devices.
This, of course, defeats the benefits of IoT. For Samsung’s Strategy and Innovation Center, it’s the opportunity to join all of the data among IoT devices that has the highest upside for user value.





TechRepublic: So, tell me more about SAMI and what you guys have been building.
Dubreuil: We saw an opportunity to create an open ecosystem for IoT developers, which is aimed at gathering and making data more accessible, and liberating IoT developers from building the underlying plumbing for the systems.
With SAMI, we set out to create a data broker in the cloud that could handle any data, from any device or application. We saw SAMI functioning as a private data bank, with full security and privacy controls for developers and users. And we built it as a developer-oriented platform, with simple and powerful APIs and tools to accelerate developers’ journey to build and enable new IoT user experiences, services, and business models.
At the highest level, SAMI provides an abstraction layer for ingesting device data, processing, storing, routing, and accessing it through very developer-friendly APIs. SAMI deals with everything from data security, to real-time data, to transformations, aggregations, storage, user management, device management, and much more. SAMI also handles crucial aspects around security and privacy, which are mission critical in IoT cloud services.
By developing on top of a platform that allows easy and secure access to any kind of data, from any kind of device, and interconnects with other device platforms, IoT developers using SAMI can focus on building their added value to the ecosystem.
TechRepublic: Tell us a little bit about the technologies and architecture under SAMI’s hood.
Dubreuil: Under the hood, SAMI uses a broad range of today’s hottest programming languages, build tools, distributed frameworks, and technologies: Java, Scala, Play, Akka, Kafka, Zookeeper, Cassandra, ElasticSearch, MongoDB, TitanDB, Redis, MySQL, Spark, Samza, Mesos, Docker, Consul, and others to provide a number of advanced features and functionality.
From day one, the SAMI team knew we would be building the platform following Reactive principles. A data system must isolate failures, and SAMI’s mission required resilience under any load, at any scale.
Key to the resilience of the SAMI platform is its design as a microservices-based platform with Akka. Using Akka for fine-grained components isolation and Docker for deployment, SAMI is built for concurrency, scalability, and resilience on the JVM.
The isolation properties that Akka provides help protect the system against individual failures, and it also allows an efficient continuous deployment model. This approach frees the dev team to rapidly build out new features without having to maintain a monolithic application

No comments:

Post a Comment