amazon ec2 - tipo - ¿Por qué no quieres usar Cloud Computing
tipo de instancia amazon (18)
Nuestra compañía está considerando mudarse de alojar nuestros propios servidores a EC2 y me preguntaba si era una buena idea.
He visto muchas cosas sobre ¿puede la computación en la nube (y específicamente EC2) hacer x, o puede hacer y, pero mi verdadera pregunta es por qué NO querrías usarla?
Si estaba creando una empresa, ¿cuáles son las razones (fuera del costo) por las que elegiría tomarse la molestia de administrar sus propios servidores?
Sé que hay muchos cálculos de costos que puede realizar con respecto al ancho de banda, el uso del disco, etc., pero, por supuesto, existen otros costos relacionados con el mantenimiento de su propio servidor. Por el bien de esta discusión, estoy dispuesto a considerar los costos aproximadamente iguales.
Me parece recordar que Joel Spolsky escribió un pequeño borrón sobre esto al mismo tiempo, pero no pude encontrarlo.
Alguien tiene alguna razón?
¡Gracias!
Además de lo que ya se ha dicho aquí, debemos considerar la uniformidad en todo el negocio. ¿Todas sus aplicaciones serán alojadas en la nube, o solo la mayoría? ¿Es suficiente apretar el gatillo para usar la nube cuando todavía tiene que tener personal para manejar algunos servidores especiales?
En particular, puede haber hardware especial que necesita para comunicarse con dichos módems para aceptar datos entrantes, o tarjetas de voz que hacen llamadas telefónicas automáticas. No sé cómo se podrían manejar tales cosas en un entorno de nube.
Algunas preguntas para hacer:
¿Cuál es el tiempo de actividad esperado y cómo afecta el tiempo de inactividad a su negocio? ¿Qué tipo de acuerdo de nivel de servicio puede obtener, cuáles son las penalidades por perderlo y qué tan seguro está de que se cumplirán los objetivos de tiempo de actividad de SLA? (Pueden ser mejores o peores para mantener los sistemas arriba de lo que está).
¿Qué tan sensibles son los datos que propones poner en la nube? Una vez más, entramos en la cuestión de qué tan seguro se compromete el proveedor, cuáles son las sanciones contractuales y las indemnizaciones, y qué tan seguro está de que el proveedor cumplirá con el acuerdo. Además, puede haber requisitos externos. Si maneja datos relacionados con la salud en los EE. UU., Está sujeto a requisitos muy estrictos. Si maneja datos de tarjetas de crédito, también tiene responsabilidades (contractuales, no legales).
¿Qué tan fácil será abandonar el acuerdo, si el servicio no fuera lo que se esperaba, o si encuentra un mejor trato en otro lado? Esto incluye no solo recuperar sus datos, sino también alguna versión de las aplicaciones que ha estado usando. Considere las posibilidades de quiebra de su proveedor (Amazon no va a ir a la quiebra en el corto plazo, pero podrían dividir a un proveedor de la nube que luego podría ir a la quiebra), o tener una reorganización interna. Tenga en cuenta que una empresa en problemas graves puede no estar a la altura de sus expectativas de servicio.
¿Cuánta independencia vas a tener? ¿Vas a ejecutar su software o software que elijas? ¿Qué tan fácil será reconfigurar?
¿Cuál es el esquema de precios? ¿Es posible que las facturas alcancen niveles inaceptables sin una advertencia adecuada?
¿Cuál es el plan de desastre? Idealmente, está ejecutando su software en servidores en una ubicación diferente de donde ocurrió el desastre.
¿Qué piensa su departamento legal (o abogado corporativo retenido) del contrato? ¿Existe un mecanismo de resolución de disputas y, de ser así, es justo para usted?
Finalmente, ¿qué esperas para salir de la nube? ¿Qué estás dispuesto a pagar? ¿Qué puedes comprometer y qué necesitas?
Depende de cuánto confíe en su propia infraestructura en comparación con un servicio en la nube de un tercero. En mi opinión, la mayoría de las empresas (al menos no relacionadas con TI) deberían elegir la más tarde.
El más grande es: si Amazon se cae, no hay nada que puedas hacer para restablecerlo.
No estoy hablando de escenarios apocalípticos donde la compañía desaparece. Quiero decir que estás a merced de su tiempo de inactividad, con pocos recursos propios.
Esto es algo así como el comentario "¿Por qué usarías Linux?" Que recibí de la administración hace muchos años. La respuesta que obtuve fue que es una solución en busca de un problema.
¿Cuáles son sus metas y objetivos al mudarse a EC2?
Me interesaría saber si aún deseas moverte a una nube, si fuera tuya.
Existen diferentes tipos de computación en la nube con muchos proveedores diferentes proporcionándola. Me pondría nervioso codificar mis aplicaciones para trabajar con un único proveedor de la nube. que específicamente tenía que codificar..amazon y Microsoft, creo que necesita codificar específicamente para esa plataforma, tal vez también para google.
Dicho esto, hace poco abandoné mis propios servidores dedicados y me mudé a la plataforma Rackspaces Mosso Cloud (que no necesita codificación propietaria) y estoy realmente muy contento con ella hasta el momento. Reduzco mis costos a la mitad y el rendimiento es mucho mejor que antes. Las bases de datos de mi servidor sql ahora se ejecutan en las versiones de servidor SQL empresarial de 64 bits con 32G de RAM, eso me hubiera costado una fortuna en la infraestructura de mis proveedores anteriores.
En cuanto a no tener suerte cuando la nube está baja, eso fue cierto si mi servidor dedicado se cayó, nunca lo hizo, pero si hubo un bloqueo de hardware en mi servidor dedicado, no estoy seguro de que vuelva a estar en línea. cualquier espacio más rápido que el espacio en bastidor podría hacer que su nube vuelva a subir.
Falta de control.
La computación en la nube ha llevado la programación paralela un poco más cerca de las masas, pero aún debe comprender cuál es la mejor manera de usarla; de lo contrario, desperdiciará los ciclos de computación y el ancho de banda.
Reestructurar su aplicación para un uso más eficiente de un servicio de computación en la nube no es trivial.
La mayoría del entorno de cómputo en la nube es al menos parcialmente específico del proveedor. No hay una buena manera de mover cosas de una nube a otra sin tener que hacer muchas reescrituras. Ese tipo de lock-in lo pone a merced de un proveedor cuando se trata de tiempo de inactividad, aumentos de precios, etc. Si alquila o posee sus propios servidores, los proveedores de hosting y los colos son prácticamente intercambiables. Siempre tienes la opción de mudarte a otro lugar.
Esto puede cambiar en el futuro, ya que estas cosas se estandarizan, pero por ahora vincularse a la nube significa vincularse a un proveedor específico.
Los datos altamente confidenciales podrían ser mejores para controlarse a sí mismo. Y hay legislación; cierta información confidencial, por ejemplo, podría no salir del país.
Además, a excepción de Microsoft Azure en combinación con SDS, las tiendas de datos tienden a no ser relacionales, lo cual es una molestia en ciertos casos.
Los problemas de seguridad no son relevantes si su aplicación realiza su propio cifrado. Amazon está almacenando datos encriptados que no tienen forma de descifrar.
Pero además de los problemas de tiempo de actividad, Amazon podría decidir aumentar sus precios a lo que quiera. Si eres dependiente de ellos, solo tendrás que pagarlo.
Otra cosa que pierde con la nube es la capacidad de elegir exactamente qué sistema operativo desea ejecutar. Por ejemplo, el último kernel de Fedora Linux disponible en EC2 es FC8, y la última versión de Windows es Server 2003.
Poner su software en la nube de otra persona representa la entrega de algún control. Pueden instituir un límite de tamaño de carga de archivos o límites de memoria que podrían arruinar su aplicación. Una vulnerabilidad de seguridad en su panel de control podría hacer que su sitio sea pirateado.
Preguntas de seguridad sin respuesta.
Realmente, ¿quieres que tu IP esté ahí, donde no eres el que tiene el control?
Puedo pensar en varias razones por las que no uso EC2 (y estoy hablando de EC2, no comp de la red en general):
- Confiabilidad : Amazon no garantiza la disponibilidad / tiempo de inactividad / seguridad de EC2
- Seguridad : Amazon no ofrece ninguna garantía sobre a quién revelará sus datos
- Persistencia : asegurar la persistencia de sus datos (que incluye, el esfuerzo por configurar el sistema) es complicado en comparación con EC2
- Gestión : hay muy pocas herramientas de gestión integradas para una nube implementada en EC2
- Red : la red virtual que permite que las instancias EC2 se comuniquen tiene algunas limitaciones bastante dolorosas (latencia, no multidifusión, ubicación topológica arbitraria)
Y para terminar eso:
- Costo : a largo plazo, si no está utilizando EC2 para absorber el tráfico pico, va a ser mucho más costoso que invertir en sus propios servidores (los servidores cheapo como Supermicro cuestan solo un par de cientos de dólares ...)
Por otro lado, sigo creyendo que EC2 es una excelente forma de absorber el tráfico pico no confidencial, si su arquitectura lo permite.
Quizás la preocupación de que esa gran compañía sea más probable que sea abordada por un agente Smith del gobierno para espiar a todos los que un pequeño pequeño proveedor en algún lugar.
Gran empresa, más clientes, más datos para agregar y reconocer patrones, más recursos para organizar un sofisticado sistema de vigilancia.
Tal vez es más una fantasía, pero ¿quién sabe?
Si no tienes una paranoia, eso no significa que no te estén vigilando.
Además de los problemas planteados con respecto a la confiabilidad, la confiabilidad y el costo, se trata de la propiedad de los datos. Cuando localiza datos en el servidor de otra persona, ya no controla quién visita, accede, modifica o usa esa información. Si bien los operadores de la nube pueden limitar su acceso, no posee ninguna forma de limitar el suyo o limitar a quién le dan acceso. Sí, puede encriptar todos los datos en el servidor, pero no tiene ninguna forma de saber quién posee acceso de root al servidor en sí y cualquier medio para evitar que otros descarguen sus datos encriptados y los abran. Pierdes el control sobre tus datos; Dependiendo del tipo de aplicaciones que esté ejecutando y la naturaleza propietaria de los datos involucrados, esto podría generar riesgos de responsabilidad corporativa y / o responsabilidad.
El otro factor a considerar es qué le pasaría a su empresa si Amazon y / o EC2 desaparecieran repentinamente de la noche a la mañana. Mientras que una posición aparentemente absurda, podría suceder. ¿Sería capaz de llenar rápidamente el agujero y restaurar el servicio, o sus aplicaciones potencialmente generadoras de ingresos languidecen mientras el personal de TI lucha para obtener servidores y ancho de banda para volver a ponerlos en línea? Además, ¿qué pasaría con sus datos? El disco duro en la nube que contiene toda su información aún existe, en algún lugar, y podría representar un riesgo de responsabilidad potencial según la información que haya almacenado allí: elementos como información personal, registros de transacciones comerciales, etc.
Si comenzara mi propio negocio ahora, pasaría por la molestia de comprar y mantener mis propios servidores, por lo que mantuve la propiedad de los datos. Pude controlar el acceso raíz al hardware, así como controlar quién puede acceder y modificar los datos.
- Seguridad: no sabe qué se está haciendo con sus datos
- Dependencia: su empresa ahora está directamente entrelazada con el proveedor