Physical Web

Concepto de Physical Web:

La Physical Web  no es un producto de Google, es un proyecto experimental y que solo deberia ser para los desarrolladores que desean poner a prueba esta tipo de funcion.

La premisa basica sobre esto es que sea capaz de poder subir cualquier objeto fisico "inteligente" por ejemplo un carrito de emolientes, un carro, una laptop, etc y poder interactuar con el sin tener que descargar una aplicación. La experencia de usuario deberia ser muy sencilla solo tocar y usar.

¿Por que URls?

El valor de un URL es que es una parte conocida de la web, muy flexible, y lo más importante, descentralizada. URL permiten que cualquiera pueda jugar y hay un servidor central para ser el cuello de botella. Este es uno de los principios básicos de la web y fundamental para mantener viva.

Dicho esto, estamos completamente de esperar que otros experimentan con un modelo url + ID que va a través de su servidor (por ejemplo safeurls.com/?id=12345). Eso es perfectamente aceptable y debe fomentarse. Sistemas como que es probable que ofrecer mucho mejor la seguridad y la investigación de antecedentes de los sitios. Pero esa es la belleza de la URL, no puede haber tanto de éstos como desee y el sistema aún funciona a la perfección.

Una idea:

La Physical Web extiende de la web que conocemos en el mundo físico que nos rodea. Esto implica la creación de un ecosistema abierto donde los dispositivos inteligentes pueden transmitir las URL en el área alrededor de ellos. Cualquiera con un teléfono o tableta puede ver estas URL y ofrecerlos al usuario. Refleja el comportamiento básico que tenemos hoy con un motor de búsqueda.

¿Es Seguro?

URLs broadcast en el claro lo que cualquiera puede verlos. Esto es por diseño. Es por eso que estamos inicialmente sugiere que esto se utiliza en los espacios públicos. Esto plantea cuestiones para uso doméstico en el que sería posible para los vecinos para interceptar balizas. Sin embargo, una de las grandes ventajas de las URL es que hay tantas formas en que pueden ser utilizados para aumentar su seguridad.

¿Por que Web?

El valor principal de Web Física es permitir a un dispositivo para poner al alcance de cualquier cosa de los usuarios de una pequeña pieza de información basada en la ubicación para una aplicación web en toda regla.

* Un collar de perro podía dejar de llamar a un servicio de encontrar al dueño.

* Un autobús podría decirle su próxima parada.

* Un servicio de alquiler de bicicleta de ciudad podía dejar que se inscriba en el acto.

* Un aparato electrodoméstico podría ofrecer un tutorial interactivo.

* Un robot industrial puede mostrar información de diagnóstico.

* Un centro comercial podría ofrecer un mapa.

Cada uno de estos ejemplos, tomados por sí mismo, es moderadamente útil. Tomado en su conjunto, sin embargo, implican un gran "larga cola" donde cualquier cosa puede ofrecer información y utilidad. Aplicaciones nativas son grandes para el uso de alta frecuencia. La web permite a la gente subir y usar algo una vez sin apenas fricción.

Mensajeria con Apache Kafka

Introducción

Apache Kafka es un distribuidor que proporciona  la funcionalidad de un sistema de mensajería, 

pero con un diseño único y como distribuido registro de confirmación, beneficios:

Rápido

Es un único corredor Kafka puede manejar cientos de megabytes de lecturas y escrituras por 

segundo desde miles de clientes.

Escalable

El Kafka está diseñado para permitir que un solo grupo pueda servir como una columna vertebral 

central de datos para una gran organización. Puede ser elástica y transparente con un tiempo de 

inactividad. Los flujos de datos se dividen y se extienden sobre un grupo de máquinas para que los 

flujos de datos más grande que la capacidad de cualquier máquina única y permitir racimos de 

coordinados consumidores

Durable

Los mensajes se conservan en el disco y se replican dentro del cluster para evitar la pérdida de 

datos. Cada corredor puede manejar terabytes de mensajes sin impacto en el rendimiento.

Distribuido por Diseño

Kafka tiene un diseño moderno -cluster céntrica que ofrece durabilidad fuerte y de tolerancia a 

fallos. El registro se distribuye a través de los servidores del cluster Kafka con el manejo de datos 

como las solicitudes de una parte de las particiones de cada servidor. Cada partición se replica a 

través de un número configurable de servidores para la tolerancia a fallos.

Cada partición tiene un servidor que actúa como el "líder " y cero o más servidores que actúan 

como "seguidores". El líder se encarga leer  y escribir solicitudes de la partición mientras que los 

seguidores pasivamente replican el líder. Si el líder falla, uno de los seguidores se convertirá 

automáticamente en el nuevo líder. Cada servidor actúa como un líder para algunos de sus 

particiones y un seguidor de los demás para la carga está bien equilibrado dentro de la agrupación.

Por lo tanto, en de un nivel alto los productores envían mensajes a través de la red al cluster Kafka 

que a su vez les sirve a los consumidores:

La comunicación entre los clientes y los servidores se realiza de manera simple, de alto 

rendimiento, su lenguaje protocolo TCP. Proporciona a  clientes Java para Kafka y para los clientes 

están disponibles en muchos idiomas.

Temas y Logs

Primera inmersión nos dejó en la abstracción de alto nivel Kafka proporciona el temas de categoría 

o de alimentación a la que se publican los mensajes. El clúster Kafka mantiene un registro con cada 

partición es una orden, secuencia inmutable de los mensajes que se añade continuamente a un 

registro de confirmación. Los mensajes en las particiones son cada uno asignado a un número de 

identificación secuencial llamado el desplazamiento que identifica de manera única cada mensaje 

dentro de la partición. El cluster Kafka mantiene todo publicó mensajes o no han sido consumidos 

por un período de tiempo. 

Esta combinación de características significa que los consumidores Kafka son muy baratos, que 

pueden ir y venir sin mucho impacto en el clúster o en otros consumidores. Por ejemplo, puede 

utilizar nuestras herramientas de línea de comandos para "cola" el contenido de cualquier tema 

sin cambiar lo que se consume por cualquier consumidor existente.

Las particiones en el registro sirven para varios propósitos. En primer lugar, permiten el registro de 

escalar más allá de un tamaño que quepa en un solo servidor. Cada partición individuo debe caber 

en los servidores que hospedan, pero un tema puede tener muchas particiones para que pueda 

manejar una cantidad arbitraria de datos. Segundo actúan como unidad de paralelismo a más en 

que en un poco. Las particiones que tiene este aspecto:

Por último, el Storm incluye Apache Kafka un cluster distribuido de encolamiento que se distribuye

bajo la licencia Apache y que puede ser alimentado a través de una red o desde aplicaciones.

Kafka puede soportar una gran cantidad de datos de entrada y gratis a su escalabilidad puede 

mantener su funcionamiento de forma eficiente, dentro de Kafka el flujo de entrada puede ser 

particionado y repartido alrededor de las máquinas que componen el cluster. También es utilizada 

es la implementación de entradas para los datos de Twitter, mediante este modo serían 

distribuidos entre los diferentes nodos internos de la topología de los mensajes que serán 

procesados.

Microservicios en arquitectura monolitica

Microservicios

Una de las tendencias de diseño de las que se ha puesto de moda hablar recientemente son los microservicios. Para el que lo quiera entender de un plumazo, los microservicios son lo mismo que Service Oriented Architecture (SOA) pero cambiando los componentes Java Enterprise Edition (JEE) y los Enterprise Software Bus (ESB) por llamadas HTTP entre componentes escritos (posiblemente) en diferentes lenguajes y ejecutándose en diferentes máquinas.

Ejemplo:
El desarrollo de una pagina que tenga, el diseño, back-end y base de datos, esto es una aplicación monolitica.Una posibilidad es intercambiar ficheros de un lado para otro mediante FTP de toda la vida, lo cual sigue siendo muy válido para el intercambio de lotes, pero también habrá servicios de información y notificación en tiempo real que requerirán enlaces entre los servicios web de la tienda y los servicios web de los proveedores.

Arquitectura
Existe una teoría atribuida a Melvyn Conway en 1967 y ampliamente comprobada que afirma que el sistema que producirá una organización es isomorfo a la estructura de comunicación de las personas que lo desarrollaron. En las aplicaciones web y cliente servidor suele haber tres equipos: el de interfaz de usuario, el de middleware y el de bases de datos. Se dividen así por una cuestión de reparto de las competencias profesionales, pero desde el punto de vista del desarrollo de las funcionalidades que ve el usuario no existe ninguna razón por la cual haya que tener ingenieros de front, de back y y administradores de base de datos.


La arquitectura basada en microservicios propone que tanto el interfaz como las aplicaciones de usuario sean clientes de una colección de servicios que operan cada uno sobre un dominio.

Un gateway para los microservicios es necesario porque una página puede necesitar decenas de ellos y sería ineficiente realizar una llamada HTTP a cada microservicio desde el navegador. Además, el gateway puede lanzar en paralelo las peticiones a cada microservicio en lugar de ejecutar una única subrutina para obtener todos los datos necesarios para pintar una página web. Netflix utiliza este tipo de arquitectura basándose en RxJava

Desventajas:
Úna aplicación monolítica se instala con un programa especializado o se despliegua como un archivo WAR en un contenedor de servlets. Pero los microservicios pueden estar distribuidos en diferentes servidores y estar escritos en diferentes lenguajes. El uso de herramientas de generación de máquinas virtuales como Vagrant y de despliegue continuo como Jenkins es una necesidad imperiosa en las arquitecturas microservicios.

Los microservicios tampoco solucionan el problema del versionado. Lo que proponen es hacer resilientes los clientes a fallos en los microservicios proveedores, lo cual es más fácil de decir que de hacer.


Pero quizá el problema más grave es el mantenimiento de la consistencia de datos replicados entre los dominios de diferentes servicios. En la mayoría de las arquitecturas basadas en microservicios los datos son sólo eventualmente consistentes, lo que significa que es posible que dos clientes que se ejecutan en paralelo reciban resultados diferentes. El mayor error de diseño que yo he encontrado hasta ahora en las aplicaciones basadas en servicios es montar la replicación de forma explícita y carecer de un buen mecanismo de consolidación de datos. Conviene recordar que evitar la redundancia y la inconsistencia de datos fueron las dos razones principales para diseñar en un principio aplicaciones monolíticas transaccionales.

Programación Streaming con Apache Storm

Concepto de Streaming:

Primero, podemos hablar sobre el concepto de streaming, para llevarlo a cabo, se requiere contar con 

tres etapas fundamentales:

1.- Codificación del Contenido:

En este proceso, se va determinar la calidad y resolución que se desea utilizar como señal de audio y video. Es importante mencionar, que a mayor calidad, mayor consumo de ancho de banda que el usuario tendría que utilizar para reproducir el contenido.

2.-Transmisión de Contenido:

Aquí se comprende la recepción  del contenido  y el ajuste de la calidad durante el envio de la señal, para que pueda acoplarse a la  conexión que tiene el usuario que se encuentra reproduciendo el contenido.

3.- Reproducción del  Contenido:

Aquí, es donde surge el proceso de “descompresión” de la señal, este proceso se realiza de forma automática. Es igual de importante que las etapas anteriores, ya que el usuario requiere contar con una buena conexión a Internet.

Concepto de Apache Storm

Apache Storm es un sistema que sirve para recuperar streams de datos en tiempo real desde 

múltiples fuentes de manera distribuida.

Apache Storm es un sistema que sirve para recuperar streams de datos en tiempo real desde 

múltiples fuentes de manera distribuida, tolerante a fallos y en alta disponibilidad. Storm está 

principalmente pensado para trabajar con datos que deben ser analizados en tiempo real, por 

ejemplo datos de sensores que se emiten con una alta frecuencia o datos que provengan de las 

redes sociales donde a veces es importante saber qué se está compartiendo en este momento.

Se compone de dos partes principalmente. La primera es la que se denomina Spout y es la 

encargada de recoger el flujo de datos de entrada. La segunda se denomina Bolt y es la encargada 

del procesado o transformación de los datos.

En la documentación oficial representan los Spouts con grifos simulando la entrada de un stream 

de datos al sistema y a los Bolts con un rayo que es donde se realizan las acciones pertinentes con 

los datos de entrada.

Procesamiento Streamyng con Apache Storm 

Apache Storm aceptado como proyecto Apache incubator también es considerada como 

plataforma de Streaming Analytics de código abierto que permite el procesamiento en tiempo de 

real de flujos constantes o corriente 

Storm se integra con las tecnologías de Gestión de colas y bases de datos que utilizas, Storm 

Topology consume flujos de datos y procesa aquellas corrientes en forma complejas.

Companies & Projects Using Storm