Portada
mis comunidades
otras secciones
#1:
#0
El texto completo de la ya conocida como 'API Mandate' ('Orden API') es el siguiente:
Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
Los equipos deben comunicarse entre sí a través de estas interfaces.
No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
Cualquiera que no haga esto será despedido.
El texto completo de la ya conocida como 'API Mandate' ('Orden API') es el siguiente:
Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
Los equipos deben comunicarse entre sí a través de estas interfaces.
No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
Cualquiera que no haga esto será despedido.
#29:
BULO (O al menos, sensacionalista). Qué maldita manía de intentar vendernos a los multimillonarios yankis como revolucionarios de la tecnología e inventores de la rueda. Que si Bill Gates inventó el ratón, que si Steve Jobs inventó Macintosh, que si los yankis derrotaron a los nazis, que si Elon Musk descubrió el litio... Y ahora que Jeff Bezos inventó las APIs.
Esta gente no ha inventado nada ni ha revolucionado nada. Ha comprado la tierra, lo que se ha producido con el trabajo de otros y lo que otros han inventado. Pero lo que nunca podrán comprar es la historia.
Los "profesionales" del dinero sólo saben de eso, dinero. No contribuyen al desarrollo de la tecnología, lo lastran con opas hostiles, patentes, secretos, denuncias... Apoderarse de la tecnología no tiene ningún mérito. Cuando venden que han hecho algo bien, ese algo siempre es idea y fruto del trabajo de otro. Ellos simplemente han puesto un muro para que el resto de la humanidad no pueda usarlas sin pasar por caja.
Esta gente no ha inventado nada ni ha revolucionado nada. Ha comprado la tierra, lo que se ha producido con el trabajo de otros y lo que otros han inventado. Pero lo que nunca podrán comprar es la historia.
Los "profesionales" del dinero sólo saben de eso, dinero. No contribuyen al desarrollo de la tecnología, lo lastran con opas hostiles, patentes, secretos, denuncias... Apoderarse de la tecnología no tiene ningún mérito. Cuando venden que han hecho algo bien, ese algo siempre es idea y fruto del trabajo de otro. Ellos simplemente han puesto un muro para que el resto de la humanidad no pueda usarlas sin pasar por caja.
#6:
Gracias a que dividieron todo Amazon en organizaciones que se comunicaban mediante API les fue posible elegir los servicios más maduros y ofrecerlos al mundo en AWS. No creo que fuera idea de Bezos pero sí que fue una idea cojonuda.
#31:
#10 La historia de la "ceguera" de Blockbuster con Netflix nunca me ha convencido.
Cuando tuvieron esa reunión Netflix aún era un servicio por correo, así que no se les puede achacar que no fuesen capaces de ver el potencial del streaming. Y si los hubieran comprado igual no hubiesen desarrollado el servicio de vídeo bajo demanda y se habrían ido a la mierda junto a Blockbuster.
Cuando tuvieron esa reunión Netflix aún era un servicio por correo, así que no se les puede achacar que no fuesen capaces de ver el potencial del streaming. Y si los hubieran comprado igual no hubiesen desarrollado el servicio de vídeo bajo demanda y se habrían ido a la mierda junto a Blockbuster.
#75:
#1 #52 #57 Pueden parecer obvias, pero por ejemplo Google no tenia una architectura orientada a servicios hasta hace pocos años [1]. Yo trabaje primero en Amazon (retail y AWS) y luego en Google. Amazon es tan buena en ingenieria, pero no hay otra igual en cuanto a capacidad de movilizar la empresa. Cuando yo estaba alli era un culto a Jeff.
Por cierto no fue tanto el email de Jeff como el manifesto "distributed computing manifesto" [2] que escribio Werner Wogels (Amazon CTO) lo que llevo a Amazon a adoptar la arquitectura a servicios. Pero dejo las batallitas para otro dia.
[1] https://www.reddit.com/r/programming/comments/l9ehj/steves_google_platform_rant/
[2] https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
Por cierto no fue tanto el email de Jeff como el manifesto "distributed computing manifesto" [2] que escribio Werner Wogels (Amazon CTO) lo que llevo a Amazon a adoptar la arquitectura a servicios. Pero dejo las batallitas para otro dia.
[1] https://www.reddit.com/r/programming/comments/l9ehj/steves_google_platform_rant/
[2] https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
#7:
¡¡Un CEO que hizo caso a muerte a su CTO!! increible es poco.
#12:
#4 No me parece sencillo en absoluto.
Pasar de un sálvese quien pueda, que era lo aceptado y aprobado a separar administrativamente o burocráticamente en pequeñas unidades lógicas que tenían que tener una interfaz pública es muy complejo.
Les tuvo que sonar a chino y, por eso, la última frase. Quien no lo acepte será despedido. Los trabajadores que pensaran ignorarlo porque "son cosas del jefe loco" deberían ser legión
Ahora , años después, nos parece lo lógico. Claro. Cuando lo vemos sin vicios
Pasar de un sálvese quien pueda, que era lo aceptado y aprobado a separar administrativamente o burocráticamente en pequeñas unidades lógicas que tenían que tener una interfaz pública es muy complejo.
Les tuvo que sonar a chino y, por eso, la última frase. Quien no lo acepte será despedido. Los trabajadores que pensaran ignorarlo porque "son cosas del jefe loco" deberían ser legión
Ahora , años después, nos parece lo lógico. Claro. Cuando lo vemos sin vicios
Comentarios
#40 Que cada edificio tiene su portero, y tú no entregas ni recibes el correo, se lo das y pides a él.
#42
Muy buena
#0
El texto completo de la ya conocida como 'API Mandate' ('Orden API') es el siguiente:
Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
Los equipos deben comunicarse entre sí a través de estas interfaces.
No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
Cualquiera que no haga esto será despedido.
#1 "Cualquiera que no haga esto será despedido"
Buen rollito ante todo
#32 el "calvo de la Loterìa" no hace prisioneros
#32 que no sea exactamente un filántropo me parece de sobra conocido. Él y un par mas, que la gente trata come si fueran los nuevos mesías.
#41 Si, y hasta se está creando mitología. Ahora parecen ser los descubridores ce cierto tipo de programación, en lugar de quedar como los que utilizaban el látigo.
#54 Amazon es el inventor de la nube publica. Yo he trabajado en Google y en Amazon. Y me quedo con Amazon, todo depende del equipo/organizacion donde estes.
#72 Amazon es una cosa, Bezos es otra
#54 Hasta donde tengo entendido, nadie ha dicho que descubrió esas tecnologías, lo que han dicho siempre es que las vió, las disfrutó, y las ordenó.
Que no es lo mismo.
#1 No entiendo una mierda, explicacion para no informaticos.
#40 Hay un señor que sabe exprimir a sus equipos muy bien, sin delojar ser un auténtico hijo puta. El resto es prosa de relleno.
#1 Suena a "ejecuten la orden 66".
#1 Muy interesante. Como cambia la informática. Cosas que parecen obvias a día de hoy antes costaba verlas.
#52 ¿Costaba verlas? La visión venía de antes, lo que cuesta es tirar todo y construir todo nuevo para comprobarlo.
#1 #52 #57 Pueden parecer obvias, pero por ejemplo Google no tenia una architectura orientada a servicios hasta hace pocos años [1]. Yo trabaje primero en Amazon (retail y AWS) y luego en Google. Amazon es tan buena en ingenieria, pero no hay otra igual en cuanto a capacidad de movilizar la empresa. Cuando yo estaba alli era un culto a Jeff.
Por cierto no fue tanto el email de Jeff como el manifesto "distributed computing manifesto" [2] que escribio Werner Wogels (Amazon CTO) lo que llevo a Amazon a adoptar la arquitectura a servicios. Pero dejo las batallitas para otro dia.
[1] https://www.reddit.com/r/programming/comments/l9ehj/steves_google_platform_rant/
[2] https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
#75 PS: porque demonios esta baneado github gist en meneame?
gist.github.com/chitchcock/1281611
#75 No dejes las batallitas para otro dia please.
Yo siempre he pensado que el genio era es compartido entre Bezos y Wogels. Wogels tuvo la vision y Bezos la comprendio y la impulso desde su polemica forma de gestionar.
Personalmente creo que AWS lleva ventaja de años en sus servicios.
Cuantanos mas por favor.
#89 Del S-Team (senior execs) los pondria asi: Jeff Bezos > Jeff Wilke > Werner Vogels > Andy Jassy . Siempre pense que Wilke seria el reemplazo de Jeff. En google cloud no hay nadie del calibre de estos ... pero ni de lejos.
>> Personalmente creo que AWS lleva ventaja de años en sus servicios.
Me duele decirlo pero yo creo Amazon esta perdiendo la batalla de la nube. Si va por delante a nivel de servicios, pero a nivel de SaaS va muy por detras. Amazon tiene que ser mucho mas agresiva a la hora de adquirir empresas. Amazon perdio en tren de comprar Github, Slack, Tableau, Twilio, Snowflake, Databricks, Salesforce y muchas otras. Esas eran compras que yo esperaba. Microsoft y Google lo hacen mucho mejor. MS se gasto 9 mill millones de dolares en 2021 en adquisiciones. What the fuck Andy!
En temas de servicisos hay muchas empresas interesantes para hacer acquihire como Contentful, Algolia, RedisLab, Elastic, datadog, new relic para mejorar mucho la innovacion de AWS en algunos servicios. El estado de AWS OpenSearch (o como se llame esta semana) da mucha pena y es un pilar basico para AWS. Cuando vamos a tener un ElasticSearch serverless en AWS? lo llevo esperando hace 5 años.
Bueno mejor lo dejo que me sube la tension
#89 #104 Al que decidio adquirir Annapurna Labs deberian hacerle un monumento en Amazon.
https://en.wikipedia.org/wiki/Annapurna_Labs
BULO (O al menos, sensacionalista). Qué maldita manía de intentar vendernos a los multimillonarios yankis como revolucionarios de la tecnología e inventores de la rueda. Que si Bill Gates inventó el ratón, que si Steve Jobs inventó Macintosh, que si los yankis derrotaron a los nazis, que si Elon Musk descubrió el litio... Y ahora que Jeff Bezos inventó las APIs.
Esta gente no ha inventado nada ni ha revolucionado nada. Ha comprado la tierra, lo que se ha producido con el trabajo de otros y lo que otros han inventado. Pero lo que nunca podrán comprar es la historia.
Los "profesionales" del dinero sólo saben de eso, dinero. No contribuyen al desarrollo de la tecnología, lo lastran con opas hostiles, patentes, secretos, denuncias... Apoderarse de la tecnología no tiene ningún mérito. Cuando venden que han hecho algo bien, ese algo siempre es idea y fruto del trabajo de otro. Ellos simplemente han puesto un muro para que el resto de la humanidad no pueda usarlas sin pasar por caja.
#29 llegó el marxista al grupo.
#64 ahora es nuestro grupo
#64 Las APIs ya eran un estándar en muchos sitios en el año 2000, eBay se apuntó al carro y publicó la suya en noviembre de ese mismo año. En 2002 cualquiera que supiera juntar las palabras de una revista para programadores sabía que las APIs no eran ya el futuro, sino el presente. Si este señor es un revolucionario, la estanquera de mi barrio fue una visionaria cuando instaló el TPV.
#29 De hecho en la propia noticia aparece:
No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
Joder, HTTP vale que tenga otras utilidades, pero CORBA es también del siglo pasado y está pensado precisamente para eso.
Cuando hablaba de microservicios, pensaba que en 2002 ya habría previsto como funcionarian los contenedores de Docker, Kubernetes y demás...
Eso sí que hubiera tenido mérito.
#73 docker está basado en chroot... Que es de 1982, anterior al propio Linux (que es de 1991)
Disclaimer: Docker usa más cosas y usa tecnologías más modernas, haciéndolo además más seguro y fácil de usar.
Yo es que me descojono ¿Así que antes de microservicios no existía SOA? Al final y al cabo microservicios es SOA llevado al extremo. Ahora resulta que Bezos inventó la rueda #73 confundes un paradigma con las tecnologías, Y cosas como lo que hace dockers o kubernetes ya se hacia antes de manera mas simple. Anda que no se escalaba según se necesitaba levantando diferentes instancias de un proceso.
#86 He puesto Docker/Kubernetes como tecnologías de ejemplo, ya que son las más conocidas. Claro que hay muchas otras que utilizan la misma arquitectura o paradigma como dices.
Si miras en el artículo de la Wikipedia sobre la historia de Microservicios, se empieza a hablar como pronto en 2004, posterior a esto de Bezos.
https://en.wikipedia.org/wiki/Microservices#History
Bezos en aquél entonces hablaba de algo más simple, SOA como dices, que llevaba años siendo utilizado. No hizo ningún cambio de paradigma.
#29 Quién lo inventó y ejecutó? Un cubano?
Qué mendrugos sois a veces
#29 Korea del norte es por
#87 Gracias por tu respuesta, ahora viene tu explicación de por qué necesitas descalificar a los demás para proteger una mentira.
Debajo de la línea, por favor:
____________________________________
#29 Yo siempre he pensado que Edison con la cara de mafioso que tiene no pudo inventar la bombilla, como ponía en los libros de texto y en muchas aminaciones, cuando yo era pequeño. Probablemente el pringao de su empresa que la desarrolló, estará en cualquier vertedero
Gracias a que dividieron todo Amazon en organizaciones que se comunicaban mediante API les fue posible elegir los servicios más maduros y ofrecerlos al mundo en AWS. No creo que fuera idea de Bezos pero sí que fue una idea cojonuda.
#6 La gracia (y dificultad) del CEO es encontrar el "oro" entre toda la paja que le llega a su escritorio.
El caso contrario es cuando el CEO de Blockbuster rechazó la compra de Netflix.
#10 La historia de la "ceguera" de Blockbuster con Netflix nunca me ha convencido.
Cuando tuvieron esa reunión Netflix aún era un servicio por correo, así que no se les puede achacar que no fuesen capaces de ver el potencial del streaming. Y si los hubieran comprado igual no hubiesen desarrollado el servicio de vídeo bajo demanda y se habrían ido a la mierda junto a Blockbuster.
#31 Exacto. Además conocemos este caso porque Netflix lo petó. ¿Cuántos posibles Netflix se han quedado en el camino y los que tuvieron la opción de comprarlos habrán respirado tranquilos al ver de la que se libraron?
#56 Tumblr por ejemplo
#31 Aún así pudieron haberlo comprado cuando empezaron la idea (bill gates style comprando compentencia)
#10 … cuando Netflix era un servicio de alquiler de DVDs y VHS por correo postal.
Que es como decir que qué poca vision no comprar nintendo cuando eran una compañía de cartas.
#6 .. Seguro que no, pero dar la orden de cambiar simultáneamente la filosofía de todos los equipos, solo puede venir del jefazo máximo.
¡¡Un CEO que hizo caso a muerte a su CTO!! increible es poco.
#7 ¿Cuándo has visto que un director ignore a uno de sus responsables?
#13 debe estar en una empresa donde el ceo y el cto son familia directa…
#22 ¿Y el cio, cmo y todas las demás ces?
#13 ¿No sé, una docena de veces o dos docenas?
#13 Por lo pronto en todas las empresas donde el CTO se larga por "diferencias creativas".
#7 será en las empresas en las que CEO o CTO son como el vestido de la mona. En cualquier empresa seria lo que diga el CTO con respecto a la arquitectura va a misa
#25 No necesariamente. Ese cambio debió costar una buena pasta. ¿Para qué cambiar algo que ya funcionaba? ¿Para qué cambiar el paradigma y quemar dinero cuando podría aplicarse en desarrollar nuevas funcionalidades de la plataforma que ya tenían en marcha?
El CTO podría decidir que hacer, pero el CEO y el CFO debían entenderlo o no se habrían lanzado a por ello con ese entusiasmo
#69 ¿Para qué cambiar algo que ya funcionaba?
Pues para evitar que deje de funcionar. Es un tema de escalabilidad.
#96 Que sí, si lo sé y estoy completamente deacuerdo, pero ahora vete a explicarle al financiero y al boss que lo que has hecho hasta ese momento "no vale" (muy entre comillas) y que hay que gastarse la pasta en refactorizarlo.
#97 Ah, ahi es en donde esta la experiencia
.
"Hemos detectado una muy buena oportunidad de BPO. Con una inversion moderada en un proyecto de 6 meses calculamos un ahorro de x% en los proximos 3-5 años".
#4 No me parece sencillo en absoluto.
Pasar de un sálvese quien pueda, que era lo aceptado y aprobado a separar administrativamente o burocráticamente en pequeñas unidades lógicas que tenían que tener una interfaz pública es muy complejo.
Les tuvo que sonar a chino y, por eso, la última frase. Quien no lo acepte será despedido. Los trabajadores que pensaran ignorarlo porque "son cosas del jefe loco" deberían ser legión
Ahora , años después, nos parece lo lógico. Claro. Cuando lo vemos sin vicios
#12 los kernels basados en microservicios hace tiempo que existían como concepto y con implementación, el diseño estaba totalmente justificable.
Desde estos ingenieros y sus equipos han elevado el mismo concepto a protocolos de red, puesto que no tenían kernels ejecutando software, sino servers conectados.
Sin conocer los pasos intermedios toda tecnología parece mágica (sin querer parafrasear a nadie)
#17 en el software industrial era muy común.
#38 qnx creo recordar?
#17 Más allá del Kernel ya existía hacía mucho la arquitectura orientada a componentes, y estos podían ser distribuidos. Corba, DCOM, por citar algunos de los más veteranos. Aquí la gracia está en hacer que toda tu empresa abrace esa tecnología, esa es la gracia del asunto.
De hecho lo que vino después, la estandarización de HTTP y JSON como protocolo de facto, si que fue revolucionario, comparado con los tochos de XML que se solían intercambiar anteriormente
CC/ 12 #4
#39 Y Docker, no te olvides de Docker, que para mi punto de vista es una de las mayores revoluciones de los últimos años en la construcción de software.
#67 De hecho todo esto de los microservicios sin Docker y sin más tarde los sistemas de orquestación de contenedores como kubernetes o marathon hubiera sido algo sumamente complicado de controlar. Todo lo que funciona se apoya en otras cosas
#17 De hecho las primeras noticias de programación por microservicios que conocía, allá a principios de 2000, venían por herencia del kernel de unix
#48 el hurd
#4 #12 Recuerda bastante la filosofía d.comandos de Unix. Aunque prohíbe todo lo que usa para compartir datos.
#12 yo creo que la sencillez y genialidad provienen del concepto y no tanto de su puesta en práctica.
#12 la última frase es para vencer el "yo siempre lo he hecho de aquella manera y funciona, no cambio"
La resistencia al cambio es enrome, y más si planteas algo tan innovador.
#28 Pues por eso, no es simple ni sencillo
#47 sí, el tema de las APIs es sencillo. Lo que pasa es que los humanos no lo somos.
Ya sabes, PEBKAC
#50
#28 No hay frase más peligrosa que "Nosotros siempre lo hemos hecho así".
#12 aún hay empresas y, peor aún, desarrolladores, que hacen "microservicios" que usan las mismas bases de datos para varios servicios en vez de APIs...
Ya me he tenido que pelear con varios en la nueva empresa en la que estoy trabajando porque están convencidos que esa es la mejor opción... Y son todos gente joven y la empresa tiene 3 años...
PS. El CTO brilla por su ausencia... O incompetencia
#12
Tienes todas la razon.
Yo he visto caer a gente muy gorda por tratar de imponer un vision asi y los de abajo ir disimulando y pasando hasta que al final el proyecto fracasa. Creo con franqueza que esas cosas hay que imponerlas con firmeza porque al principio son:
- dificiles de entender
- dificiles de afrontar
- te obligan a salir de la comoda rutina.
Sera un miserable chacal en todo lo demas, pero en esto , acerto de pleno.
#5 No tanto, se han creado micro servicios por encima de nuestras posibilidades.
#8 Cuanta razon llevas...yo ahora mismo estoy pasando 3 monolitos a una masa de microservicios y me esta entrando mucho miedo
#8 no
No se entiende el artículo, vaya divulgación de chichinabo con definiciones y explicaciones vagas que solo entienden los que no necesitan que se lo expliquen.
"Cualquiera que no haga esto será despedido". Creo que esta fue la clave.
Lo que pasó a continuación te sorprenderá
#15 A mi siempre me sorprende. Gasto un ratón al mes de tantos clicks
#60 ¿Verdad? A mí me pasa lo mismo
Qué interesante, gracias #0
#2 Gracias. Me alegro que te haya gustado. Pienso igualmente que marcó un antes y un después.
#3 es que, como las grandes ideas, es de una sencillez maravillosa.
Pasar de monolítico a APIs ha cambiado mi forma de concebir el software de una manera brutal.
#16 El monolito va a volver. El 99.9% de los proyectos/empresas no son Amazon ni tienen sus necesidades.
#19 No va a volver, nunca se fue, eso no quita que se puedan hacer las cosas de manera diferente cuando la situación lo requiera
#19 como dice #24 nunca se ha ido. Una buena parte de los microservicios que se hacen no son más que "monolitos distribuidos" que tienen que desplegarse juntos, y si uno falla dejan de funcionar los demás
#34 pero esa no es la idea
#34 Claro, pero eso es porque a la hora de implementar microservicios no se es purista con su implementación y luego sale un híbrido raro de cojones que ni es un microservicio ni nada.
Pasar de monolítico a distribuido es un coste enorme y no sólo en lo económico si no en la manera de enfocar la arquitectura.
Hay gente que no está preparado para el cambio (tristemente...)
#16 #19 #24 es verdad que de un tiempo a esta parte parece que la tendencia es a pensar microservicios=guay monolito=kk, pero la verdad es que…Depende.
Este video lo explica muy bien
Y si estais en el sector IT y no conoceis el canal de ese tio os lo recomiendo encarecidamente.
#19 la cantidad de proyectos de empresas que son, de hecho, Amazon (o mejor dicho, desplegados en AWS) esta bastante, pero bastante por encima del 0,1%
.
Creo que andan más o menos por un 33% de todas las aplicaciones cloud desplegadas con ellos.
#27 Sí, si yo tengo ahí mi blog, pero no necesito 20 microservicios. No soy Amazon/Google/Facebook/Uber/Twitter que son los que crean ciertas tendencias innecesarias en ocasiones.
#43 hombre ya, para un blog personal con 500 visitas mensuales. Pues te cojes un EC2 e instalas WordPress y la base de datos manualmente.
El tema está cuando ese mismo blog pertenece a un cliente con miles de visitas mensuales y que no puede permitirse caídas. Ahí ya te tienes que preocupar de desacoplar la arquitectura en varios trozos, aka microservicios.
Para un WordPress, entiendo algo así:
- Un RDS para la base de datos aurora mysql.
- Un fargate con la imagen de WordPress. Al menos 2 instancias corriendo.
- Un EFS con los ficheros adjuntos del blog.
- Un load balancer correctamente configurado.
- Opcionalmente, un cloudfront enfrente de esto. Ahí ya depende de cuanto ancho de banda gastas y de donde viene el tráfico.
Aunque no hayas escrito nada de código, esto ya es una arquitectura de microservicios. Todos los componentes están debidamente desacoplados entre sí.
#43 Como dice #61, si que los necesitas, solo que son transparentes y no los tienes que usar tu. Es decir, el mejor microservicio es el que nunca notas . ¿Tu comentario? Microservicios. ¿Tu correo electronico? Microservicios. ¿Cualquier app de tu telefono? Lo mismo.
#19
No vuelve ni de coña.
#19 ¿Eres Kubrick?
#16 Para mi empresa ha sido un game changer de cojones.
Y, no me quiero echar flores, pero empecé a usar esa metodología casi sin leer nada, por pura necesidad, nosotros somos todos programadores pero no sabemos combinar el color de la camisa con los pantalones así que me busqué a un colega de la universidad que trabaja en Londres y era muy bueno en diseño de webs y APP para minimizar la dependencia de él diseñé una serie de APIs que no hacían nada más que llamar a una stored procedure y devolver el resultado. De esa forma el 80% de los cambios y debugs de las APP los podía resolver yo desde SQL.
Ya ha crecido tanto la cosa que tenemos dos programadores de web services, pero el diseño gráfico lo seguimos subcontratando. Que mal gusto tenemos todos
Nadie como genbeta para conocer la API de Amazon. La usan para cascarte anuncios de artículos con enlaces de afiliación en cada post.
no seria en todo caso una tendencia del sector en esa época? lo que si me parece chocante es que se pusieran las pilas y lo tuvieran todo muy claro
Lo único que no me cuadra es que se filtrara en Google+, ¿Quién usaba eso?
#30 El exempleado de Amazon que trabajaba en Google cuando publicó el mensaje
Que genios!!! Bezos inventó las API, Jobs el teléfono y Musk el espacio.
Grandes tiempos los que vivimos!!!
No sé quien escribió el correo, y tengo claro que no inventaron la arquitectura, pero sí fueron quienes marcaron un cambio de tendencia que aún hoy está siendo adoptada por muchos de sus competidores. Ole, Ole y Ole.
Mi tesoro... Gollum!!!!
Ah, la muerte de Obidos y el nacimiento de Gurupa
2002, buenos ciegos me pegué ese año, y la picha escocida. Entonces no entendí American Beauty.