Full transcript
0:00Estos días he estado navegando bastante
0:01en medium y he estado viendo que hay
0:03bastantes artículos interesantes en
0:04cuanto a arquitectura y diseño de
0:06proyectos y también en cuanto a código.
0:08El día de hoy les quiero compartir uno
0:09que se llama la arquitectura de una
0:11startup moderna y es para aquellas
0:12personas que si bien no están creando
0:14una startup están iniciando algún
0:16proyecto. Obviamente también entre
0:17ustedes puede haber alguien que esté
0:18creando su propia startup, pero la idea
0:21de este artículo es que justamente saber
0:22qué utilizar o qué consideraciones
0:24tener. Es un artículo bastante simple de
0:26poder entender, pero justamente vamos a
0:28poder ir ahondando en temas que por lo
0:30general casi no tiene nadie en mente y
0:32cuando escucha de un startup todo el
0:34mundo piensa que es algo que ya lo
0:35tienen bien definido y no, esto puede
0:37ser algo muy simple como algo bastante
0:38complejo. Entonces en este video vamos a
0:40ver de qué habla el artículo.
0:42Coder, antes de empezar, si quieres
0:44desplegar una web full stack que está
0:46desarrollada con Note, Python, Go o
0:48incluso elixir más una base de datos y
0:51todo un precio muy accesible, debes
0:53conocer Cote. Esta es una plataforma que
0:55te permite subir tus proyectos web de
0:56forma muy simple y a un buen precio.
0:58Usarlo es muy fácil, solo conectas tu
1:00repo de GitHub o Gitlab, eliges tu
1:02proyecto y en segundos tu aplicación
1:04está en línea con una URL pública para
1:06usarse. Además, la plataforma te permite
1:08hacer lo esencial como tener dominios
1:09personalizados, https automático,
1:12soporte para web sockets y http2, lo
1:15logs en tiempo real, variables de
1:16entorno y soporte 247. y en cuanto a
1:19precio son casi imbatibles, ofreciéndote
1:21base de datos postre SQL o may SQL desde
1:23$1 al mes y servidores backend desde $3
1:26al mes. Eso significa que con $4 al mes
1:28ya puedes tener un backend funcionando
1:30en producción. Y si quieres probarlo
1:32antes, también tienes un trial gratuito
1:34de 7 días en donde puedes subir
1:35cualquier tipo de proyecto y esta
1:37plataforma es ideal para esos proyectos
1:39pequeños, MVPs o clientes con bajo
1:41presupuesto, haciéndolo una opción
1:43rápida, simple y económica. Así que para
1:46saber más de Cynote, te dejo un enlace
1:47en la descripción. Muy bien, el artículo
1:49empieza de la siguiente forma. Primero
1:51tenemos esta imagen que nos da un
1:52resumen acerca de qué es lo que van a
1:54estar desarrollando. En sí, este es
1:56bastante común estos días, pero aún así
1:58este gráfico tiene demasiada
1:59complejidad, principalmente por el tema
2:01de cubernetes que se va a repetir
2:02bastante en este video. Pero bueno, para
2:04darles un resumen, esta aplicación es
2:05prácticamente una aplicación móvil hecha
2:07en flutter que se comunica con una nube
2:10de ABS con una API gateway de ABS. es
2:12código de backend que está servido en
2:15microservicios encima de un cluster de
2:16cubernetes y utiliza Python Terrafone
2:19como herramienta de despliegue y otros
2:21servicios adicionales para poder crear
2:22un API, además de también tener algunos
2:24servicios de análisis o monitorización.
2:27Y en cuanto a la base de datos, pues ahí
2:28pueden ver un posres que es típico para
2:30tener una base de datos relacional.
2:31Ridis como base de datos, no SQL,
2:34típicamente para guardar datos en
2:35memoria caché y en media utiliza S3 que
2:37es para guardar archivos o simplemente
2:39servirlos a través de una CDN. Fuera de
2:41esto, obviamente también utilizan
2:42servicios externos, principalmente para
2:44procesar pagos, enviar SMS o correos,
2:46aunque de por sí también tiene algunos
2:48de estos, así que es bastante
2:50interesante por qué utilizan otros. Pero
2:51en fin, este artículo no es
2:53relativamente nuevo, de hecho es
2:54bastante antiguo, es el 5 de noviembre
2:55del 2022, pero la idea de lo que se
2:57menciona aquí, hay muchas cosas que aún
2:59siguen igual. Por ejemplo, la primer
3:00pregunta es saber qué tecnología o stack
3:03utilizar. Esto es principalmente porque
3:05si ustedes están diseñando algún tipo de
3:06proyecto o sistema, es importante que
3:08escojan las herramientas que les va a
3:10ayudar a poder añadir más
3:11características a futuro. Es decir, es
3:13como crear una deuda técnica. Ustedes
3:15pueden tener algo muy fácil de utilizar
3:17estos días, pero si van a estar
3:18añadiendo más cosas o saben que la
3:20aplicación o el proyecto va a añadir más
3:22cosas, es importante que escojan una
3:23herramienta que les permita poder
3:24escalar en algún momento. El tema está
3:26en no escoger herramientas que se van a
3:28implementar después de mucho tiempo. Es
3:30decir, si ustedes están creando un
3:31proyecto y por ejemplo buscan
3:32rendimiento en algún momento, pues
3:34obviamente la idea sería utilizar
3:35lenguajes que tienen contacto con nivel
3:38de sistemas, seasmadas ras y ese estilo,
3:40pero obviamente eso es mucho más
3:41complicado, entonces no vale la pena
3:43tratar de utilizar herramientas que a
3:45futuro vamos a necesitar cuando justo
3:46ahora ni siquiera pasamos la barrera del
3:48prototipo o el MVP del proyecto. Lo
3:50ideal sería que escojan herramientas que
3:52ustedes se sientan cómodos y que pueden
3:53llevarles a crear algo práctico y ya
3:55luego a futuro van a poder reemplazarlas
3:56o extenderlas. Lo otro es que también
3:58menciona que típicamente salen nuevas
4:00herramientas, nuevos frameworks,
4:01bibliotecas y así. Y no es importante
4:03escoger las nuevas. Yo sé que muchos de
4:05los que están empezando a crear
4:07softwares a service o MVPs utilizan base
4:09de datos que recién está surgiendo o
4:10así, pero en realidad lo ideal sería que
4:12escojan algo que ustedes dominen y algo
4:14muy popular. Y ya luego a partir de allí
4:15si ustedes quieren y ya conocen muy bien
4:17cómo funciona su proyecto, pueden añadir
4:19algo que realmente necesiten y no
4:21simplemente porque está utilizándose
4:23mucho estos días o todo el mundo está
4:24hablando de eso. Y algo también a
4:25considerar de que mencion este artículo
4:27es algo relacionado con el proceso de
4:29poder añadir más cambios a un proyecto,
4:31principalmente basados en cambios en
4:32Git. Para darles una idea, cuando se
4:34hacen cambios en Git, hay varias formas
4:35de poder distribuir los cambios. Es
4:37decir, cuando trabajas siendo una sola
4:38persona, es bastante fácil. Tú puedes
4:40añadir tus cambios y estos se van
4:41apilando uno debajo del otro. Pero
4:42cuando son distintas personas trabajando
4:44en el mismo proyecto, hay metodologías.
4:46Esas metodologías básicamente indican
4:48cómo puedes hacer un branch por aparte o
4:51quizás todos trabajamos en el máster o
4:52quizás simplemente hacemos branch por
4:55cada característica y vamos haciendo
4:56pool request. Bueno, de hecho de eso se
4:58trata estas ideas, por ejemplo, Trump
5:00based development es desarrollar todo en
5:02el master. El git h flow es
5:03prácticamente tener todos los branch
5:05divididos por pers o pull request y a
5:08partir de allí pues se va añadiendo
5:09dentro del proyecto. Obviamente esto
5:11llea más trabajo y hasta puede ser más
5:12complicado, pero esto depende de cómo es
5:14que se va a trabajar a lo largo del
5:15proyecto. Lo más común es utilizar eh
5:18los pull request. Entonces es una idea
5:20bastante fácil que ustedes vayan por
5:21esa. Y bueno, esto de aquí que les
5:23menciono tiene relación con dos partes.
5:24La primera es el CCD o el continuous
5:27integration continu deployment, que son
5:28herramientas que cuando ustedes hacen un
5:29comit y lo envían quizás a un entorno,
5:31puede ser producción o pruebas, pues lo
5:34que hacen es que se disparan
5:35automáticamente. Es decir, ustedes van a
5:37tener que esperar a que los cambios se
5:38apliquen y esto dependiendo de la
5:39herramienta o la configuración de la
5:41nube puede tomar más o menos tiempo.
5:43Pero yo he visto proyectos que pueden
5:44tomar alrededor de 30 minutos como
5:45menciona aquí, y esto es real. Ustedes
5:47pueden subir algún tipo de cambio y
5:49tienen que esperar a que esto se
5:50ejecute. Obviamente si están revisando,
5:52pues esto les va a tomar mucho tiempo.
5:54Entonces es ideal que esta forma de
5:55añadir cambios se considera desde el
5:57inicio para evitar este tipo de esperas
5:58cuando se desarrolla. Por ejemplo,
6:00combinar todos los cambios al final de
6:02todos los PRs y ya con eso pues
6:04solamente esperamos un solo cambio donde
6:06están todos y no tenemos que estar
6:08esperando cada 30 minutos por cada
6:09cambio pequeño. Lo otro también
6:10relacionado con eso es algo también
6:12llamado el time to market versus el SLX.
6:15El time to market habla básicamente de
6:16cuando nosotros hacemos despliegue qué
6:18tan rápido queremos que se apliquen al
6:19proyecto ya en ejecución. Es decir,
6:21puede que haya un proyecto que ya está
6:22siendo utilizado por usuarios, por
6:24personas, y si ustedes van a estar
6:25enfocándose en lanzar cambios
6:26constantemente, probablemente van a
6:28priorizar que los comics sean
6:30individuales para que a medida que van
6:32trabajando, pues estos se vayan viendo
6:33en la aplicación real. Por otro lado,
6:35eso es contrario a lo que es el SLX, que
6:37le llaman SLX porque eso es un abreviado
6:39de service level agreement o service
6:42level objective o service Level
6:44Indicator. Prácticamente estos tres
6:46indican lo mismo. Es decir, si ustedes
6:48hacen cambios bastante grandes en su
6:50proyecto, es probable que esto los hagan
6:51cada cierto tiempo y su proyecto sea
6:53estable. Pero si ustedes hacen cambios
6:54continuos, es posible que se encuentren
6:56con más y más bugs a medida que van
6:58añadiendo cambios. Entonces, siempre es
7:00escoger uno u otro. Por lo general
7:01depende del tipo de proyecto, pero si su
7:03aplicación está empezando es muy
7:05importante quizás que hagan el time to
7:06market, que es el tratar de añadir
7:08cambios constantemente. Ahora, aquí nos
7:09da un planteamiento y es justamente
7:11cuántos desarrollaría en un proyecto.
7:12Ahora, mucho más abajo también nos dice,
7:14"Okay, vamos a ver qué es lo que
7:15realmente tiene la mano, porque
7:17anteriormente solamente nos da como unos
7:18ejemplos de lo que se debería
7:19considerar, pero bueno, aquí coloca un
7:21caso. Por ejemplo, supongamos que
7:22tenemos menos de 12 desarrolladores, es
7:23un proyecto completamente nuevo y
7:25nosotros podemos escoger prácticamente
7:26las tecnologías de todo el ecosistema,
7:28es decir, backing y frontend." Bueno,
7:29aquí justamente menciona lo que les
7:31digo, utilizar GitHub con una estrategia
7:34de pull request y poder ir lanzando
7:36tickets que se pueden entregar desde un
7:37a 3 días. Para aquellos que no no han
7:39trabajado alguna vez con algún sistema
7:41de tickets, prácticamente a medida que
7:42el proyecto va avanzando y el cliente lo
7:44va revisando o otro desarrollador lo va
7:45revisando, típicamente va lanzando más
7:47tareas y más tareas y estas se tienen
7:49que ir integrando en algún tiempo. Y
7:50bueno, otra cosa que también menciona es
7:51la tentativa de crear algo llamado
7:53microservicios. Yo sé que la gran
7:54mayoría que ya conoce algo probablemente
7:56he escuchado de temas como
7:57microservicios, microfrontends y cosas
7:59así. Yo sé que todo el mundo quiere
8:01utilizar lo mejor de lo mejor en su
8:02proyecto, pero el tema está en que a
8:04veces eso puede ser muy complicado y
8:05para un proyecto pequeño o un
8:07planteamiento de un proyecto que recién
8:09va a ser un MVP puede ser realmente algo
8:11que puede perjudicar el proyecto o puede
8:12ser que nunca despegue. La razón de
8:14utilizar microservicios es típicamente
8:15cuando tienen muchos desarrolladores y
8:17muchas áreas y en realidad están bien
8:19definidas, entonces ya como que pueden
8:20ir dividiendo el trabajo. Pero si
8:22ustedes son desarrolladores que recién
8:23están empezando o el proyecto realmente
8:25tiene unas características que aún no
8:27están bien definidas, no se sabe qué es
8:28lo que se va a crear o al menos se tiene
8:29una noción, lo mejor sería crear un
8:31monolito al inicio y ya luego cuando el
8:32proyecto vaya creciendo pueden ir
8:34desacoplándolo y eso les va a generar un
8:35microservicio. Y de hecho aquí en este
8:37proyecto él plantea estas
8:39características. Por ejemplo, tiene una
8:41API core, es decir, un monolito. Luego
8:43tiene una API simplemente para búsquedas
8:45y recomendaciones. Y también tiene al
8:47parecer algún tipo de funcionalidad que
8:48se ejecuta dependiendo de trabajos
8:50temporales, es decir, quizás
8:51notificaciones, envíos de correos y así.
8:53Pero bueno, para dar un resumen, aquí
8:54muestra una imagen que es bastante
8:55descriptiva. Prácticamente son
8:57aplicaciones móviles, la principal o las
8:59características principales serían la
9:00API. Y bueno, el backen por lo general
9:02tendría algún tipo de comunicación con
9:04algún tipo de sistema externo que pueda
9:05delegar tareas e digamos agrupadas. Los
9:09bat jobs básicamente hablan de poder
9:11tener grupos de tareas que pueden tomar
9:13mucho tiempo, entonces en lugar de
9:14procesarlas conjuntamente se van
9:15procesando por partes y obviamente a
9:17veces puede ir combinado con algo que se
9:18llaman message que es otro sistema que
9:20las va apilando, es decir, va
9:22ejecutándola paso a paso. Bueno,
9:23típicamente esto está relacionado con
9:26servicios de notificaciones o servicios
9:28de envío de correos o SMS porque a
9:30medida que los usuarios van obteniendo
9:32los resultados de sus procesos o tareas,
9:34pues van recibiendo notificaciones, SMS
9:36y así. Y bueno, algo muy importante y
9:37que así estoy de acuerdo es que se
9:39utilice lo que se conoce y no tanto lo
9:41que puede ser lo más moderno. Por
9:43ejemplo, en esos años se hablaba
9:44bastante utilizar Go y Rust. Estos días
9:46creo que ya hay un poco más de simpleza
9:48por el tema de IA, pero en ese tiempo,
9:51en el 2022, todavía se hablaba bastante
9:52de utilizar este tipo de lenguaje como
9:54backen. Es decir, obviamente lo pueden
9:55utilizar, pero estos días es mucho más
9:57fácil si ustedes van por un lenguaje que
9:58es mucho más popular, más simple, como
10:00puede ser un Python, un S con
10:02JavaScript. Y ya luego ustedes pueden ir
10:04reemplazando las características que
10:05toman mucho más consumo de recursos
10:07utilizando un lenguaje que realmente
10:09tiene un mejor rendimiento. En cuanto a
10:10las aplicaciones móviles también lo
10:11mismo. En lugar de estar desarrollando
10:13un proyecto nativo para iOS y Android,
10:15pues por lo general lo que podrían hacer
10:17es simplemente tener una sola base de
10:18código y a partir de allí poder generar
10:20ambas aplicaciones. Aquí entran el tema
10:22de frameworks al estilo React Native o
10:24Flatter. En lo personal, yo utilizo
10:26bastante React Native y en la agencia en
10:29la que trabajo también eh se utiliza
10:30bastante React Native y para la mayoría
10:32de proyectos funciona bastante bien. Eh,
10:34obviamente si ustedes están
10:35desarrollando algo muy personalizado que
10:37requiere muchos recursos y probablemente
10:39quieren que luzca como la propia
10:41interfaz de Android o la propia interfaz
10:43de iOS, probablemente van a ir por
10:44nativo, pero eso genera mucho más
10:46costos, se necesita más personas que
10:47trabajen en cada entorno, las entregas
10:49se pueden desincronizar, es decir, una
10:51aplicación puede estar más actualizada
10:52que la otra. Entonces, para evitar eso,
10:54estos días eh lo que yo hago es utilizar
10:56React Native, aunque de nuevo, Flyer
10:57también es otra buena opción. Y bueno,
10:59en secciones más abajo, pues habla lo
11:00mismo de lo que les hemos mostrado en el
11:02gráfico, es decir, eh los servicios que
11:04se están utilizando, las API, pero lo
11:05más importante aquí es cuando ya entra
11:07en la parte de la nube, es decir, cuando
11:09ya habla del despliegue. De hecho, aquí
11:10para resumirlo está utilizando AWS como
11:13nube principal y yo sé que muchos de
11:15ustedes pues prefieren utilizar algún
11:16tipo de nube mucho más fácil como puede
11:19ser Verel, Railway, Heroku y demás. De
11:22hecho, yo también los utilizo, pero el
11:23tema está en que cuando ejecuten un
11:24sistema que es para un startup, por lo
11:26general esta va a requerir más y más
11:28características a medida que va
11:29funcionando. Para que tengan una idea,
11:30la diferencia de una startup con un
11:32proyecto que puede ser de una sola
11:35persona y es como un SAS, la diferencia
11:37donde Star es que realmente tiene algo
11:38de inversión. Entonces, como tiene
11:40inversión, se puede pagar personas, se
11:41puede tener acceso a una nube y allí es
11:43donde ya se trata de tener una
11:45infraestructura que pueda escalar. En
11:46cambio, una idea como de un SAS o puede
11:49ser un proyecto pequeño, por lo general
11:50no sabes si va a funcionar. Entonces, no
11:52te conviene generar una arquitectura
11:53grande con gastos grandes cuando en
11:55realidad no sabes si va a continuar.
11:57Entonces, la idea de los starers es
11:59utilizar algún tipo de nube que les
12:00permita poder escalar con más servicios.
12:02Y AWS sí permite eso. AWS tiene algunos
12:04servicios simples como puede ser Amplify
12:07o te permite ejecutar funciones lambda o
12:09tener tu propi con alguna base de datos
12:11allí. Pero obviamente si vas a estar
12:12creciéndola eventualmente vas a ingresar
12:14Docker, vas a añadir cluster, vas a
12:17querer escalarlo de forma automática.
12:18Entonces por lo general vas a necesitar
12:20más servicios y como no vas a querer
12:21moverte la nube estas nubes son muy
12:23grandes. Es una de las razones por las
12:25que muchos startups los utilizan. Casi
12:26la mayoría de servicios que va a
12:28necesitar tu startup ya lo ofrecen.
12:29Entonces simplemente es conectar algo
12:31nuevo, pagar algo más y ya estaría.
12:33Ahora, la gran mayoría que utiliza WS o
12:35está empezando a utilizar WS utiliza la
12:37interfaz gráfica y estos días en
12:39realidad hay otras opciones y es la
12:41forma de crearlo con código. Es decir,
12:43así como vamos dando clicks en AWS y
12:45vamos creando servicios y
12:47configuraciones eh de forma manual,
12:49también se puede hacer de forma
12:50automática utilizando un archivo de
12:51configuración. Hay un proyecto que se
12:53llama Terraform, que yo ya les he
12:54explicado y le voy a dejar en la
12:55descripción el enlace al otro video,
12:56pero prácticamente Terraform es una
12:58herramienta que utilizando un archivo de
12:59configuración va a crear toda la base de
13:01datos. Yo sé que esto puede sonar mucho
13:02más complicado y de hecho lo es.
13:04Eventualmente pueden llegar a tener un
13:06proyecto que utiliza muchas herramientas
13:08y al final está encima de una nube muy
13:09grande, pero inicialmente no tiene que
13:11ser tan complejo. Es decir, aquí por
13:13ejemplo algo que menciona también es
13:14utilizar Secret Management, que son otro
13:16servicio que es para guardar básicamente
13:18sus variables de entorno. As, de hecho,
13:20tiene un servicio llamado AWC Secret
13:22Manager y es bastante bueno. El único
13:24tema está en que, claro, si ustedes
13:25están empezando, probablemente van a
13:27tener que añadir otro servicio más y
13:28otro más a medida que van creciendo. De
13:31hecho, aquí entra la parte donde digamos
13:32que es la más criticada del artículo,
13:34porque menciona el utilizar cubernetes.
13:36Y bueno, para aquellos que no sepan qué
13:37es cubernetes, es prácticamente una
13:38herramienta de orquestración. Es decir,
13:40cuando nosotros tenemos un contenedor de
13:42Docker, por lo general vamos a querer
13:43aplicarlo a medida que crece un proyecto
13:45con más usuarios. Eso obviamente
13:47funciona, de hecho esa una herramienta
13:49bastante popular en la nube. El tema
13:50está en que es bastante compleja y
13:52añadirla en un proyecto que está
13:53empezando en un startup es bastante raro
13:55de ver. De hecho, estás añadiendo tanta
13:56complejidad y estás enfocando tanto en
13:58la arquitectura que estás creando algo
14:00que probablemente no sabes si en algún
14:01momento va a escalar. Obviamente todo el
14:03mundo espera que su proyecto le vaya
14:04bien, pero es posible que estos nunca lo
14:05lleguen a utilizar, digamos, en su mayor
14:08esplendor. Entonces, lo ideal sería que
14:09empiecen con algo más simple. Y de
14:11hecho, también lo menciona aquí. Por
14:12ejemplo, aquí sería mucho más fácil
14:14hacer un push de Docker a un Elastic
14:16Container Registry, que es básicamente
14:18un lugar donde en tú puedes guardar los
14:19contenedores y luego desde allí se
14:21pueden leer desde otro servicio de AS
14:23como puede ser el Lasting Container
14:25Service, por ejemplo, y allí se puede
14:26desplegar rápidamente utilizando
14:28servicio como Fargate. Entonces, para
14:29darles una idea, es algo muy similar a
14:31lo que hacen con Vercell. En lugar de
14:33estar creando todo un cluster de
14:34cubernetes, pues pueden utilizar algún
14:36tipo de esos servicios ya autoalojados o
14:38autoadministrados de ACS. Y es mucho más
14:40fácil tenerlos así porque obviamente
14:42cuando el startar empieza lo principal
14:44no es tener una arquitectura gigante
14:45para manejar una enorme cantidad de
14:47usuarios, sino lo ideal sería lanzar
14:48cambios lo antes posible para que la
14:50aplicación pueda llegar a ser usada. El
14:52objetivo es muy simple, de hecho cuando
14:53se empieza, no se requiere tener el
14:55proyecto funcional si en el 100% por así
14:57decirlo, no que no sea óptimo o que no
14:59sea extremadamente veloz, sino lo que se
15:01quiere es que se realmente resuelva un
15:02problema. Entonces, de nada no sirve
15:04tener una arquitectura gigante cuando el
15:06problema principal aún no ha sido
15:07resuelto. Lo ideal sería que empiecen
15:09con algo simple y ya a medida que va
15:11creciendo, pues ya lo puedan luego
15:13contenerizar. Cuando ya estén en ese
15:14estado, probablemente ya haya más
15:16personas en su empresa o la startup
15:18quizás ya tenga o hasta una serie B. Por
15:20ejemplo, el comentario más popular de
15:21este artículo es que muchas startups
15:22empiezan con un monolito y no cambian a
15:24microservicio ya hasta cuando tienen una
15:26serie B. Para aquellos que no saben que
15:27es una serie B, esto es prácticamente
15:29hablar del financiamiento de una
15:30startup. Por ejemplo, cuando alguien
15:31tiene la idea de crear algún proyecto,
15:33él puede recibir una financiación
15:34inicial que se le conoce como semilla.
15:36Eso es simplemente para que desarrolles
15:37la idea y la puedas mostrar. Luego viene
15:39la serie A en donde puedes tener un
15:41producto que ya lo pueden utilizar los
15:43clientes, es decir, ya hay personas
15:44descargándolo, utilizándolo, pero no son
15:46muchas, pero ya da una idea de que tu
15:47proyecto sí está funcionando. Entonces,
15:49lo que lo siguiente que te pueden dar
15:50tus inversores es la serie B, que esa
15:52donde probablemente ya te permitan
15:53escalar ese proyecto y probablemente vas
15:55a tener mucho dinero para poder
15:57contratar más gente, aumentar recursos y
16:00básicamente poder hacer crecer tu
16:01proyecto. Y bueno, ya casi finalizando,
16:03hay una sección que se llama Pro versus
16:05Staging, que es algo muy importante y
16:07que de hecho se hace en cualquier tipo
16:09de startup, que también es muy útil y es
16:10que cuando ustedes tienen un proyecto
16:11que ya las personas están utilizándolo,
16:13por lo general van a querer separar los
16:15datos de prueba de los datos reales. Es
16:17decir, hay aplicaciones que por lo
16:19general hay personas que tienden a
16:21registrar datos que son sensibles, es
16:23decir, que pueden ser balances, pueden
16:25ser información personal, pueden ser
16:27datos de algún tipo de operación y
16:29obviamente esos datos ustedes pueden
16:31tratarlos, pero lo ideal es que creen un
16:32entorno de sting. Esto de hecho es
16:34bastante común y se llama entornos de
16:35desarrollo. Ustedes van a tener, por
16:37ejemplo, un entorno de producción donde
16:38están los datos de verdad, la base de
16:40datos de verdad, luego un entorno de
16:41stag donde es una copia de la base de
16:43datos de verdad y ustedes trabajarían en
16:44staging. De hecho, para darles un
16:45resumen, aquí también nos da una imagen
16:47que también está relacionada con eso y
16:49principalmente menciona que tiene tres
16:51entornos. Eh, un entorno de testing, que
16:53es algo también bastante común, un
16:54entorno de sting, que es la copia de
16:56producción y el entorno live como le
16:57dice, que vendría a ser la rama de
16:59verdad, es decir, donde están los
17:00usuarios de verdad, aquí están los
17:01desarrollos trabajando y aquí estarían
17:03los testers. Y bueno, lo debajo ya es
17:05todo lo que les he comentado. Y bueno,
17:06adicionalmente a esto, aquí pueden ver
17:08que también añade servicios de monitoreo
17:10como pueden ser Grafana o Prometeos. Y
17:12hay servicios de alertas solamente para
17:14darles una idea, cuando se crea un
17:16proyecto, típicamente ustedes obviamente
17:18quieren utilizar lo mejor de lo mejor y
17:20tratar de utilizar lo que escala más, lo
17:22que es más rápido y demás. Pero lo ideal
17:24en un startup o en un proyecto también
17:26que puede ser personal es tratar de
17:28generar la idea lo antes posible porque
17:29puede ser que haya más personas que
17:31también tengan tu misma idea y ellos
17:33planteen una solución mucho mejor a lo
17:34que tú estás haciendo. Entonces, algo
17:36muy importante con las startups es que
17:38jueguen contra el tiempo. Entonces, es
17:40por eso que se enfocan más en captar
17:42usuarios y tener las características lo
17:44antes posible que en tratar de hacer la
17:45arquitectura perfecta. Es algo muy
17:47común, de hecho, y es lo ideal, porque
17:49si ustedes están tratando de lanzar un
17:51proyecto, primero quieres que usen tu
17:53proyecto, que lo conozcan y ya a partir
17:55de allí si tienes ingresos, tienes
17:56usuarios que están dispuestos a pagar
17:58por tu proyecto, es probable que lo
17:59puedas escalar. Entonces, la idea con
18:01este artículo, al menos la gran parte o
18:03la mitad, al menos digamos que tiene
18:05algunos puntos bastante interesantes o
18:06que funcionan. Lo que sí está de más es
18:09añadir algún tipo de complejidad grande
18:11como puede ser cubernet. Y de hecho en
18:12los comentarios son las críticas más
18:14común que tiene este artículo y es que
18:16justamente el empezar con un cláster de
18:18cubernetes para un proio que es pequeño
18:20es demasiado realmente. En fin, si
18:22ustedes tienen una idea y van por allí,
18:24pues nosotros también desarrollamos
18:25proyectos para startups y en lo personal
18:27hacemos un enfoque que es algo similar,
18:29es decir, no utilizamos cláser de
18:30cubernetes la primera, pero a medida que
18:32vas creciendo los servicios que utilizas
18:34en la nube los puedes ir cambiando. Así
18:36que es muy importante que el diseño o la
18:38arquitectura del proyecto, digamos que
18:39considera la mayor cantidad de
18:41operaciones o funcionalidades que va a
18:43tener antes de que sea ejecutado o antes
18:45de que sea escrito en código. Pero
18:46bueno, al menos espero que con esto
18:47tengan una idea y si ustedes pensaban
18:49crear algo muy complejo con un montón de
18:51servicios, vayan por lo simple y lo
18:53común y ya luego pueden ir
18:54reemplazándolo. Eso ha sido todo por el
18:56video del día de hoy. Nos vemos en un
18:57siguiente ejemplo. Eso ha sido todo por
18:59el video del día de hoy. Si tienes dudas
19:00puedes dejarla en los comentarios o en
19:02la descripción dejo un enlace para que
19:03te puedas unir a la comunidad de Discord
19:05en donde encontrarás a otros
19:07desarrolladores o si en caso el enlace
19:08está caído, puedes ir a fast.df/discord
19:11para acceder más rápidamente. Dejo mi
19:13Twitter donde típicamente comparto
19:14algunos recursos interesantes de
19:16desarrollo y programación en general, mi
19:17Instagram donde comparto algunas
19:19noticias cortas todos los días, el
19:20TikTok donde comparto vídeos cortos e
19:22informativos y mi canal principal en
19:23donde comparto opiniones y noticias de
19:25tendencias nuevas. Además, también dejo
19:27mi web en donde puedes reservar
19:28asesorías personalizadas.
19:30[Música]