¿Por qué la obsesión del cliente de Amazon debería hacerla más amigable con el código abierto

            
                                                                             
            
            

 amazon-logo-seattle.jpg

                                            Imagen: Ben Fox Rubin / CNET
                                        

Lo más aterrador de AWS para sus competidores es que el líder de la nube está diciendo la verdad. ¿Que verdad? Ese AWS no se fija en la competencia, sino en satisfacer las necesidades de los clientes. Como dijo el jefe de AWS, Andy Jassy, ​​en AWS re: Invent la semana pasada, hablando de la nueva tecnología local de la compañía Outposts : “No veo a Outposts como un disparo en la proa de nadie. Si miras En lo que estamos haciendo, está muy bien informado por los clientes. “

Clientes. Esa palabra sale mucho de la boca de Jassy, ​​utilizada para justificar la construcción de todo tipo de cosas, como Outposts, que una vez la compañía evitó. Es lo que hace que AWS sea tan difícil de predecir, como he escrito pero en mis conversaciones con AWS, sus clientes y sus socios en re: Invent, está claro que la “obsesión del cliente” es lo que realmente hace Garrapata de AWS. Esa obsesión debería llevar a AWS a tomar aún más en serio los proyectos de código abierto que cada vez más se convierten en servicios.

VER: Comparación de proveedores: Microsoft Azure, Amazon AWS y Google Cloud (Tech Pro Research)

Un cliché con cualquier otro nombre. ..

Cada compañía afirma estar centrada en el cliente. Solo el fundador de Apple, Steve Jobs, podría decir descaradamente: “La gente no sabe lo que quiere hasta que uno se lo muestra. Por eso nunca confío en la investigación de mercado”. El suyo fue el don de la intuición. La mayoría de las empresas simplemente no pueden lograr esto.

    
        

Si bien AWS sigue la otra parte de la cita de Jobs (“Nuestro trabajo es averiguar qué [customers are] va a querer antes que”), en múltiples conversaciones sobre re: Inventar, fue sorprendente la frecuencia con la que el cliente fue invocado como la fuente de esta o aquella dirección del producto. Desde el escenario principal el miércoles por la mañana, Jassy identificó una variedad de formas en las que AWS se involucra con sus clientes para determinar qué construir, incluida la participación profunda entre los equipos de productos de AWS y los clientes actuales y futuros. Cuando les pregunté a sus clientes y socios si esto era cierto para ellos, invariablemente escuché un rotundo “sí”.

Más interesante fue la postura de AWS hacia los posibles competidores.

Toma Instaclustr, por ejemplo. La compañía ejecuta servicios administrados para Apache Cassandra, Apache Kafka, Elasticsearch y otras tecnologías de código abierto, lo que ayuda a las empresas a funcionar a gran escala. Para dos de esos servicios, AWS es un competidor director, aunque Instaclustr ejecuta estos servicios en AWS. Esto parece una receta para el conflicto, pero cuando hablé con el Director Ejecutivo de Instaclustr, Peter Nichol, me dijo que de los diversos proveedores de la nube, AWS es realmente el más fácil y el mejor para trabajar. En parte, esto se debe a que los procesos y servicios de AWS son mucho más ricos en características y están establecidos, pero también se debe a que AWS se centra en las necesidades de los clientes. Como lo expresó Nichol, los representantes de ventas de AWS no alejarán a los clientes de Instaclustr del servicio Cassandra administrado por la empresa a DynamoDB de AWS. El enfoque está en lo que el cliente necesita, no en lo que el vendedor necesita.

VER: Amazon Web Services: una guía de información privilegiada (PDF gratuito) (TechRepublic)

En otros casos, el cliente puede no saber exactamente qué ella necesita. En una conversación con Herain Oberoi, gerente general de marketing de bases de datos, analíticas y blockchain de AWS, habló sobre cómo se le ocurrió a la compañía sus productos Managed Blockchain y QLDB. Al anunciar los nuevos servicios, Jassy destacó que AWS pasó mucho tiempo tratando de encontrar la señal en todo el ruido de la cadena de bloques, y señaló que “no construimos cosas para la óptica”. El hecho de que haya exageración sobre blockchain no significa que haya una demanda real de los clientes.

Debido a que “los equipos de desarrollo de AWS son muy cercanos a los clientes”, como Oberoi me informó, pudieron sondear la demanda de los clientes (“Queremos blockchain”) para descifrar lo que realmente significaba esa demanda en la práctica. Para algunos, significaba blockchain, pero se manejaba más fácilmente. Entrar en la cadena de bloques administrados. Pero para otros, lo que realmente querían era “una forma de tener una forma transparente y verificable de administrar las transacciones”. No necesitaban blockchain, necesitaban algo más como QLDB, una base de datos interna que AWS decidió externalizar para las necesidades del cliente.

Para el vicepresidente de estrategia en la nube de Capital One, Bernard Golden, uno de los principales puntos de referencia de Re: Invent es la importancia que esta obsesión por el cliente está llevando a AWS a resolver las necesidades empresariales. No es que esto siempre hace amigos de AWS.

No hacer amigos

Dado que la mayoría de las infraestructuras de datos empresariales más populares de hoy en día son de código abierto, tiene sentido que AWS comience a invertir para hacer que cosas como Kafka sean más fáciles para el consumo empresarial. En el apuro por satisfacer las demandas de la empresa, AWS debería dedicar más tiempo a garantizar la salud de las comunidades de código abierto de las que se basa el código.

No, no estoy sugiriendo que AWS deba entregar dinero en efectivo a las compañías de código abierto que han surgido para proporcionar soporte empresarial para cosas como Kafka y MySQL. No es culpa de AWS que estas empresas a menudo esperan monetizar proyectos de código abierto modernos utilizando modelos de ingresos de software anticuados. Tampoco es el trabajo de AWS proporcionarles dinero en efectivo. Cualquier proyecto de código abierto que sea excesivamente dependiente de una sola compañía en lugar de una comunidad variada no debe esperar que AWS o cualquier otra persona los saque de sus malas prácticas de código abierto.

VER: En AWS re: Invent, Amazon obtiene su arma: 'Todo lo que hace el sector tecnológico, podemos hacerlo mejor (ZDNet)

Más bien, AWS debería estar pensando seriamente en cómo reponer comunidades . A largo plazo, esto es en interés propio de AWS. Un servicio de Kafka hoy, por ejemplo, es tan interesante como la evolución del proyecto subyacente. Si esa evolución se atrofia debido a la falta de inversión de la comunidad, AWS no podrá satisfacer las necesidades de los clientes. Y, por lo tanto, AWS debe ir desde el codificador de código abierto más prolífico de la industria y convertirse en el cuidador más cuidadoso de la comunidad de las comunidades de código abierto. (No, esto no satisfará los proyectos de un solo proveedor que realmente no quieren código, ya que esperan ser la única fuente de código dominante para sus proyectos. Pero esos proyectos tienen problemas que AWS no tiene que preocuparse de resolver).

¿Por qué debería importarle AWS? Hortonworks ' Steve Loughran ha resaltado algunas razones sólidas. para la salud del proyecto, lo razona, “pierde [es] en cualquier solución [AWS] que los equipos encuentran, cualquier característica, y [AWS doesn’t] ayuda con la fase de prueba de cualquier lanzamiento para demostrar que funciona en la infraestructura de AWS, Imágenes del SO, etc. ¿Y qué hay de AWS y sus clientes? “Pierden la capacidad de parchear sus propios artefactos, de agregar funciones a [products like] EMR, incluso de depurar fácilmente por qué algo falla”. Como tales, los clientes terminan siendo los conejillos de indias para determinar si los servicios de AWS están a la par con la industria.

Esto no es una gran experiencia para el cliente.

Afortunadamente, hay señales de que esto está comenzando. AWS contrató a Adrian Cockcroft para ayudar a la compañía a tomar en serio el código abierto, y está empezando a mostrar frutos en cosas como Firecracker. Firecracker es un gran ejemplo de la tecnología de fuente abierta de AWS que hará avanzar a la industria en la virtualización, pero es posible que se necesite aún más en términos de código de contribución de AWS a los proyectos que está convirtiendo en servicios para los clientes. Una vez más, esta es la mejor manera para que AWS realmente cumpla con su obsesión centrada en el cliente.

Véase también


Source link

About rasco

Be Happy the future is friendly.

Leave a Reply

Allrights Reserved 2007-2018 - Beone Magazine - powered by rasco