[ad_1]
Si bien Serverless suele defenderse como una forma de reducir costos y escalar masivamente según la demanda, hay una razón extraordinariamente convincente sobre todas las demás para adoptar un enfoque sin servidor: es la mejor manera de lograr la máxima velocidad de desarrollo en el tiempo. No es fácil de implementar correctamente y ciertamente no es una cura para todos, pero, si se hace bien, allana un camino extraordinario para maximizar la velocidad de desarrollo, y es por esto que la tecnología sin servidor es la tecnología más inflada y menos discutida Movimiento entre los fundadores e inversores de hoy.
El caso de Serverless comienza con una simple premisa: si la puesta en marcha más rápida en un mercado determinado va a ganar, entonces Lo más importante es mantener o aumentar la velocidad de desarrollo a lo largo del tiempo. Esto puede parecer obvio, pero muy, muy pocas empresas de estado manteniendo o aumentando la velocidad de desarrollo Como un objetivo explícito.
"Velocidad de desarrollo", para ser específico, significa la velocidad a la que puede entregar una unidad de valor adicional a un cliente. Por supuesto, una unidad adicional de valor para el cliente se puede entregar ya sea enviando más valor a los clientes existentes o enviando el valor existente, es decir, las características existentes, a los nuevos clientes.
Para muchas nuevas empresas de tecnología, particularmente en el espacio B2B, ambas están controladas por el rendimiento del desarrollo (el primero por razones obvias y el último porque la incorporación de nuevos clientes suele estar limitada por la automatización de la integración que deben ser construidas por los ingenieros). ¿Qué significa sin servidor, exactamente? Es un nombre poco apropiado. Tal como computación en la nube no significaba que los centros de datos desaparecieran en el éter, significaba que esos centros de datos estaban a cargo de otra persona y que los servidores podían aprovisionarse a pedido y pagarse por horas, sin servidor no significa que no haya ningún servidor.
Siempre tiene que haber servidores en alguna parte. En términos generales, sin servidor significa que usted no es responsable de toda la configuración y administración de esos servidores. Una buena definición de serverless es computación de pago por uso donde el tiempo de actividad está fuera del control del desarrollador. Con uso cero, hay costo cero. Y si el servicio se cae, usted no es responsable de volver a ponerlo en marcha. AWS comenzó el movimiento sin servidor en 2014 con una plataforma de "cómputo sin servidor" llamada AWS Lambda.
Mientras que un servidor en la nube "normal" como la oferta EC2 de AWS tenía que aprovisionarse por adelantado y se facturaba por hora independientemente de si se usaba o no, AWS Lambda se aprovisionó instantáneamente, a pedido, y solo se facturó por solicitud. Lambda es sorprendentemente barato: $ 0.0000002 por solicitud más $ 0.00001667 por gigabyte-segundo de cómputo. Y mientras que los usuarios tienen que aumentar el tamaño de su servidor si alcanzan una restricción de capacidad en EC2, Lambda escalará más o menos infinitamente para adaptarse a la carga, sin ninguna intervención manual. Y, si una instancia de EC2 falla, el desarrollador es responsable de diagnosticar el problema y volver a conectarlo, mientras que si un Lambda muere, otro Lambda puede tomar su lugar.
Si bien Lambda, y servicios equivalentes como Azure Functions o Google Cloud Functions, son increíblemente atractivos desde el punto de vista de los costos y la capacidad, la verdad es que ahorrar dinero y prepararse para la escala son muy malas razones para que una startup adopte una tecnología determinada. Pocas startups fallan como resultado de gastar demasiado dinero en servidores o de escalar para satisfacer la demanda de los clientes; de hecho, la optimización de cualquiera de estas cosas es una forma de escalamiento prematuro y escalamiento prematuro en una o varias dimensiones (contratación, marketing, ventas, características del producto e incluso jerarquías / títulos) es la causa principal de muerte para la gran mayoría de las startups. En otras palabras, la optimización prematura del costo, la escala o el tiempo de actividad es un antipatrón.
Cuando las personas hablan de un enfoque sin servidor, no solo quieren tomar el código que se ejecuta en los servidores y dividirlo en funciones Lambda para lograr costos más bajos y escalas más fáciles. Una arquitectura sin servidor adecuada es una forma radicalmente diferente de crear una aplicación de software moderna, un método que se ha denominado un sin servidor, servicio completo enfoque.
Comienza con la adopción agresiva de las plataformas disponibles, es decir, servicios gestionados—Como AWS Cognito o Auth0 (autenticación de usuario— registrarse e iniciar sesión como servicio), AWS Step Functions o Azure Logic Apps (workflow-orchestration-as-a-service), AWS AppSync (GraphQL backend-as -a-service), o incluso servicios más familiares como Stripe.
Mientras que las ofrendas de Lambda proporcionan funciones Como servicio, los servicios gestionados proporcionan. funcionalidad como servicio La distinción, en otras palabras, es que tú escriba y mantenga el código (por ejemplo, las funciones) para el cálculo sin servidor, mientras que el proveedor Escribe y mantiene el código para servicios gestionados. Con servicios gestionados, la plataforma proporciona tanto la funcionalidad y Gestionando la complejidad operativa que hay detrás.
Al adoptar servicios administrados, la gran mayoría de la funcionalidad "básica" de una aplicación (autenticación, almacenamiento de archivos, puerta de enlace API y más) se maneja mediante las diversas plataformas disponibles en el mercado de la nube, que están unidas con una capa delgada de su propio código de 'pegamento'. El código de pegamento, junto con la lógica empresarial restante que hace que su aplicación sea única, se ejecuta en una infraestructura Lambda (o equivalente) ultra económica y escalable, lo que elimina la necesidad de servidores por completo. Pequeños equipos de ingeniería como el nuestro lo están utilizando para crear aplicaciones increíblemente potentes y fáciles de mantener en una arquitectura que produce una velocidad de desarrollo sostenible sin precedentes a medida que la aplicación se vuelve más compleja.
Hay una compensación a la hora de adoptar la filosofía de servicio completo y sin servidor. La creación de una aplicación sin servidor radicalmente requiere un gran éxito en la velocidad de desarrollo a corto plazo, ya que a menudo es mucho más rápido crear un "servicio" que utilizar uno de los productos de AWS listos para usar. Cuando los desarrolladores están considerando un servicio como Stripe, "compilar contra comprar" ni siquiera es una pregunta: es inequívocamente más rápido usar el servicio de pago de Stripe que construir un servicio de pago usted mismo. Más exactamente, es Más rápido para entender el modelo de Stripe para pagos que para entender y construir un modelo propietario para pagos—Un testimonio tanto de la complejidad del espacio de pago como del servicio intuitivo que ha desarrollado Stripe.
Pero para los desarrolladores que tratan con algo como la autenticación (Cognito o Auth0) o la organización de flujo de trabajo (AWS Step Functions o Azure Logic Apps), generalmente es más lento para comprender e implementar el modelo del proveedor para un servicio que implementar la funcionalidad dentro de la base de código de la aplicación (ya sea escribiéndola desde cero o utilizando una biblioteca de código abierto). Al elegir usar un servicio administrado, los desarrolladores están deliberadamente eligiendo ir más lento en el corto plazo, una píldora difícil de tragar para una empresa nueva. Muchos, comprensiblemente, eligen ir rápido ahora y rodar los suyos.
El problema con este enfoque vuelve a un antiguo axioma en el desarrollo de software: "el código no es un activo, el código es la deuda". El código requiere una entrada en ambos lados de la ecuación contable. Es un activo que permite a las empresas entregar valor al cliente, pero también requiere un mantenimiento que debe contabilizarse y distribuirse a lo largo del tiempo. En igualdad de condiciones, las nuevas empresas quieren la base de código más pequeña posible (siempre y cuando, por supuesto, los desarrolladores no lo lleven demasiado lejos y escriban código inteligente pero ilegible). Menos código significa menos área de superficie para mantener, y también significa menos área de superficie para que los nuevos ingenieros puedan agarrar durante el aumento de velocidad.
Aquí radica la magia de usar servicios gestionados. Las empresas nuevas obtienen el uso beneficioso del código del proveedor como un activo sin tener esa deuda de código en su "hoja de balance técnico". En cambio, el código se encuentra en el proveedor balance general, y los ingenieros del proveedor tienen la tarea de mantener, mejorar y documentar ese código. En otras palabras, las startups obtienen código que es auto-mantenimiento, auto-mejora, y auto-documentación—El equivalente a contratar un equipo de ingeniería de primera categoría dedicado a una parte no básica del código base — de forma gratuita. O, más precisamente, a un costo predecible por uso. Contrasta esto con el uso de un servicio administrado como Cognito o Auth0. En el primer día, tal vez no tenga todas las funciones en la lista de deseos de una startup. La diferencia es que el proveedor cuenta con un equipo de ingenieros y gerentes de producto cuya única tarea es enviar mejoras a este servicio día tras día. Su emocionante producto principal es el posible hijastro pelirrojo de otra compañía.
Si hay un solo principio de unificación entre el equipo de ingeniería de una startup, debería ser escribir como un código pequeño, y ser responsable de la menor cantidad de servicios no esenciales, tan humanamente como sea posible. Al adoptar esta filosofía, una startup puede construir una plataforma que puede procesar miles de millones de transacciones a un costo extremadamente predecible y puramente variable, con casi cero desvíos de supervisión.
Ser perezoso requiere una sorprendente cantidad de disciplina. Ser bueno en la gestión de una base de código sin servidor y una infraestructura sin servidor no es trivial. Significa crear prácticas extensas en torno a las pruebas y la automatización, lo que significa una inversión inicial aún mayor. Integrarse con un servicio administrado puede ser increíblemente doloroso, con días dedicados a tratar de comprender todos los vacíos, errores y casos extremos. La tentación de implementar una solución propietaria puede ser increíble, especialmente cuando significa que una historia puede hacerse en cuestión de minutos u horas en lugar de días o más.
Significa escribir soluciones alternativas cuando un servicio solo satisface el 80% de las necesidades de un desarrollador. Y a medida que se libera el 20% de la funcionalidad, significa un código de refactorización para eliminar la solución, incluso cuando funciona bien y no hay beneficios a corto plazo para cambiarlo. La importante inversión inicial significa que un enfoque sin servidor / servicio gestionado primero no es correcto para cada inicio. La pregunta más importante a hacer es, ¿En qué escala de tiempo necesitamos ser rápidos? Si la respuesta es en días o semanas, como es el caso de muchas startups muy tempranas, probablemente no sea el enfoque correcto.
Pero si la escala de tiempo para la optimización de la velocidad ha cambiado desde días o semanas a meses o años, vale la pena echarle un vistazo de cerca a ir sin servidor.
Reclutar a grandes ingenieros es extraordinariamente difícil, y solo se hace más difícil. Es una tremenda ventaja competitiva hacer que aquellos ingenieros creen una funcionalidad de negocios diferenciada mientras sus competidores construyen servicios que realizan trabajos pesados no diferenciados, y luego permanecen estancados en el mantenimiento de esos servicios durante los próximos años. Por supuesto, hay ciertos casos en los que el servidor sin servidor simplemente no tiene sentido, pero estos están desapareciendo a una velocidad rápida (por ejemplo, el tiempo de espera de Lambda de Lambda se triplicó recientemente a 15 minutos) y razones como el bloqueo o la latencia. En general son tonterías o una cosa del pasado.
En última instancia, el trabajo de un inicio de software, y por lo tanto el trabajo del fundador, es entregar el valor al cliente por encima y más allá de la capacidad de la competencia. Ese trabajo se reduce a maximizar la velocidad de desarrollo, que, a su vez, se reduce a mitigar la complejidad siempre que sea posible. Puede ser que cada base de código, y por lo tanto cada inicio, esté destinada a convertirse en "una gran bola de barro", el término acuñado en un documento de 1997 para describir el "estructurado al azar, extenso, descuidado, cinta adhesiva y empacado". cable, código de espagueti en la jungla ”que cada proyecto de software parece eventualmente destinado a convertirse.
Un día, la complejidad crecerá más allá de un punto de ruptura y la velocidad de desarrollo comenzará a disminuir irreversiblemente, por lo que el trabajo final del fundador es presionar ese día mientras sea humanamente posible. La mejor manera de hacerlo es mantener su bola de barro al mínimo tamaño posible: sin servidor es la herramienta más poderosa que se haya desarrollado para hacer exactamente eso.
[ad_2]
VendeTodito