Las ofertas virtualizadas funcionan significativamente peor (consulte mis experimentos de 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance y cuestan más. La diferencia es que puede "escalar según demanda", lo que no me pareció necesario, al menos en mi caso. Y si necesito escalar, aún puedo hacerlo, es solo que obtener nuevos servidores lleva horas en lugar de segundos. Bueno, no necesito escalar en segundos.
En mi caso, mi factura mensual completa por el entorno de producción completo y un entorno de prueba/en espera duplicado es constante, simple, predecible, muy baja en comparación con lo que tendría que pagar a AWS, y todavía tengo mucho margen de rendimiento para
Una cosa que vale la pena señalar es que trato los servidores físicos como virtuales: todo se administra a través de ansible y puedo recrear todo desde cero. De hecho, uso otro entorno "devcloud"en Digital Ocean, y ese se activa con terraform, antes de pasar a ansible que hace el resto de la configuración.
Sospecho que VendorOps y herramientas complejas como kubernetes se ven favorecidas por los comerciantes de complejidad que surgieron en la última década. Se ve muy bien en el currículum y les da a los líderes tecnológicos una falsa sensación de logro.
Mientras tanto, Stackoverflow, que podría decirse que es más importante que la mayoría de las nuevas empresas, avanza en máquinas dedicadas.
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Parece que la tendencia en este espacio es saltar directamente a la capa más alta de abstracción. Saltarse los fundamentos y apuntar a las herramientas, bibliotecas y productos de $buzzword
Ves destellos de esto en diferentes formas. Uno son los hilos de las redes sociales que preguntan cosas como ¿Cuánto de X necesito saber para aprender Y? Donde X es una tecnología o campo fundamental, posiblemente muy estable, e Y es una herramienta del día o directamente un producto o servicio.
CORBA pertenece allí. Y tal vez incluso las cosas de la web semántica. Definitivamente XML!
XML es excelente: si no lo cree, es posible que le interesen las molestias de analizar JSON: httpseriot.ch/projects/parsing_json.html
Y no me hagas empezar con YAML...
El costo incremental de estar en una nube vale totalmente la pena para mí tener bases de datos administradas, instantáneas automáticas, balanceadores de carga alojados, almacenamiento en bloque plug and play, etc.
Quiero preocuparme por si nuestro producto es bueno, no por fallas de hardware a mitad de la noche, por poner en marcha un nuevo servidor y que no funcione correctamente porque no había ningún incentivo para usar la administración de configuración con una sola caja, con una sola tarea fuera de control. causa OOM o disco lleno y rompe todo en lugar de solo esa tarea VM, miedo a reiniciar una máquina que ha estado activa 1000 días, etc.
Para mí, el atractivo de la nube no es una moda pasajera de escalabilidad FAANG cuando no es necesaria, sino parches automáticos del sistema operativo, equilibrio de carga automático, servicios NAT, registros centralizados y analizables, servicios de bases de datos que no tengo que administrar, fuera del actualizaciones continuas de servicios, gestión de claves criptográficas y secretos y, por supuesto, almacenamiento de objetos. (Estas son todas las cosas que usamos en nuestra startup)
Me arriesgaría y diría que los servidores dedicados pueden ser muy viables y rentables cuando alcancemos cierta escala, y no al revés. De momento, los gastos en la nube valen la pena para mi startup.
Si está configurando su entorno como código, en última instancia, no debería importar si su objetivo es un servidor dedicado, una máquina virtual o alguna configuración específica de la nube configurada a través de una API.
Realmente no importa cuál, el punto es que tienes uno que puede construirte una nueva caja o devolver una caja que se porta mal a un buen estado simplemente ejecutando un comando.
Claro, la pila real de Go(o) que lo impulsa se puede mejorar (y de hecho está mejorando)
Dicho esto, la dura verdad es que su enfoque es el correcto: casi todas las empresas (¡startups!) construyen demasiado en lugar de centrarse en proporcionar valor, identificar el nicho real, etc. (Sí, también está el lado de la demanda, ya que el Las startups infladas con dinero de capital de riesgo quieren depender de terceros que puedan asumir la carga, escalar con ellas, los SLA y todo eso deben publicitarse).
¡Kubernetes es fantástico! Cada vez que veo que una empresa potencialmente competidora comienza a utilizar Kubernetes, me siento aliviado de inmediato, porque sé que ya no tengo que preocuparme por ellos. Están a punto de desaparecer en un montón de problemas técnicos sin solución, tratando de solucionar problemas que no se pueden rastrear en una pila tecnológica de increíble complejidad y solucionando las limitaciones impuestas por un sistema diseñado para empresas con un tráfico dos o tres de magnitud mayor. Además, sus COGS serán mucho más altos que los míos, lo que significa que tendrán que poner un precio más alto a su producto, a menos que simplemente estén quemando dinero de capital de riesgo (en cuyo caso son algo pasajero).
Cosas buenas por todas partes
Ansible es imperativo, puede funcionar hacia un estado estático y eso es todo. Si tiene un problema, cancela su conexión SSH, llora toneladas de errores de Python y se da por vencido para siempre. Incluso con su inventario está lejos de ser declarativo.
k8s es una serie de bucles de control que intentan avanzar hacia su estado declarado. La falla no es un problema, se volverá a intentar. Verificará constantemente su propio estado, tiene una buena API para informarlo y, gracias a muchos conceptos cosificados, es más difícil tener choques extraños entre los componentes implementados. (Mientras que la integración de múltiples playbooks con Ansible no es trivial).
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
E incluso si k8s presenta demasiados legados, hay próximas manifestaciones más delgadas de las ideas centrales. (Por ejemplo, httpsgithub.com/aurae-runtime/aurae)
¿Y ahora está sugiriendo que la gente use una implementación no estándar más simple?
Entonces, por supuesto, puede implementar una solución de complejidad mínima o puede usar algo "listo para usar"k8s es complejo y parte de él definitivamente no es necesario para su situación, pero también es bastante general, flexible, bien soportado, etc.
>¿Estás sugiriendo que la gente use una implementación no estándar más simple?
Lo que sugerí es que si k8s el proyecto/software se vuelve demasiado grande para fallar, entonces la gente puede cambiar a una alternativa. Afortunadamente, los conceptos y la API de k8s son de código abierto, por lo que pueden implementarse en otros proyectos, y di un ejemplo para ilustrar que elegir k8s no es un bloqueo de proveedor similar al de Oracle.
Siempre escucho sobre todas las cosas geniales que obtienes prácticamente gratis de los proveedores de la nube. ¿Es eso realmente tan fácil de configurar y usar? Cada vez que intentaba configurar mi pila LAMP en un servicio en la nube, era un proceso tan confuso y aterrador que terminaba por rendirme. Me pregunto si necesito esforzarme un poco más y llegaré a Cloud Heaven.
Ser capaz de decir "Quiero un MySQL agrupado aquí con este tipo de especificaciones"es mucho mejor (en cuanto al tiempo) que hacerlo por su cuenta. Las actualizaciones también están bien integradas en el sistema, por lo que solo digo "aplicar la última actualización"en lugar de asegurarme manualmente de que las conmutaciones por error/reinicios ocurran en el orden correcto.
Por lo tanto, paga para simplificar las cosas, pero la ganancia de esa simplificación solo se activa con proyectos más grandes. Si tiene algo en un solo servidor que puede reiniciar mientras sus usuarios obtienen una página de error, puede que no valga la pena
La nube no es fácil, pero tratar de obtener enfriamiento y eficiencia energética de una pequeña sala de servidores en cualquier lugar cerca de los niveles de eficiencia que la mayoría de los grandes centros de datos publican es casi imposible, al igual que la conectividad a Internet de múltiples proveedores.
Con la nube, todo eso desaparece, ya que es administrado por cualquier operador de centro de datos en el que se ejecuta la nube, pero lo que la gente olvida es que eso también es cierto para los servicios de colocación a la antigua, que a menudo ofrecen una mejor relación costo/valor que la nube.
Y si bien definitivamente es más difícil administrar cosas como AWS o Azure porque revela muchas abstracciones que los pequeños proveedores de vpc de scall te ocultan o que realmente no obtienes con un solo servidor doméstico, no es difícil en la escala de tener que ejecutar un par. de racks de servidores vmware con almacenamiento basado en SANCon las cosas de la nube tienes más configuración que hacer porque se trata de configurar servidores virtuales, etc.En lugar de llevar la PC en un box a tu habitación debes "configurarlo"para que esté disponibleLas bases de datos DO tienen copias de seguridad que puedes configurar a tu gusto, guárdalas en DO Spaces (como S3).La gestión de usuarios de bases de datos es sencilla.También hay servidores de caché para RedisPuedes agregar un balanceador de carga y conectarlo a tus diversos servidores webCreo que me tomó Aproximadamente 30 minutos para configurar 2 servidores web, un servidor de base de datos, un servidor de caché, un equilibrador de carga, un servidor de almacenamiento y conectarlos todos según sea necesario mediante algunos formularios simples.Realmente no puedo superar esoSi tienes más información u opiniones, por favor comparteMuchos artículos en Internet sobre Para fortalecer un servidor Linux, los que he probado toman un poco más de 30 minutos para seguir los pasos, mucho más si realmente intento aprender y comprender qué hace cada cosa, por qué es importante, cuál es la vulnerabilidad subyacente. es, y cómo podría necesitar personalizar algunas configuraciones para mi caso de uso particularEstoy seguro de que puede encontrar scripts de configuración de ejemplo en línea (configurar actualizaciones automáticas, firewall, aplicaciones, etc. debería ser un asunto de ejecutar 'curl $URL'y luego 'chmod +x $FILE'y 'bash $FILE'.No necesitaba administración de configuración (uso el servicio de respaldo de mi proveedor, lo cual es importante, supongo)Algo como esto: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(visto en httpswww.reddit.com/r/selfhosted /comments/f18xi2/ubuntu_d )Obviamente se puede decir lo mismo de las máquinas virtuales de larga ejecución, y esto se puede resolver con un equipo disciplinado, pero creo que generalmente es más probable en un entorno con una sola máquina dedicada de larga duración. máquinaHetzner tiene todo esto excepto bases de datos administradashttpswww.hetzner.com/managed-serverLos paquetes de alojamiento web también incluyen 1. .DB ilimitadas (MySQL y PostgreSQL)httpswww.hetzner.com/webhosting/¿tiene copia de seguridad automática y conmutación por error?>Con la copia de seguridad diaria reservada o la copia de seguridad incluida en el tipo de servidor, se realiza una copia de seguridad de todos los datos diariamente y se conserva durante un máximo de 14 días.La recuperación de copias de seguridad (Restaurar) es posible a través de la interfaz de administración de konsoleHPero tengo la impresión de que las bases de datos en los servidores administrados están diseñadas para que las utilicen las aplicaciones que se ejecutan en ese servidor. por lo que realmente no existe un concepto de conmutación por errorhttpswww.hetzner.com/legal/managed-server/Una sola unidad en un solo servidor que falla nunca debería causar una producción interrupciónMuchos problemas de configuración pueden atribuirse a implementaciones autónomas.¿Ese archivo de fuente o JRE realmente necesita estar instalado en todo el servidor o puede incluirlo en su implementación?Nuestras implementaciones utilizan objetivos EC2 y locales.El script de implementación no es diferente, solo la IP para el host esAhora, diré si puedo usar S3 para algo que lo haré al 100%.No existe una alternativa local con el mismo conjunto de característicasEl objetivo de DevOps es "Ganado, no mascotas". Pon una bala en tu servidor una vez a la semana para encontrar tus puntos de fallaMe encantaría que ingresaras a nuestro Discord/Slack y mencionaras algunos de los problemas que estabas viendo para que podamos al menos mejorar la experiencia para otros que usan Dokku.Siéntete libre de contactarme (mi nick es `savant`)Permíteme comenzar y decir que soy un desarrollador de aplicaciones con solo un conocimiento práctico de Docker.No soy muy hábil en infraestructura y la aplicación con la que tuve problemas tiene parámetros de implementación peculiares: es una aplicación Python que en el momento de la compilación analiza varios gigas de rastreos de HTML estáticos para completar una base de datos de Postgres que es estática después de ser compilada.Luego, una aplicación web Flask sirve para esa base de datos.El análisis de HTML evoluciona rápidamente y, por lo tanto, los datos de la base de datos completa deben agruparse como parte de las imágenes de la aplicación.IIRC, tuve problemas para estructurar los Dockerfiles cuando la base de datos no estaba No es persistente, sino simplemente otra parte transitoria de la aplicación, pero parecía superable.El problema más grande parecía ser cómo evitar extraer gigas de datos rara vez modificados de S3 para cada compilación cuando lo ideal sería almacenarlos en caché, especialmente de una manera que se comportara de manera sensata en DigitalOcean y mi entorno local.Supongo que el almacenamiento en caché de la capa de imágenes de Docker correcto solucionaría el problema, pero rápidamente llegué al final de mi conocimiento y pacienciaEl DX de Dokku parece excelente para las personas que hacen cosas normales .:)0. httpscoolify.io/Además, ¿quién no quiere jugar con el juguete más nuevo y genial con el dinero de otra persona?Definitivamente existe un argumento para sacar (algunas) cosas de la nube más adelante en el viaje, cuando la flexibilidad (o lidiar con el flujo/pivote) deja de ser un factor principal y la escala/costo comienza a dominarClaro, puedes hacer que algo funcione en Hetzner, pero prepárate para responder muchas más preguntasEstoy de acuerdo en tu último punto de empresa al pedir esto, lo cual nuevamente es simplemente triste que estos negocios ""Requisitos"dictan cómo diseñar y alojar su software cuando otra forma podría ser mucho mejorLa recuperación ante desastres es un problema muy real.Por eso lo pruebo regularmente.En un escenario de tierra arrasada, puedo estar en funcionamiento en un sistema secundario (de prueba) o en un sistema de nube terraformado en menos de una hora.Para mi negocio, eso es suficiente
Pasamos por un auge de crecimiento y, como todos los anteriores, significó que había mucha gente sin experiencia a la que se le entregaba mucho dinero y expectativas urgentes. Es una receta para el culto al cargo y el marketing explotador.
Pero el crecimiento se está desacelerando y el dinero se está volviendo más caro, así que reduciremos la velocidad y comenzaremos a volver a aprender las viejas lecciones con nuevas y emocionantes variaciones. (Como aquí: gestión del escalado básico y con contenedores y orquestación)
Y todo el ciclo se repetirá en el próximo boom. Esa es nuestra industria por ahora
Un servidor dedicado sólido es el 99% de las veces mucho más útil que un VPS dañado en hardware compartido, pero obviamente tiene un costo mayor si no necesita todos los recursos que brindan.
Sí, pero los anhelos de "hacer lo que todos los chicos geniales están haciendo ahora"son al menos tan fuertes en aquellos a quienes normalmente se les llamaría "gerentes"que "empleados".
Resultado A) Un enorme gasto en microservicios/nube sale mal, bueno, al menos estabas siguiendo las mejores prácticas, estas cosas suceden, ¿qué puedes hacer?
Resultado B) Elegiste un servidor Hetzner y algo salió mal, bueno, deberías haber elegido microservicios, disfruta buscando un nuevo trabajo.
Animando así a los directivos a elegir microservicios/nube. Puede que no sea la decisión correcta para la empresa, pero es la decisión correcta para el gerente, y es el gerente el que toma la decisión.
(Al igual que ser un consultor que desea una extensión y escribir un software que funcione, como lo descubrí por las malas).
Hay una desconexión entre los fundadores y todos los demás
Los fundadores creen que lo harán >10 veces cada año
La realidad es que tienen un 90% de probabilidades de fracasar.
El 90% de las veces, estás bien si fallas en lo que sea
Alrededor del 10% de las veces que tiene éxito, todavía está bien sin la nube, al menos durante varios años de éxito, tiempo suficiente para cambiar si alguna vez es necesario.
Solo tengo una configuración ansible y puede funcionar tanto para servidores virtualizados como físicos. Ninguna diferencia. La única diferencia es que los servidores virtualizados deben configurarse primero con terraform, y los físicos deben solicitarse primero y sus IP ingresarse en un archivo de configuración (inventario).
Por supuesto, también tengo cuidado de no volverme dependiente de muchos otros servicios en la nube. Por ejemplo, uso VpnCloud (httpsgithub.com/dswd/vpncloud) para la comunicación entre los servidores. Como beneficio adicional, esto también me brinda la flexibilidad de cambiar a cualquier proveedor de infraestructura en cualquier momento.
Mi punto principal fue que, si bien las ofertas virtualizadas tienen sus usos, existe una brecha (enorme) entre un VPS de pasatiempo de $ 10 / mes y una empresa con un negocio B2C de crecimiento explosivo. La mayoría de los negocios nuevos en realidad caen en esa brecha: no espera un crecimiento exponencial de palo de hockey en un SaaS B2B rentable. Ahí es donde debe cuestionar la opción predeterminada habitual de "usar AWS". Me importan mis COGS y mis márgenes, por lo que miro esta elección con mucho cuidado.
Usted no es una empresa de software, fundamentalmente fabrica y vende Sprockets
Las opiniones aquí serían contratar a un gran personal de ingeniería / TI para "comprar y mantener servidores"(PaaS es malo) y luego probablemente "escribir un código usted mismo"(SaaS es malo) o lo que sea actualmente popular aquí (último hilo aquí fue "Empujando PHP sobre SFTP sin Git, y estás si necesitas más"jajaja)
Pero creo que las empresas deberían hacer una cosa bien y evitar tratar de competir (haciéndolo manualmente) por cosas que están fuera de su competencia principal. En este caso, definitivamente pensaría que Sprocket Masters no debería intentar administrar su propio hardware y debería confiar en un proveedor para manejar la escala, la seguridad, el tiempo de actividad, el cumplimiento y todos los pequeños detalles. También creo que su software debería ser estándar con la menor cantidad interna posible. No son una tienda de software y deberían escribir la menor cantidad de código posible.
Siendo realistas, Widget Masters podría ejecutar estos sitios con un personal bastante pequeño a menos que decidieran hacerlo todo manualmente, en cuyo caso probablemente necesitarían mucho más personal.
Sin embargo, lo que también veo y de lo que creo que hablaba el cartel anterior son negocios donde la tecnología está en el centro del negocio, y allí a menudo tiene menos sentido, y en lugar de ahorrar tiempo, parece costar tiempo. Hay una razón por la que hay expertos en AWS: no es trivial. Los servidores "reales"tampoco son triviales, pero tampoco necesariamente más difíciles que los servicios en la nube
Pero esas agencias tampoco quieren tener personal para mantener el hardware físico.
Pero Sprocket Masters todavía tiene que contratar a un consultor de nube costoso simplemente para responder a las emergencias.
Si va a tener a alguien en el personal para que se ocupe de los problemas de la nube, también puede alquilar un servidor.
Personalmente, administré servidores dedicados para nuestro negocio en los primeros días, pero a medida que nos expandimos y escalamos, se volvió mucho más fácil ir con los proveedores de la nube para proporcionar varios servicios rápidamente, aunque los costos aumentaron. Sin mencionar que es mucho más fácil decirle a un posible cliente que usa "nube como AWS"que "Oh, alquilamos estas máquinas en un centro de datos administrado por alguna empresa"(que en realidad puede ser mejor, pero la mayoría de los clientes no entenderán eso) . Auditoría, Cumplimiento y otros
Para muchos, incluso mucho menos que eso. Ejecuto un pequeño proyecto paralelo[1] que se volvió viral varias veces (30 000 visitas en aproximadamente 24 horas) y se ejecuta en un servidor web de CPU de un solo núcleo y un Postgres administrado también en un solo núcleo de CPU. Ni siquiera ha estado cerca de la plena utilización
1: httpsaihelperbot.com/¿Puedo cambiar algunas de ellas a funciones lambda?¿O cambiar a ECS?¿O cambiar a algún otro servicio en la nube del momento?Quizás.Pero la cantidad de tiempo que dediqué a escribir este comentario ya representa aproximadamente seis meses de ahorro para tal cambio.Si es más difícil que "presionar un botón, recibir un servicio traducido 100% confiable", es difícil de justificarParte de esto también se debe a que la nube proporciona otros servicios que permiten este tipo de cosas.No necesito ejecutar un clúster Kafka para mensajería básica, todos vienen con un bus de mensajes.Yo uso eso.Utilizo las opciones de base de datos alojada.Utilizo S3 o equivalente, etc.Creo que lo que queda casi no vale la pena de intentar meterme en algún otro paradigma cuando pago dólares de un solo dígito al mes para simplemente ejecútelo en una instancia EC2Es absolutamente cierto que no todos ni todos los proyectos pueden hacer esto.No estoy apegado a esto como objetivo final.Cuando no funciona, inmediatamente tomo las medidas de escala adecuadas.No estoy sugiriendo que vuelvas a diseñar nada basado en esto.Solo digo que no es una opción que deba ser despreciada.Tiene mucha flexibilidad y la facturación es bastante consistente (o, para decirlo de otra manera, el hecho de que si de repente tengo 50 veces más tráfico, mi sistema comienza a ahogarse y a fallar notablemente en lugar de simplemente cobrarme cientos de dólares más es una característica para mí más que un error), y generalmente no se esfuerza por contorsionarse en algún paradigma que sea conveniente para algún servicio en la nube pero que puede no serlo para usted¿Alguna vez has tenido que gestionar uno de esos entornos?La cuestión es que, si desea obtener una escalabilidad básica para más de una persona y devops adecuados, entonces debe sobreaprovisionar por un factor significativo (posiblemente anulando sus ahorros)Inevitablemente terminará con una solución personalizada, lo que significa que a los nuevos miembros les resultará más difícil dominar el sistema y las personas importantes que dejen la empresa traerán consigo su conocimiento íntimo de su infraestructura.Volviste a usar mascotas en lugar de ganado.Algunos servidores son especiales, después de un tiempo la automatización significa "muchos scripts de shell adhesivos aquí y allá"y una actualización del sistema operativo significa que la mitad de la infraestructura está KO por un tiempo o que no se realizan actualizaciones del sistema operativo en absolutoY en el caso afortunado de que necesites ampliar tu escala. Es posible que encuentres sorpresas desagradablesY nunca me hagas hablar del lado de las redes.A menos que alquile todo el bastidor y coloque su propio hardware de red, obtendrá lo que obtendrá.Lo cual podría ser muy pobre en funcionalidades o rendimiento. Asumiendo que no estás haciendo nada sofisticadoSi quieres un 100.0000% de tiempo de actividad, seguro.Pero normalmente no lo haces.Las empresas que desean ese tipo de tiempo de actividad normalmente tienen equipos dedicados a ello de todos modosY el escalado también funciona bien en bare-metal si escala verticalmente, ¿tiene alguna idea de la cantidad? ¿Qué cantidad de potencia y rendimiento puede obtener de un único servidor?Es preocupante seguir escuchando sobre "escalar"cuando el hablante quiere decir "escalar horizontal"Si tus requisitos son "escalar", entonces el escalamiento vertical te llevará lejosSi sus requisitos son "escalado horizontal bajo demanda", entonces, seguro, los proveedores de la nube lo ayudarán.Pero pocos lugares necesitan ese tipo de escalamientoNo estoy diciendo que el 100% de tiempo de actividad en metal desnudo sea barato, estoy diciendo que el 100% de tiempo de actividad frecuentemente no es necesarioPorque la industria está llena de gente que está persiguiendo tendencias y palabras clave y a la que lo más importante es añadir esas palabras clave a los CVIME apuntando la escalabilidad es extremadamente incorrecta para la mayoría de los servicios/aplicaciones/lo que sea.Y normalmente pagas tantos gastos generales por las soluciones "escalables", que luego necesitas escalar para compensarlosRealmente lo dudo.El único tema que se ve en casi todos los defensores de AWS es una gran cantidad de engaños sobre las garantías que AWS realmente le brinda.Sí, claro.Nadie es despedido por comprarle a IBMBueno, si las grandes empresas tuvieran alguna competencia en la toma de decisiones, serían imbatibles y sería inútil trabajar en cualquier otra cosa en todo.Entonces, sí, eso es un bien públicoFuente: casi treinta años de operacionesHasta ahora no me he dado cuenta de que si gasto más para la empresa a la que también me pagan másobtener la confiabilidad equivalente con hierros es mucho más costoso que alquilar "dos servidores dedicados"- ahora podría estar bien con un servidor y una solución de respaldo , y eso es justo. pero un sysad para crear todo eso, incluso con un contrato corto para la configuración inicial y sin mantenimiento, irá mucho más allá de la diferencia de precio de la nube, especialmente si hay una base de datos en la mezcla y a usted le importan esos datosHoy en día, la nube es similar: el tiempo de comercialización es más rápido ya que hay menos piezas móviles.Cuando la economía se hunde y el crecimiento se desacelera, los contadores entran y hacen lo suyoSucede cada vezEsto solo enriquece a AWS en el ámbito de empresas y equipos de nubeEs trivial aprovisionar y desaprovisionar una instancia EC2 automáticamente, en cuestión de segundos, si su implementación necesita ampliarse o reducirse.Eso es lo que lo hace fundamentalmente diferente de un servidor básico
Ahora bien, no niego que aún podría ser más rentable en comparación con AWS aprovisionar algunos servidores dedicados más de los que necesitará, pero cuando tiene cargas de trabajo realmente impredecibles no es fácil mantenerse al día.
Si está activando y apagando máquinas virtuales para satisfacer la curva de demanda, algo anda muy mal con su arquitectura.
¿Se te ocurrió alguna vez cómo es que stackoverflow utiliza ~8 servidores dedicados para servir a todo el mundo y no necesita encender y apagar las máquinas virtuales para satisfacer la demanda global de los clientes?
--
Al planificar la infraestructura informática, es importante volver a lo básico y no caer en la propaganda de los proveedores de la nube.
Tú mismo lo dijiste. No es necesario que todas las aplicaciones sirvan a todo el mundo, por lo que la demanda será menor cuando la gente se vaya a dormir.
Incluso con las aplicaciones globales existen regulaciones que requieren que usted aloje aplicaciones y datos en regiones específicas. Imagine una aplicación utilizada por clientes en Europa, Australia y Estados Unidos. Deben ser atendidos desde centros de datos regionales, y un clúster estará mayoritariamente inactivo mientras el otro esté funcionando (debido a las zonas horarias). Con servidores dedicados desperdiciarías entre el 60 y el 70 % de tus recursos, mientras que usando algo como EC2/Fargate puedes reducir la escala a casi 0 cuando tu región está inactiva.
Hay un método para esta locura, aquí se llama "desarrollo impulsado por la seguridad laboral"Porque es una amenaza para sus trabajos.
Hay todo un grupo de personas que tienen las habilidades técnicas para ser anfitriones propios o organizar pequeñas instancias para su familia/amigos/asociación/club de senderismo. Este pequeño margen te permite gastar un poco más porque quieres hacerlo bien, pero no puedes justificar pagar tanto y dedicar tiempo a un mantenimiento intenso. Un pequeño VPS, con un Nextcloud compartido o un pequeño sitio web, es todo lo que se necesita en muchos casos
Para esto incluso uso una pequeña Raspberry Pi 400 en mi dormitorio.
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
He alojado mis propias cosas durante casi una década. Nadie ha intentado realizar DDoS en mi configuración, porque ¿por qué lo harían? ¿Qué beneficio podrían obtener de ello? Sería prácticamente la única persona afectada y una vez que se detuvieran no tardaría mucho en recuperarme.
Hay poco o ningún incentivo para realizar DDoS en una caja personal, y mucho menos mediante un rando de Internet.
Estás sobreestimando drásticamente las habilidades de un adolescente.
Simplemente hacer ping a la IP una y otra vez no servirá de mucho. Tal vez un ataque DoS dependiendo de lo que tenga la red objetivo en términos de IPS, pero incluso entonces es más probable que infecten sus computadoras con virus antes de tener la oportunidad de atacarte.
Personalmente he estado en el lado receptor de uno de esos por un tramposo en GTA 5. Definitivamente sucede y no es divertido.
Editar: Parece que esto podría ser automático. Esto es algo interesante que debería investigar un poco. Probablemente sea solo una complejidad adicional para mi pequeño servidor, pero tengo algunos usos en mente.
Técnicamente, mi laboratorio doméstico también está en una IP pública estática; esto fue más un ejercicio de "¿podría hacer esto"que de "realmente necesario", pero aún así es genial y estoy muy feliz?
El único problema fue que tuve que configurar Wireguard para mantener activo el túnel; de lo contrario, a veces el VPS recibía tráfico entrante y si mi laboratorio no se había comunicado en un tiempo (¿por qué lo haría?), el túnel estaría caído. y la conexión proxy lo haría. Afortunadamente, esa es una funcionalidad incorporada.
Entonces, parece que agregar feeds RSS/Atom en un sitio de páginas jekyll o GitHub es bastante sencillo.
1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..
3. httpspages.github.com/versions/
atom 2c/4t, 4gb de ram, unidad de 1tb, 100mbit
Algunos años de funcionamiento en este momento
Si es ininterrumpido: es posible que sea necesario realizar alguna actualización.
Las actualizaciones de seguridad del kernel son una cosa
Encontré que Atoms es insoportablemente lento, incluso con Linux. Por supuesto, es suficiente para servir sitios web y todo eso, pero es desconcertante cuánta energía usan y no funcionan.
Exactamente. Estas instancias VPS de menos de $10 son excelentes para proyectos pequeños en los que no desea celebrar contratos largos ni lidiar con la administración de sus propios servidores.
Si está ejecutando un negocio real donde los márgenes son muy reducidos y tiene todo el tiempo libre del mundo para manejar los problemas del servidor si (cuando) surjan, podría ser interesante explorar esos servidores dedicados de ~ $ 50
Pero si dirige un negocio real, incluso una factura de AWS de $10 000 al mes es más barata que contratar a otro desarrollador capacitado para que le ayude a administrar sus servidores dedicados.
Esto es lo que generalmente se pasa por alto en las discusiones sobre los costos de la nube en lugares como HN: Sí, la nube es costosa, pero contratar incluso un solo administrador de sistemas/desarrollador adicional para ayudarlo a administrar una infraestructura personalizada es increíblemente costoso y mucho menos flexible. Es por eso que gastar unos hipotéticos $5000 al mes en una solución alojada en la nube que, en teoría, podría personalizarse en un servidor de $50 al mes con suficiente inversión de tiempo aún puede ser un gran negocio. Los ingenieros son caros y el tiempo es limitado.
Uhhh, disculpe, pero ¿cuánto le paga a este tipo de DevOps? Esta parece una perspectiva muy americana, incluso en la zona del valle. En Europa contratar a un chico sería más barato
Los costos de empleo totalmente cargados son significativamente más altos que lo que se lleva a casa en su cheque de pago. En realidad es peor en Europa. Eche un vistazo a estos gráficos: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Si le paga a alguien 1000 EUR en el Reino Unido, a la empresa le cuesta un total de 1245 EUR.
Si le pagas a alguien 1000 EUR en Rumanía, a la empresa le cuesta 1747 EUR en total.
Por lo tanto, un costo total de $120 000 solo podría permitirle obtener un salario de $68 000 USD para una persona de desarrollo de la UE.
Pero no se puede tener una sola persona devops. Necesitas al menos 2 si quieres permitir que uno de ellos se tome un descanso, se vaya de vacaciones o se vaya de vacaciones.
Puedo conectarte en aproximadamente 3 horas.
AWS es muy rentable para otros servicios (S3,SES,SQS, etc.), pero las máquinas virtuales no son un buen negocio. Obtienes menos RAM& CPU, con los gastos generales de virtualización, y paga mucho más dinero
Especialmente para Postgres, si ejecuta algunas pruebas con pgbench, realmente puede ver la penalización que paga por la virtualización.
Tal vez la habilidad de administrador de sistemas de poder construir su propia infraestructura se esté convirtiendo en un arte perdido; de lo contrario, no puedo explicar por qué la gente está tan enamorada de pagar 5 veces más por menos rendimiento.
Hetzner es barato y fiable en Europa; si estás en Norteamérica, echa un vistazo a OVH. Especialmente su alternativa de ahorro llamada SoYouStart. Puedes conseguir 4/8 4,5 ghz, 64 RAM y una unidad NVME por $65
(No tengo ninguna afiliación con OVH, solo soy un cliente con casi 100 servidores y me ha funcionado muy bien)
También señalaré que soy mayor, jeje, y en uno de mis primeros trabajos teníamos un centro de datos de tamaño decente en el lugar. Tratar con SAN, unidades de cinta (los rotadores automáticos de cintas en ese momento eran servidores, etc.) era un PITA enorme. Empacar las cintas y enviarlas a otra oficina para obtener redundancia de ubicación siempre fue divertido.
La aplicación particular que administro realmente sufre de bajos GHz y no tiene todos los datos en la memoria. He ejecutado los puntos de referencia en EC2, ciertos informes que finalizan en ~5 segundos pueden tardar más de un minuto en una instancia EC2 comparable que cuesta aproximadamente 10 veces más. Esta aplicación realmente necesita la CPU sin formato. Y sí, tenemos un equipo de ingeniería bastante grande que ha optimizado todas las consultas, índices, etc.
En cuanto a replicación, copias de seguridad, etc. Configuré todo eso y, sinceramente, no fue gran cosa. Son un par de capítulos cortos en el libro de Postgres que lo explican todo de manera muy simple, cómo configurar, probar de forma continua (y automática), etc.
Estoy de acuerdo en que las SAN son una pesadilla. Es por eso que envío todos mis WAL (archivos de respaldo PG) a S3 (y eventualmente a Glacier). De esa manera no tengo que pensar en perder esos archivos y es muy barato.
Creo que existe la idea errónea de que este tipo de configuraciones son demasiado complicadas para que las configure un solo ingeniero y requieren un mantenimiento interminable. En realidad, puede configurarlo todo en menos de una semana y solo necesita mantenimiento cuando desea actualizar Postgres (es posible que algunas configuraciones hayan cambiado). Calculo que se necesitan unas 5 horas al año de mantenimiento.
Es probable que la infraestructura de autoservicio se vuelva cada vez más viable a medida que continuamos mejorando la entrega de última milla y ampliamos el acceso a la fibra. ¿Se volverá la nube autocanibalizadora? Definitivamente puede ser
Lo que la nube le brinda es la capacidad de poner sus datos/carga de trabajo en el centro sin tener que hacer acuerdos especiales con su ISP local, y con mucha más resiliencia de la que probablemente podría permitirse a menos que esté lleno al menos en el contenedor múltiple de 20 pies. de servidores escala de necesidad informática
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Editar: si alguien está interesado en el autohospedaje, es sencillo con Cloudflared. Tengo un Google Pixelbook 2017 que ejecuta Ubuntu con firmware personalizado que sirve a un sitio web basado en Flask. Está en mi escritorio cargándose mientras está conectado a una red wifi para invitados. Recibe una puntuación de PageSpeed móvil de 100/100 y tarda 0,8 segundos en cargarse por completo
De DO obtengo todos los beneficios de una empresa confiable, escalabilidad, copias de seguridad automatizadas, etc., etc. No hay manera de que cambie
La nube de Hetzner ahora tiene dos ubicaciones en EE. UU. Sin embargo, todavía no hay servidores dedicados en EE. UU.; esos serían reales. Incluso si sus ofertas actuales de nube ya son ~30% del precio de los principales equivalentes de nube.
Al igual que tú, también administro mis servicios desde un servidor físico alquilado. Solía usar Versaweb, pero sus máquinas son demasiado viejas. Anteriormente no me gustaba Hetzner porque había oído cosas malas acerca de que interferían con lo que estás ejecutando.
Sin embargo, me mudé a ellos en diciembre cuando mi instancia de Versaweb acaba de morir, probablemente SSD por su vejez. Ahora estoy pagando el 50% de lo que pagué por Versaweb y puedo ejecutar 6 instancias de Postgres de este tipo.
Entonces uno se pregunta si vale la pena pagar $700 o $800 por un servicio administrado con una elegante interfaz de usuario en la nube, actualizaciones y copias de seguridad automáticas, etc.
Para una exposición de 1 persona o una pequeña startup, no lo creo. Es más económico utilizar un servicio disponible y volcar las copias de seguridad a S3 o algo más económico
La empresa para la que solía trabajar pagaba felizmente a la empresa A cuatro veces más de lo que cobraba la empresa B por exactamente el mismo servicio, solo porque la empresa A estaba dispuesta a enviar facturas trimestrales de una manera que encajaba bien con nuestro sistema de facturación. Para las empresas, ahorrar unos cuantos cientos de dólares aquí y allá a menudo no vale la pena de introducir fricciones adicionales.
Hay un costo implícito ahí. Si es solo una o dos de esas cosas, simplemente tome los servicios administrados.
Si comienza a escalar, obtenga un tipo de empleado administrador para ahorrar en esto
De lo contrario, tendría que contratar/contratar a alguien con mucha experiencia, o dedicar un mes entero o más de mi tiempo (que no estaba disponible), solo para estar 100% seguro de que siempre podríamos restaurar rápidamente las copias de seguridad PITR registradas.
Puedo ahorrar una magnitud considerable en los costos de la nube en otros lugares, pero PostgreSQL administrado y creíble fue una decisión bastante fácil (incluso si el precio básico era más alto de lo que cabría esperar).
Una startup temprana que no puede darse el lujo de perder una hora de datos de producción probablemente sea demasiado frágil para sobrevivir de todos modos.
Es una puesta en marcha temprana: habrá interrupciones mayores que esas en el servicio y cualquier cliente que huya después de una pérdida de datos de producción de una hora simplemente no valoró lo suficiente el producto de todos modos.
(En el inicio específico en el que estaba pensando, ya tenía algunos volcados de bases de datos en línea frecuentes y automatizados a S3 con retención impuesta, pero no pensé que fuera lo suficientemente bueno para este escenario en particular. Pero no estar seguro de que podríamos recuperarnos con PITR/diario agregaría un nuevo punto único de fracaso, apostando por el éxito de un negocio que de otro modo podría tener una salida de más de 9 cifras en unos pocos o varios años, solo para ahorrar unos pocos cientos).
Además, supongo que algunas de las primeras empresas que tienen necesidades menos exigentes, pero que son más arrogantes en cuanto a sus obligaciones con los datos de los clientes/usuarios, siguen siendo negligentes con las prácticas básicas mínimas.
Tal vez una forma intuitiva de apreciarlo: imagine una noticia de negocios en HN, sobre algunas operaciones de inicio que se dejan caer, con los nombres de los fundadores de inicio adjuntos, y la historia dice y resulta que no tenían buenos respaldos. Entonces uno de los Los cofundadores, que tal vez no hayan dormido mucho porque su empresa se derrumba a su alrededor, responde: "Los datos de los clientes no son tan importantes en una startup temprana; si lo fuera, seríamos demasiado frágiles"(escrito antes de que el cofundador pudiera arrojar la computadora portátil de esa persona al otro lado de la habitación para que dejen de escribir). no se veria bien
Me ocuparé de esto al final
>Imagine una noticia de negocios en HN, sobre algunas operaciones de startups que se dejan caer, con los nombres de los fundadores de startups adjuntos, y la historia dice y resulta que no tenían buenos respaldos.
ITYM y resulta que no tenían respaldada la última hora
Puedo imaginar todo en su escenario, incluso los bits no recortados, y todo parece normal, a menos que lea "Nuestros clientes emergentes, que nos han estado usando durante un mes, se fueron inmediatamente cuando perdimos la última hora de sus datos".
Realmente no puedo imaginar ese escenario.
Ahora bien, hay algunas empresas en las que el beneficio de usarlo es que no se pierden ni siquiera una hora de datos.
IOW, los clientes lo utilizan porque no pierden ningún dato: colaboración de documentos en línea[1], por ejemplo[2]. Si tiene una crisis que pierde una hora de los últimos datos ingresados, entonces, por supuesto, espere que todos los usuarios actuales afectados huyan de inmediato.
[1] Aunque, personalmente, mitigaría el riesgo duplicando el documento actual en el almacenamiento local mientras se edita.
[2] ¿Quizás la bolsa de valores también necesita que el sistema guarde los datos de la última hora? ¿Qué otra cosa?
Creo que incluso para equipos más grandes puede tener sentido administrar las bases de datos usted mismo, suponiendo que tenga la competencia para hacerlo bien. Hay tantas cosas que pueden salir mal con los servicios administrados y no ocultan la implementación subyacente como lo hacen cosas como el almacenamiento en bloques o el almacenamiento de objetos.
El rendimiento máximo es ciertamente peor, pero de todos modos no me molesta demasiado si algo tarda más en ejecutarse. Ciertamente tiene razón al tener tanta automatización en el aprovisionamiento de un servidor, algo que no hice con un servidor físico.
Solía tener un servidor raíz para mis proyectos favoritos, pero honestamente, eso no tiene sentido. No tengo mucho tráfico, calculo SaaS intenso en mis máquinas. Es solo un sitio web estático y algunos proyectos. Me he reducido a costos mensuales de 24 que incluyen una caja de almacenamiento de 1 TB para almacenar todos mis datos.
El principal problema en cualquier escenario que involucre hardware real es que se necesita personal que sea competente tanto en hardware como en sistemas Linux/UNIX. Muchos afirman estar en sus currículums y luego no pueden desempeñarse una vez en el trabajo (al menos, según mi experiencia). En mi opinión, una de las principales razones de la explosión del mundo de la nube fue precisamente la dificultad y el coste financiero de crear dichos equipos. Además, existe una fricción algo natural (y necesaria) entre los desarrolladores de aplicaciones y la gente de sistemas. La gente de sistemas siempre debería retroceder y abogar por más seguridad, más procesos y menos implementaciones. El equipo de desarrollo siempre debería abogar por una mayor flexibilidad, más lanzamientos y menos procesos. Una buena gestión debería entonces encontrar el camino intermedio entre ambos. Desafortunadamente, los gerentes incompetentes a menudo simplemente deciden deshacerse del personal de sistemas y trasladar las cosas a AWS.
Por último, solo quisiera señalar que la arquitectura de la nube es mala para el planeta, ya que requiere un aprovisionamiento excesivo por parte de los proveedores de la nube y, en general, requiere más potencia informática debido a las muchas capas de abstracción. Si bien cualquier proyecto es responsable de una pequeña parte de este desperdicio, toda la nube global en su conjunto es un gran desperdicio. Esto me molesta y obviamente es probable que tenga un sesgo emocional en mis puntos de vista (tantas cantidades de sal para todo lo anterior)
Se podría argumentar que puede desarrollar un medio para alquilar servidores físicos antes de obtener ingresos y luego, cuando tenga sentido, puede utilizar la depreciación estándar -o- la Sección 179 en compras directas y/o arrendamientos de la Sección 179.
Como ejemplo, puede implementar un grupo increíblemente capaz de, digamos, cuatro máquinas físicas 1U de $ 100 000 absolutamente sobreaprovisionadas en diferentes instalaciones de colo para redundancia. Aquí hay todo tipo de trucos para el equilibrio de carga y la conmutación por error con el servicio en la nube XYZ, DNS, anycast, lo que quieras. Puede optar por varias instalaciones de colo que operan centros de datos en todo el mundo, enviarles el hardware del proveedor y luego aprovisionarlas con Ansible o lo que sea que le interese sin siquiera ver las instalaciones ni tocar el hardware.
Así que ahora tiene hardware físico redundante que funcionará en círculos alrededor de la mayoría de los proveedores de nube (especialmente para E/S), costos fijos como todo lo que pueda ancho de banda (que no tiene el margen de beneficio del 800 % de los servicios de nube, etc.), no más esperas. por la inevitable factura de la nube de 50.000 dólares o intentar rastrear (en pánico) qué provocó que excediera su presupuesto de nube configurado en un día en lugar de un mes. Ah, por cierto, no te estás encerrando en las ridículas API propietarias para aprovisionar e incluso utilizar servicios distintos de las máquinas virtuales que ofrece $BIGCLOUD.
Si está haciendo ML, puede entrenar en su propio hardware o (o en la nube ocasional) y ejecutar inferencia las 24 horas del día, los 7 días de la semana con cosas como NVIDIA A10. El alquiler continuo en la nube para instancias de GPU es increíblemente costoso y el retorno de la inversión en la compra del hardware suele estar en el rango de unos pocos meses (o muy por delante casi de inmediato con la Sección 179). Como ejemplo, recientemente hice una prueba comparativa con la Nvidia A10 para un modelo que estamos ofreciendo y puede realizar más de 700 solicitudes de inferencia/s en FP32 con una latencia inferior a 10 ms. Con un solo A10 por chasis en cuatro instancias en buen estado, eso es 2800 solicitudes/s (y probablemente podría ajustarse más)
Luego, si REALMENTE creces, puedes empezar a conseguir gabinetes y más. En términos de fallas de hardware, como se mencionó, todo lo que puedo decir es salida dual PS RAID, etc., el hardware es (según mi experiencia) extremadamente confiable. Habiendo tenido varios gabinetes completos de hardware en el pasado, las fallas de hardware fueron pocas y distantes entre sí y el hardware Los proveedores incluirán increíbles SLA para el reemplazo. Les notificas del fallo y envían un técnico.< ocho horas directamente a las instalaciones de colo y reemplace el disco, PS, etc. con la luz intermitente
Mi experiencia es que un (bueno) recurso FTE puede gestionar esto fácilmente hasta una escala de varios gabinetes. En su opinión, el problema actual es que muchas de estas personas han sido arrebatadas por los grandes proveedores de la nube y reemplazadas (en el mercado) con recursos que pueden navegar por la ridiculez límite que supone utilizar docenas (si no más) productos/servicios de $ NUBE GRANDE
También descubrí que esta configuración es MUCHO más confiable que la mayoría de $BIGCLOUD. Ya no tendrás que preguntarte qué está pasando con una interrupción de $BIGCLOUD que ni siquiera reconocen (y sobre la que no tienes ningún control). Dado que tengo experiencia en telecomunicaciones y atención médica, me resulta completamente sorprendente cómo el tiempo de actividad ha empeorado mucho con los proveedores de la nube. Por lo general, puedes simplemente decirles a los clientes "oh, Internet está teniendo problemas hoy"porque probablemente verán titulares al respecto, pero para muchas aplicaciones eso es totalmente inaceptable, y deberíamos esperar algo mejor.
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Si quiero poner en marcha un nuevo proyecto o intentar alojar algo nuevo, me llevará un par de minutos y ya tengo los guiones. Las implementaciones son rápidas, el mantenimiento es bajo y tengo mucho más por mi dinero
Para cualquiera que esté interesado, este es el borrador de lo que estoy usando:
* Ansible para gestionar todo.
* Un poquito de terraformación para algunas entradas DNS que quizás reemplace algún día
* restic para copias de seguridad, nuevamente controlado por ansible
* tailscale para vpn (tengo algunos pi ejecutándose en casa, nada importante, pero tailscale lo hace fácil y seguro)
* docker-compose para casi todo lo demás
La aplicación principal es Clojure, así que ejecuto una JVM nativa. La base de datos está completamente distribuida, RethinkDB, ahora trabajando para migrar a FoundationDB
Lo importante es no gestionar nada manualmente, p.e. Trate los servidores físicos como cualquier otro servidor en la nube. No debería importar si es físico o virtualizado.
He visto a muchas personas con menos experiencia pagar de más por Hetzner y similares cuando un vps de $ 5 a 10 hubiera funcionado.
Sí, en ese momento estás soportando tu propio hardware. No, no es un gran dolor de cabeza.
El mayor coste adicional es el alquiler de más direcciones IPv4, que Hetzner cobra generosamente por ahora que hay tan pocas disponibles.
Cualquier cosa que cree, comenzará con 0 usuarios, y una máquina real completa es completamente excesiva para esa carga 0 que obtendrá. Actualiza su VPS a un par de máquinas reales, luego a un pequeño clúster alquilado y luego a un centro de datos (si alguien no lo socava). Todos ellos tienen facturas predecibles y un rendimiento superior por su precio.
Todo lo que tengas en una colo también costará más por mes. Cuando tenía conexiones donde podía pagar por una IP estática, normalmente era $5 al mes.
Ahora estoy alquilando un servidor bastante bajo, pero cuesta $30/mes. Mucho más todo lo que necesito, pero es agradable. Y no eliminaron el soporte para mi sistema operativo mientras aumentaban los precios para mejorar el soporte o algo así. (Aunque inicialmente tenía un hardware inestable que necesitaba ser cambiado)
como usted señaló, el metal desnudo es el camino a seguir. funciona al contrario de la nube: un poco más de trabajo al principio pero mucho menos de gastos al final
Más información httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Configurar y administrar Postgres es un dolor aunque. Sería bueno tener una forma más simple de hacer esto bien
1. Obliga a que la configuración sea reproducible, ya que las máquinas virtuales dejarán de funcionar.
2. Puede obtener grandes descuentos en AWS que reducen el dolor
3. Las otras cosas a las que tiene acceso encima de las máquinas virtuales que son más baratas/más rápidas una vez que sus cosas ya están en la nube
4. Es más fácil tener una configuración de sistema documentada (por ejemplo, documentos de AWS) que capacitar a las personas/documentar qué cosas especiales tiene internamente. Especialmente útil para contratar gente nueva.
5. No necesita espacio ni energía redundante/internet/etc. en las instalaciones. Solo lo suficiente para permitir que las personas usen sus computadoras portátiles
Usé un VPS antes de eso, pero me detuve y me cambié a uno físico porque era una mejor oferta y no nos encontramos con límites de CPU.
Sin embargo, la supervisión del disco no es demasiado difícil. Para discos duros, ejecute smartctl una vez por hora, alerta cuando los sectores reasignados o pendientes crezcan rápidamente o lleguen a 100. Para SSD, cruce los dedos; en mi experiencia con unos pocos miles, tienden a funcionar muy bien hasta que desaparecen del autobús, para no ser vistos nunca más. Tenga un plan de recuperación de datos que no implique el almacenamiento de los datos en dispositivos del mismo modelo con horas de encendido muy similares. Los errores de firmware correlacionados con horas de encendido son reales.
Después de todo, Hetzner tiene una API para ordenar servidores dedicados y una API para instalar un sistema operativo (o para reiniciar para rescatar y mostrar cualquier imagen que desee)
Supongo que si estuviera investigando opciones comerciales, ordenaría el "maletero"en la oficina con una solución de ISP comercial, IP estática, tal vez un buen hardware de TI, pero por lo que sé en este momento exacto, si un cliente necesita alojamiento. d siempre ir directamente a alquilar un vps
Era más un desarrollador junior en ese momento, así que tal vez lo era, pero no lo extraño en absoluto. En teoría, estoy de acuerdo con lo que dices, pero implementar un Dockerfile en algo como Google Cloud Run es mucho más fácil. Sí, estoy pagando más de lo que estaría administrando mi propio VPS, pero creo que esto está más que compensado por las horas de desarrollo ahorradas.
- el hardware físico tiene problemas, p. falla del ventilador ->mi VM se migra en vivo a un host diferente, no me doy cuenta ni me importa
- el hardware físico explota ->mi VM se reinicia en un host diferente, podría notarlo pero no me importa
La planificación ante desastres es mucho más fácil con las máquinas virtuales (incluso con mascotas, no con ganado)
Para un principiante, los más baratos hacen el trabajo.
Estoy seguro de que a medida que evoluciona la computación en la nube, estas ofertas se vuelven más comunes.
Hay otro aspecto de la computación en la nube. Las empresas medianas y grandes cuentan la computación en la nube como porcentajes de un solo dígito en sus cálculos de costos. Esto significa que las decisiones que toman los gerentes y equipos, a menudo buscan confiabilidad y escalabilidad (que se pondrán en sus presentaciones) en lugar de "¿mi configuración es costosa o barata?"Mi empleador adoptó la nube como una estrategia comercial/financiera, no religiosa. A menudo colocamos nuevas construcciones en la nube y migramos a un centro de datos si es necesario más adelante.
Las aplicaciones locales cuestan aproximadamente un 40% menos. Las aplicaciones que son más rentables en la nube permanecen allí
Creo que se da el caso de que AWS/GCP/Azure no son ofertas muy competitivas en términos de costos en Europa. Lo que no veo es evidencia de eso para los EE. UU.
para la misma especificación, claro. Creo que los virtuales tienen sentido en ambos extremos: o la escalabilidad dinámica para N grandes es importante o solo se necesita una pequeña fracción de una caja física. Pagar 45 al mes por algo que se ejecuta en búsqueda 5 al mes tampoco es sensato y le brinda más flexibilidad para no agrupar cosas solo para usar su servidor.
Mantenga copias de seguridad en cualquier caso. Preferiblemente en otro proveedor o al menos en una ubicación física diferente. Y, por supuesto, pruébalos
Y si está administrando un buen régimen de respaldo y monitoreando sus datos/aplicaciones de todos modos, ¿el monitoreo de unidades es una dificultad adicional significativa?
--
[1] de hecho, si automatizas el proceso de restauración a otra ubicación, lo cual hago con un par de mis bits, entonces puedes presionar ese botón y actualizar el DNS cuando esté completo, y tal vez asignar un poco más de núcleos de RAM+ (mi prueba los espejos son más pequeños que las máquinas virtuales en vivo ya que no necesitan servir patrones de uso real)
Exactamente lo que hago por mí y por mis clientes. Ahorra toneladas de dosh
Incluso si quisiera actualizar, es solo cuestión de incorporar la última versión a la plantilla de Docker-Compose y volver a ejecutar el libro de jugadas de Ansible. Obviamente, si la actualización requiere más, que así sea, pero no es diferente a cualquier otra configuración en cuanto a trabajo.
Probablemente lo único que _necesito_ hacer manualmente es probar mis copias de seguridad. Pero tengo un script para cada proyecto que lo hace, así que simplemente enciendo SSH, ejecuto el resumen, verifico el resultado y listo. Lo hago aproximadamente una vez al mes, pero también recibo correos electrónicos si falla una copia de seguridad.
Entonces puede que no sea ningún momento. Por lo general, son probablemente de 1 a 2 horas al mes si recibo actualizaciones de forma semiregular. Pero eso aumentará a medida que más cosas alojes y administres.
En otras palabras, la única diferencia es de dónde proviene el archivo de inventario ansible. O es una lista estática de IP o proviene de terraform
Si desea RAM ECC, parece ser 60 por mes y también aumenta a una CPU de 8 núcleos más potente.
De todos modos, si estamos hablando de un "entorno de producción completo y un entorno de prueba/en espera duplicado"(para citar a la persona a la que respondió), entonces 60/mes * (2 o 3) sigue siendo muy barato en comparación con AWS de cualquier startup. factura que he visto
Los casos de uso varían, pero tiendo a estar de acuerdo en que AWS/GCP/Azure no es la respuesta a todos los problemas.
Para alguien que puede instalar su aplicación en un VPS de $4, obviamente será más barato que cualquier cosa básica, pero la nube crece muy costosa en muchos casos. El metal desnudo tampoco es la respuesta a todos los problemas, pero mucha gente en la industria no parece apreciar cuándo puede ser la respuesta correcta.
SERVIDORES PRIVADOS VIRTUALES#120
