Kuby-core: ¿Qué tipo de aplicaciones deberíamos (no) implementar con Kuby?

Hola @hovancik. Tienes toda la razón, no hay mucho en la documentación sobre los distintos proveedores de la nube y cuánto cuestan. Estaba pensando en agregar una matriz de precios a los documentos, pero la solución de implementación realmente no tiene nada que ver con el proveedor de la nube. Imagina, por ejemplo, hacerle la misma pregunta a Capistrano :)

Kuby está diseñado para implementar su aplicación en cualquier clúster de Kubernetes, independientemente del proveedor de la nube y de su costo. Usted, como desarrollador, debe tener la libertad de elegir el proveedor de la nube que mejor se adapte a sus necesidades. Por ejemplo, no elegiría EKS o Azure para un pasatiempo o proyecto personal; es demasiado costoso. Para EKS, los $ 72 / mes que mencionó son literalmente solo para el plano de control de Kubernetes y no incluyen el costo de ningún recurso informático, almacenamiento en bloque, etc. En su lugar, buscaría DigitalOcean o Linode, que son mucho más costosos. -efectivo (alrededor de $ 20 / mes por una instancia de 4 gb de RAM, 2 CPU) y le brinda el plano de control de forma gratuita. Si forma parte de una empresa que desea utilizar algunos de los otros numerosos servicios de AWS o Azure, entonces quizás EKS sea la solución adecuada para usted. El punto es que tú eliges. A Kuby no le importa: está diseñado para funcionar en todas partes.

Dicho esto, ¿sería útil ver una matriz de precios en la documentación? Dudo en agregar uno porque 1) las razones enumeradas anteriormente, 2) los precios cambian con frecuencia y 3) no quiero entrar en el negocio de recomendar proveedores de nube o ser percibido como favoreciendo a uno sobre el otro.

¿Pensamientos?

Hola @camertron , sí, la matriz de precios es una mala idea.

Como dice el título, lo que intento preguntar es: ¿Qué tipo de aplicaciones deberíamos (no) implementar con Kuby? En cierto sentido: describa la herramienta en el término de trabajo :)

Empecé con hobby vs professional ( =dinero), porque es fácil, pero me gustaría saber más sobre el tipo de aplicaciones que está buscando. ¿Es esto excesivo para una aplicación de rieles renderizada por servidor simple con db? ¿O ese es el candidato perfecto? ¿O cuanto más complicada sea la aplicación, mejor será esta herramienta para los desarrolladores?

¿Quizás estoy malinterpretando y esto está destinado a todo tipo de aplicaciones? Ya sabes, el tipo de páginas donde dicen use this tool if y don't use this tool if es lo que busco cuando las reviso :)

Ah vale, ya veo lo que quieres decir. Diría que Kuby está diseñado para todo tipo de aplicaciones, pero ciertamente hay algunos tipos que se beneficiarán más que otros. Probablemente sea mejor que use un Heroku dyno gratuito para una aplicación súper pequeña que no ve mucho tráfico y que solo administra unos pocos cientos (o menos) de filas de la base de datos. La cuestión es que no es que Kuby sea una mala opción para este tipo de aplicaciones, es solo que es probable que gastes menos dinero y menos capacidad mental para configurar Heroku. Es bastante difícil vencerlos en simplicidad. Sin embargo, Heroku comienza a ser costoso cuando necesita más recursos, y descubrí que, en términos generales, un clúster de Kubernetes administrado con un solo nodo implementado con Kuby es más rentable que la configuración equivalente de Heroku. Sí, Kuby requiere más capacidad intelectual para configurar (una vez más, es bastante difícil de superar git push heroku master ), pero la flexibilidad que obtienes como resultado vale la pena en mi humilde opinión.

Kuby también podría no ser la opción correcta para aplicaciones muy grandes y altamente personalizadas que se han desviado significativamente de las convenciones de Rails. Estoy seguro de que podría hacer que Kuby funcione para tales aplicaciones, pero probablemente significaría personalizar Kuby en gran medida. Para hacerlo, probablemente deba tener una comprensión más profunda de cómo funcionan Docker, Kubernetes y Kuby. Supongo que se reduce a qué tan dispuesto está a invertir tiempo en aprender las tecnologías.

Tal vez la mejor manera de decirlo es que Kuby fue diseñado para atender a la misma audiencia que Rails, y debe considerarse que reside al mismo nivel que el registro activo, el almacenamiento activo, etc. Se podría decir razonablemente que un ORM es excesivo para una aplicación muy pequeña, y también podría decir razonablemente que se interpone en su camino en una aplicación grande y personalizada. El registro activo está diseñado para abstraer las complejidades de la comunicación de la base de datos, y Kuby está diseñado para hacer lo mismo con la implementación. Ambos vienen, como le gusta decir a DHH, con pilas incluidas.

¡Gracias! Alguna forma de esto probablemente debería estar en la web en algún lugar :)

De acuerdo, gracias por mencionar esto @hovancik :)