Estás utilizando un navegador desactualizado. Puede que no muestre este u otros sitios web correctamente Deberías actualizar o utilizar un navegador alternativo.
Eso cilantritos.
Actualmente en mi pega tenemos un servidor para IOT, con herramientas basicas como MQTT, InfluxDB, Node.Red y Grafana.
Lo usamos como herramienta interna para analisis de datos industriales que usamos con 1 o 2 clientes.
El tema es que ahora ya tenemos pulido el desarrollo y escalaremos la solucion para ofrecerles el servicio a clientes en forma global, pero queremos migrar el servidor a la nube.
Google cloud en mi opinión es mejor en cuanto a precio calidad, sus VM me ha resultado más rápidas , en contraste a AWS que debes pagar un riñón para tener una VM decente, ni pensar en un medium o un small, esas weas no aceptan ni CentOS, q es el más eficiente
Te sugiero que agarres la calculadora y compares precios según lo que necesites, estoy de acuerdo con el cipa sobre Google y aws puta que duele el bolsillo con esos klos, azure es bastante decente pero enserio que todo depende de lo que requieras en el día a día y obviamente del presupuesto que dispongas
Como dicen los compitas arriba, lo primero, el presupuesto, lo segundo es ver que es lo que necesitas realmente, algunos hablan de VM pero para que necesitas VM si puedes crear Docker y los puedes portar a cualquier cloud y probar. Cosas que debes tener en consideracion:
Arquitectura, necesitas todo en modo administrado? tienes el equipo con los skills? serverless?
Volumetria (cuanto quieres almacenar y como)
Storage (ciclo de vida de tus objetos) tienes que definir bien la estratega de datos
Ingesta, si te quieres despreocupar del streaming, confluent kafka es una buena opcion
Orquestacion K8? o modelo Serverless
ML, tienes pensado usar modelos? pre entrenados? hagalo usted mismo? MLops ?
Tendras interaccion con Datalake? tienes uno? armaras uno?
Seguridad (como expondras los datos, cifrado, y anonimizacion de los datos reposo/vuelo
Resiliencia: multi region? hace poco se cayo virgina del norte en AWS y dejo la caga, azure unos meses atras.
Resumen, con cualquier wn que hables que represente a una nube te vendera lo bonito (nunca te hablan de los costos agregados y propios de cada producto) solo usalos para obtener rebajas y beneficios de contratos.
Exige soporte dedicado si no tienes manos (te cobran un poco mas caro pero los obligas a que sus propuestas esten orientadas a la optimizacion y no al gasto, cuando estan en la previa puedes sacar harto provecho de eso antes que les contrates los servicios cloud)
AWS,GCP,Azure,HUAWEI? wn en todas te cobraran, algunos les gusta por que es mas bonita o desde la zona de confort. teniendo una buena arquitectura puedes ahorrar varios morlacos todo depende de la expertiz que tenga quien te modele la solucion.
Para los papistas: Si hay costos diferenciados entre las nubes y algunos productos son con menor costo pero si el que implementa cree que sabe te hara gastar el triple, adicional a eso debes sumarles los costos operacionales que tiene cada uno y como lo orquestas. Por ej AWS para datalake te vende lake formation, tiene sus weas pero no es caro y hace su pega pero azure te muestra una documentacion a toda raja pero en databricks que si bien es bastante bueno es mucho mas caro que Lake formation y a eso sumale que el storage layer si lo tienes mal armado se convierte en un pacman de dolares.
Post automatically merged:
Resumen, primero arme bien su arquitectura de manera conceptual, listado de requerimientos, que casos de usos quieres satisfacer con tu solucion, tu ROI, Equipo o celula de desarrollo que tengas y mide sus capacidades para tener claridad de los SLA que podrias tener para todos los casos (desarrollo, correcciones, hot fix, nuevos features, asistencia tecnica, etc), lucas, puesta en marcha y tasa de crecimiento mensual/semestral/anual de tu producto ya que va de la mano con la infra.
Como dicen los compitas arriba, lo primero, el presupuesto, lo segundo es ver que es lo que necesitas realmente, algunos hablan de VM pero para que necesitas VM si puedes crear Docker y los puedes portar a cualquier cloud y probar. Cosas que debes tener en consideracion:
Arquitectura, necesitas todo en modo administrado? tienes el equipo con los skills? serverless?
Volumetria (cuanto quieres almacenar y como)
Storage (ciclo de vida de tus objetos) tienes que definir bien la estratega de datos
Ingesta, si te quieres despreocupar del streaming, confluent kafka es una buena opcion
Orquestacion K8? o modelo Serverless
ML, tienes pensado usar modelos? pre entrenados? hagalo usted mismo? MLops ?
Tendras interaccion con Datalake? tienes uno? armaras uno?
Seguridad (como expondras los datos, cifrado, y anonimizacion de los datos reposo/vuelo
Resiliencia: multi region? hace poco se cayo virgina del norte en AWS y dejo la caga, azure unos meses atras.
Resumen, con cualquier wn que hables que represente a una nube te vendera lo bonito (nunca te hablan de los costos agregados y propios de cada producto) solo usalos para obtener rebajas y beneficios de contratos.
Exige soporte dedicado si no tienes manos (te cobran un poco mas caro pero los obligas a que sus propuestas esten orientadas a la optimizacion y no al gasto, cuando estan en la previa puedes sacar harto provecho de eso antes que les contrates los servicios cloud)
AWS,GCP,Azure,HUAWEI? wn en todas te cobraran, algunos les gusta por que es mas bonita o desde la zona de confort. teniendo una buena arquitectura puedes ahorrar varios morlacos todo depende de la expertiz que tenga quien te modele la solucion.
Para los papistas: Si hay costos diferenciados entre las nubes y algunos productos son con menor costo pero si el que implementa cree que sabe te hara gastar el triple, adicional a eso debes sumarles los costos operacionales que tiene cada uno y como lo orquestas. Por ej AWS para datalake te vende lake formation, tiene sus weas pero no es caro y hace su pega pero azure te muestra una documentacion a toda raja pero en databricks que si bien es bastante bueno es mucho mas caro que Lake formation y a eso sumale que el storage layer si lo tienes mal armado se convierte en un pacman de dolares.
Post automatically merged:
Resumen, primero arme bien su arquitectura de manera conceptual, listado de requerimientos, que casos de usos quieres satisfacer con tu solucion, tu ROI, Equipo o celula de desarrollo que tengas y mide sus capacidades para tener claridad de los SLA que podrias tener para todos los casos (desarrollo, correcciones, hot fix, nuevos features, asistencia tecnica, etc), lucas, puesta en marcha y tasa de crecimiento mensual/semestral/anual de tu producto ya que va de la mano con la infra.
Como dicen los compitas arriba, lo primero, el presupuesto, lo segundo es ver que es lo que necesitas realmente, algunos hablan de VM pero para que necesitas VM si puedes crear Docker y los puedes portar a cualquier cloud y probar. Cosas que debes tener en consideracion:
Arquitectura, necesitas todo en modo administrado? tienes el equipo con los skills? serverless?
Volumetria (cuanto quieres almacenar y como)
Storage (ciclo de vida de tus objetos) tienes que definir bien la estratega de datos
Ingesta, si te quieres despreocupar del streaming, confluent kafka es una buena opcion
Orquestacion K8? o modelo Serverless
ML, tienes pensado usar modelos? pre entrenados? hagalo usted mismo? MLops ?
Tendras interaccion con Datalake? tienes uno? armaras uno?
Seguridad (como expondras los datos, cifrado, y anonimizacion de los datos reposo/vuelo
Resiliencia: multi region? hace poco se cayo virgina del norte en AWS y dejo la caga, azure unos meses atras.
Resumen, con cualquier wn que hables que represente a una nube te vendera lo bonito (nunca te hablan de los costos agregados y propios de cada producto) solo usalos para obtener rebajas y beneficios de contratos.
Exige soporte dedicado si no tienes manos (te cobran un poco mas caro pero los obligas a que sus propuestas esten orientadas a la optimizacion y no al gasto, cuando estan en la previa puedes sacar harto provecho de eso antes que les contrates los servicios cloud)
AWS,GCP,Azure,HUAWEI? wn en todas te cobraran, algunos les gusta por que es mas bonita o desde la zona de confort. teniendo una buena arquitectura puedes ahorrar varios morlacos todo depende de la expertiz que tenga quien te modele la solucion.
Para los papistas: Si hay costos diferenciados entre las nubes y algunos productos son con menor costo pero si el que implementa cree que sabe te hara gastar el triple, adicional a eso debes sumarles los costos operacionales que tiene cada uno y como lo orquestas. Por ej AWS para datalake te vende lake formation, tiene sus weas pero no es caro y hace su pega pero azure te muestra una documentacion a toda raja pero en databricks que si bien es bastante bueno es mucho mas caro que Lake formation y a eso sumale que el storage layer si lo tienes mal armado se convierte en un pacman de dolares.
Post automatically merged:
Resumen, primero arme bien su arquitectura de manera conceptual, listado de requerimientos, que casos de usos quieres satisfacer con tu solucion, tu ROI, Equipo o celula de desarrollo que tengas y mide sus capacidades para tener claridad de los SLA que podrias tener para todos los casos (desarrollo, correcciones, hot fix, nuevos features, asistencia tecnica, etc), lucas, puesta en marcha y tasa de crecimiento mensual/semestral/anual de tu producto ya que va de la mano con la infra.
Eso cilantritos.
Actualmente en mi pega tenemos un servidor para IOT, con herramientas basicas como MQTT, InfluxDB, Node.Red y Grafana.
Lo usamos como herramienta interna para analisis de datos industriales que usamos con 1 o 2 clientes.
El tema es que ahora ya tenemos pulido el desarrollo y escalaremos la solucion para ofrecerles el servicio a clientes en forma global, pero queremos migrar el servidor a la nube.
1. Diseño de tu solución, diagrama de arquitectura.
2. Buscar las opciones para cada componente de arquitectura en el cloud. Te recomiendo evitar IaaS. Trata de ir por plataformas. Por ejemplo si tienes un server con una BD, en lugar de llevártelo tal cual, trata de usar algo como CLOUDSQL o similar.
3. Dimensiona el volumen de tráfico y data. Las nubes cobran por uso y por tráfico. Luego usa las calculadoras para sacar un costo aproximado.
4. Estrategia de migración. Busca una alternativa qué evite en algún momento dejar tráfico entre nube y on premise.
5. Si te da las lucas implementa plataformas en HA interregional, sino, HA ínterzonal.
Si usas servicios de AD o Windows te recomendaría Azure, sino, GCP.
1. Diseño de tu solución, diagrama de arquitectura.
2. Buscar las opciones para cada componente de arquitectura en el cloud. Te recomiendo evitar IaaS. Trata de ir por plataformas. Por ejemplo si tienes un server con una BD, en lugar de llevártelo tal cual, trata de usar algo como CLOUDSQL o similar.
3. Dimensiona el volumen de tráfico y data. Las nubes cobran por uso y por tráfico. Luego usa las calculadoras para sacar un costo aproximado.
4. Estrategia de migración. Busca una alternativa qué evite en algún momento dejar tráfico entre nube y on premise.
5. Si te da las lucas implementa plataformas en HA interregional, sino, HA ínterzonal.
Si usas servicios de AD o Windows te recomendaría Azure, sino, GCP.
jejeje no es hablar mucho, es hablar desde la verdeda como Cliente y todos los pro y contras que hemos tenido con distintos proveedores. Piensa que nosotros al dia subimos de 1 a 2 tb de informacion. Tu resumen como marco general esta medianamente correcto pero te falta detalles importantes a la hora de estimar. Una BD? de que tipo? si es IOT y necesitas near realtime debes usar timestream pero el costo es elevado. Cloudsql? si es alto volumen trabaja con spark y tienes varias herramientas que te facilitan el desarrollo. Trafico? depende de los componentes que uses. Trafico on premise? has implementado un Private link o un direct connect ? y algo super importante que dejas afuera, el sizing y la tasa de crecimiento de tu solucion. Dependiendo de lo que uses puedes negociar precios.
Personalmente prefiero aterrizar bien la expectativa y no hacer resumenes de Consultor que despues empiezan a aparecer los "conejos" y tienes que poner la cara explicando por que les subio x lukas la cuenta.
Eso cilantritos.
Actualmente en mi pega tenemos un servidor para IOT, con herramientas basicas como MQTT, InfluxDB, Node.Red y Grafana.
Lo usamos como herramienta interna para analisis de datos industriales que usamos con 1 o 2 clientes.
El tema es que ahora ya tenemos pulido el desarrollo y escalaremos la solucion para ofrecerles el servicio a clientes en forma global, pero queremos migrar el servidor a la nube.
jejeje no es hablar mucho, es hablar desde la verdeda como Cliente y todos los pro y contras que hemos tenido con distintos proveedores. Piensa que nosotros al dia subimos de 1 a 2 tb de informacion. Tu resumen como marco general esta medianamente correcto pero te falta detalles importantes a la hora de estimar. Una BD? de que tipo? si es IOT y necesitas near realtime debes usar timestream pero el costo es elevado. Cloudsql? si es alto volumen trabaja con spark y tienes varias herramientas que te facilitan el desarrollo. Trafico? depende de los componentes que uses. Trafico on premise? has implementado un Private link o un direct connect ? y algo super importante que dejas afuera, el sizing y la tasa de crecimiento de tu solucion. Dependiendo de lo que uses puedes negociar precios.
Personalmente prefiero aterrizar bien la expectativa y no hacer resumenes de Consultor que despues empiezan a aparecer los "conejos" y tienes que poner la cara explicando por que les subio x lukas la cuenta.
Estamos tomando datos de funcionamiento de maquinas (OEE), y con cueva de cada equipo que instalamos sacamos 4 o 5 datos por MQTT.
Tenemos un pequeño server (en realidad es un PC con Linux Ubuntu) que corre 4 aplicaciones:
MQTT Mosquitto (para traer los datos)
Node-Red (para recibir los datos, procesarlos y generar algunos calculos)
InfluxDB (como base de datos)
Grafana (para hacer los dashboards).
Este server lo tenemos en una red dedicada de GTD que nos deja salir por el puerto 1883 (mqtt) y 3000 (grafana).
La wea funciona bien, pero estamos evaluando el costo de adquirir AWS, versus el costo de la red GTD y el costo de energia del servidor.
Como dicen los compitas arriba, lo primero, el presupuesto, lo segundo es ver que es lo que necesitas realmente, algunos hablan de VM pero para que necesitas VM si puedes crear Docker y los puedes portar a cualquier cloud y probar. Cosas que debes tener en consideracion:
Arquitectura, necesitas todo en modo administrado? tienes el equipo con los skills? serverless?
Volumetria (cuanto quieres almacenar y como)
Storage (ciclo de vida de tus objetos) tienes que definir bien la estratega de datos
Ingesta, si te quieres despreocupar del streaming, confluent kafka es una buena opcion
Orquestacion K8? o modelo Serverless
ML, tienes pensado usar modelos? pre entrenados? hagalo usted mismo? MLops ?
Tendras interaccion con Datalake? tienes uno? armaras uno?
Seguridad (como expondras los datos, cifrado, y anonimizacion de los datos reposo/vuelo
Resiliencia: multi region? hace poco se cayo virgina del norte en AWS y dejo la caga, azure unos meses atras.
Resumen, con cualquier wn que hables que represente a una nube te vendera lo bonito (nunca te hablan de los costos agregados y propios de cada producto) solo usalos para obtener rebajas y beneficios de contratos.
Exige soporte dedicado si no tienes manos (te cobran un poco mas caro pero los obligas a que sus propuestas esten orientadas a la optimizacion y no al gasto, cuando estan en la previa puedes sacar harto provecho de eso antes que les contrates los servicios cloud)
AWS,GCP,Azure,HUAWEI? wn en todas te cobraran, algunos les gusta por que es mas bonita o desde la zona de confort. teniendo una buena arquitectura puedes ahorrar varios morlacos todo depende de la expertiz que tenga quien te modele la solucion.
Para los papistas: Si hay costos diferenciados entre las nubes y algunos productos son con menor costo pero si el que implementa cree que sabe te hara gastar el triple, adicional a eso debes sumarles los costos operacionales que tiene cada uno y como lo orquestas. Por ej AWS para datalake te vende lake formation, tiene sus weas pero no es caro y hace su pega pero azure te muestra una documentacion a toda raja pero en databricks que si bien es bastante bueno es mucho mas caro que Lake formation y a eso sumale que el storage layer si lo tienes mal armado se convierte en un pacman de dolares.
Post automatically merged:
Resumen, primero arme bien su arquitectura de manera conceptual, listado de requerimientos, que casos de usos quieres satisfacer con tu solucion, tu ROI, Equipo o celula de desarrollo que tengas y mide sus capacidades para tener claridad de los SLA que podrias tener para todos los casos (desarrollo, correcciones, hot fix, nuevos features, asistencia tecnica, etc), lucas, puesta en marcha y tasa de crecimiento mensual/semestral/anual de tu producto ya que va de la mano con la infra.
Estamos tomando datos de funcionamiento de maquinas (OEE), y con cueva de cada equipo que instalamos sacamos 4 o 5 datos por MQTT.
Tenemos un pequeño server (en realidad es un PC con Linux Ubuntu) que corre 4 aplicaciones:
MQTT Mosquitto (para traer los datos)
Node-Red (para recibir los datos, procesarlos y generar algunos calculos)
InfluxDB (como base de datos)
Grafana (para hacer los dashboards).
Este server lo tenemos en una red dedicada de GTD que nos deja salir por el puerto 1883 (mqtt) y 3000 (grafana).
La wea funciona bien, pero estamos evaluando el costo de adquirir AWS, versus el costo de la red GTD y el costo de energia del servidor.
Eso cilantritos.
Actualmente en mi pega tenemos un servidor para IOT, con herramientas basicas como MQTT, InfluxDB, Node.Red y Grafana.
Lo usamos como herramienta interna para analisis de datos industriales que usamos con 1 o 2 clientes.
El tema es que ahora ya tenemos pulido el desarrollo y escalaremos la solucion para ofrecerles el servicio a clientes en forma global, pero queremos migrar el servidor a la nube.
De experiencia propia. Los plcs no se mandan a la nube papu, no puedes trabajar en tiempo real con latencias variables (tuve un cagazo maximo con unas balanzas de materia prima).
Necesitas si o si un servidor de paso para las operaciones prioritarias y mandar a la nube solo la reporteria.
puta que duele el bolsillo con esos klos, azure es bastante decente pero enserio que todo depende de lo que requieras en el día a día y obviamente del presupuesto que dispongas 
que el resumen sea más largo que el post completo
