Feda /dev/ - No Javascript allowed | Página 1247

Kaledros #37381 Jul '22

#37364 Mala opinión. Muy mala.

En mi último curro a mi jefe se le ocurrió que no íbamos a tener perfiles especializados en nada (arquitecto, devops, analistas, etc), que íbamos a ser todo "perfil senior" y ya iríamos haciendo lo que se necesitara. Con lo que mi jefe no contaba es que vas a seguir teniendo que hacer tareas de arquitectura, de devops y de análisis, pero ahora, en lugar de tener una autoridad especializada en eso vas a tener a un tío que sí, tiene experiencia, pero no la suficiente y no en ese campo. El resultado fue un año dando palos de ciego y probando cosas a ver si funcionaban (spoiler: no funcionaron), rebooteando el proyecto dos veces en ese tiempo y no avanzando nada en absoluto porque ninguno sabía por dónde ir. Aprendimos todos un montón, pero con perfiles especializados hubiesemos tardado un mes en encontrar la solución adecuada que no encontramos en un año.

Moraleja: necesitas perfiles especializados porque siempre hay tareas que los necesitan. No vas a necesitar que un arquitecto se dedique el 100% de su tiempo a tareas de arquitectura, el 90% será programar como los demás, pero es ese 10% el que necesitas que te aporte un tío con expertise.

1 1 respuesta

_gideon #37382 Jul '22

#37381 les transmití mi miedo en la entrevista, porque de primeras me sonaba a eso. Puedo aceptar un equipo sin roles especializados, siempre y cuando haya un referente técnico de cada una de las ramas que supervise el código. Si no, aprendices de todo, maestros de nada, y acaba formándose un sindiós.

Lo que me alucina es que es una empresa bien bien grande, que al parecer está invirtiendo mucho en digitalizarse. Y si empiezan así, mal vamos.

1 respuesta

JuAn4k4 #37383 Jul '22

#37382 Depende, en una startup necesitas gente poco especializada y generalista, tirar millas y hacia adelante el MVP, después, necesitas especialistas para, una vez validado el producto, cree unos cimientos sólidos e ir moviendo hacia allí, y después pasas a adquisición y escalar. Si hace falta especialistas al principio siempre contractors.

2 1 respuesta

aren-pulid0 #37384 Jul '22

Al principio de una carrera (mi caso 2 años de exp), ¿es mejor aprender un poco de todo o especializarte?

¿Con qué se puede ganar más dinero?

2 respuestas

_gideon #37385 Jul '22

#37383 mira, pues ese es un punto de vista interesante. Porque la situación actual de esta empresa es la de sacar adelante ideas no muy concretas, e ir sacando MVP para ver hacia dónde tirar.

Es algo que me suena muy etéreo, si he de ser honesto. Porque me suena muy startupero (un área que desconozco completamente) y muy a que un día nos van a echar a todos a la calle si no se acaba concretando en nada. Y me choca que tengan este enfoque, porque es una empresa bien grande (no tecnológica).

#37384 más que apuntar hacia el dinero, así de primeras, yo apuntaría hacia lo que más te guste. Al final, si eres bueno en algo concreto, el dinero va a venir detrás tarde o temprano.

Optaría por centrar el tiro, y en ser un poco curioso con todo en general.

1 respuesta

eondev #37386 Jul '22 Rawe Ceek

#37384 sigue mis pasos y deja de dar vueltas

desu #37387 Jul '22

#37385 si estas en una startup necesitas a todo un equipo de devops y quien diga que no tiene 0 idea de lo que habla

montar la pipeline de CI/CD, automatizar todo a AWS, configurar tus environments, configurar tus secrets, configurar tus colas... los mayores potenciadores de productividad y que mas te haran avanzar el proyector...

el codigo de negocio como si lo pica el becario en node que da igual como ha dicho juanaka que da igual si es una porqueria

quieres montar un servicio, configura la pipeline, todos los secretos, permisos y roles a aws para cada proceso, automatiza todo para todos tus entornos desacoplando todos los requirimientos anteriores, a;adele la capa de oauth de tu empresa... para leer de una puta SQS o guardar algo a S3. HAHAHA.

luego en empresas grandes como la mia te viene el equipo de seguridad que se dedican a encontrar day zeroes y ya vereis ya como re-useis 1 token en algun entorno de dev o el TTL este configurado asi en lugar de asa, useis push en lugar de poll para propagar esto u lo otro.. no tengais monitoring de ningun tipo y necesiteis logs de X tipo para auditorias y mil polladas XD que esa es otra.

los de seguridad de mi empresa han roto la mitad del stack de Hashicorp, romper muy muy fuerte por eso no lo usamos, y cosas de aws, okta tambien.. XD romper de meterse hasta la DB de okta y tener acceso a los secretos de todos los usuarios.

vamos que una empresa hoy en dia en el cloud te la levantan los devops y un par de ingenieros que sepan lo que estan haciendo a nivel de arquitectura y seguridad.

1 2 respuestas

_gideon #37388 Jul '22

#37387 ¿y qué te parece trabajar en un sitio así? En mi caso, busco un cambio para tocar otras tecnologías y salir de lo que ya controlo. Mi idea es ir a un sitio con un nivel alto y nutrirme de lo que haya.

Ahora mismo estoy en un sitio totalmente opuesto a una startup, en el que podría jubilarme si quisiera y en el que yo soy el nazi que da la matraca con la pureza del código, los patrones bien aplicados y se calienta la cabeza cuando alguien hace una mierda. Como me rodeen de orangutanes no aguanto una semana.

Encima están haciendo incorporaciones a granel, porque la división en España está despegando. Me da muy mala espina lo que os he leído, la verdad.

1 respuesta

GaN2 #37389 Jul '22 Inocente

#37387 O sea que no usais TF que es practicamente el standard hoy en dia para montar entornos cloud porque los de seguridad de tu empresa supuestamente han roto la mitad del stack. Vamos que sois mas listos que empresas tipo Google, Uber, Slack, Twitch, Microsoft, etc. y sabeis algo que el resto del mundo IT no sabe.

1 respuesta

desu #37390 Jul '22

#37388 pues mi equipo y nuestro producto es literalmente como una startup de 5 personas. hacemos lo que nos sale de la polla, hablamos directamente con clientes, ademas del backend tenemos front end propio, con casos de exito, docus tecnicas de todo tipos, tenemos pagina "fake" simulando ser un cliente donde puede probar features, tenemos una pagina de demo donde en tiempo real puedes probar el producto (a la photoshop online), tenemos CLI con pip y docker, multiples SDK mantenidas por nosotros y otras por la comunidad, 100% self on-board y es el producto mas adoptado de la compa;ia. tenemos numeros de trafico publico que movemos que creo que somos top "web" en el mundo. (esto tiene algun matiz porque movemos mas que amazon.com, pero no mas que todo amazon.com .uk .es combinado)

yo siempre he trabajado con startups y cuando me cambie ya lo hice a un sitio donde fuese "similar". hago lo que me sale la polla y punto. y sobre el tipo de equipo pues facil: core o infra. en mi caso termine en core aunque entreviste para todo. si no tuviesemos la infra por detras el dia a dia seria un infierno... ni de puta broma tendrias un producto tan maduro ni los productos mas jovenes podrian avanzar tanr apido... si lo tienes que montar tu tienes que ser un equipo de devops y montarte una plataforma... mantenerlo es un infierno...

si alguien te dice que no tienen equipo de devops porque "you make it you run it" no tienen ni puta idea de lo que es algo bien montado. como el tonto que respondo abajo.

respondiendote busca equipo core o infra. trabaja para Google desarrollando plataforma no para "youtube" "usando" la "plataforma. Siempre lo digo: "hacer libreria" vs "usar libreria". La gente buena "hace". y estaras siempre bien.

#37389 cuando rompes algo lo reportamos y ya esta arreglado. que es TF? TensorFlow XDDDDDDDDDDDD

Te puedo confirmar que rompimos Vault 2018-2019. Y Okta hasta leer su base de datos.

La decision de usar algo a este nivel es a nivel de infra / global. Rompimos Okta pero lo usamos.

Un equipo puede usar lo que queira y por ejemplo yo considero usar Consul. Porque venimos del netflix stack y aun tenemos eureka que de vez en cuando da por culo.

2 respuestas

aren-pulid0 #37391 Jul '22

#37390 tf es terraform

ahora se lleva mucho lo de devsecops

2 respuestas

desu #37392 Jul '22

#37391 de una busqueda veo 120 repos. diria que ninguno es de core ni infra. nosotros usamos ansible. eso es parecido?

no se que tiene por cierto que ver terraform con una decision de infra. tu lo entiendes anto;ito?

decidir usar vault o decidir contratar el pack enterprise de hashicorp que pagaras millones de euros anuales son decisiones de infra.

nse para que ibamos a usar terraform. provisionar el k8s? contribuimos a k8s y tenemos nuestras propias mierdas.

2 respuestas

Wei-Yu #37393 Jul '22

tu equipo montó todo eso y mientras tanto tú intentando meter unit tests para el ioc de spring porque no entiendes cómo funciona

todo en orden

7

aren-pulid0 #37394 Jul '22

#37392 terraform es para declarar la infrastructura como código pero lo bueno es que es multi provider (aws, amazon, gcp).

Ansible no es exactamente lo mismo, es para gestión de servidores, configuración, automatización...

1 respuesta

desu #37395 Jul '22

#37394 no tenemos multiprovider. la politica es aws.

tenemos servicios que eran de ebay que estan el google cloud pero tienen un par de a;os para migrarlos a AWS.

incluso si alguno no se migrase no veo xq ibas a necesitar terraform para esos servicios.

que problema resuelve terraform?

2 respuestas

GaN2 #37396 Jul '22 Inocente

#37390 TF es Terraform como dice #37391 Lo mismo lo que rompio el de seguridad de tu empresa fue la mierda de implantacion que hizo el chimpace de turno en vez de romper el producto como tal.

#37392 Ansible no tiene nada que ver con Terraform. Terraform se usa para provisionar infraestructura en AWS, Azure, GCP o el cloud de turno. De hecho TF tiene soporte para Kubernetes:

https://learn.hashicorp.com/tutorials/terraform/kubernetes-provider

Ansible se usa para gestion de configuracion, automatizacion y despliegues, etc. En teoria puedes provisionar infraestructura en AWS/GCP/Azure via Ansible pero generalmente se suele usar TF para ello porque te da ciertas ventajas que no tienes en Ansible.

1 respuesta

fehnd #37397 Jul '22

#37395 soluciona el problema de no saber ni lo que tienes configurado por hacerlo todo a manopla, al final es tener una declaración de todo lo que tienes montado y como se relaciona, por ejemplo vpcs e instancias

1

MTX_Anubis #37398 Jul '22 :psyduck:

#37395desu:
que problema resuelve terraform?

Te lo acaba de decir, declarar la infraestruactura como código. No tener que ir a la mierda consola de AWS a crear las cosas ni usar su pestoso sdk/cdk ni la basura del cloudformation.

Además de llevar un tracking de los cambios en la infra, ver que se va a cambiar ,etc. etc.

2 1 respuesta

aren-pulid0 #37399 Jul '22

Lo bueno de que la infrastructura como código es que lo puedes meter en un repo en el que las PR las revisen los arquitectos cloud y dejar que los devs monten parte de la infrastructura cloud con supervision jeje. Lo metes en un jenkins o alguna herramienta de automatización y permites que los devs trabajen a su rollo que también es lo que se busca en la filosofía devops

Pasar de mirar un ticket de oye no tengo permisos, oye creame esto... etc... A tener un repo en el que vas revisando prs

Aparte de por supuesto trackeo de cambios etc etc

2 respuestas

desu #37400 Jul '22

#37396GaN2:
Lo mismo lo que rompio el de seguridad de tu empresa fue la mierda de implantacion que hizo el chimpace de turno en vez de romper el producto como tal.

vault hasta la cocina

aun me rio de mitchell hasimoto por discord de zig, luego me pregunto xq no quiere hacer pair conmigo jeje

#37398 #37399 sabeis que podeis tener las configs de cloudformation en github igual y hacer PRs igual no? jeje y si quereis hacer rollback haceis rollback del commit no? trackeo de cambios, ver que se va a cambiar, etc

jeje

sigo sin entender que problema resuelve terraform, que quereis tocar de la infraestrctura exactamente????

1 respuesta

MTX_Anubis #37401 Jul '22 :psyduck:

#37400 si si, tu usa la mierda de cloudformation y dejame utilizar a mi terraform.

1 respuesta

desu #37402 Jul '22

#37401 es que la infraestructura me la pela bastante, para configurar los server groups y demas lo hago a manopla en spinnaker

no veo un caso de uso donde terraform me salve la vida

y de aws ya ni comentar que me suda la polla hacerlo a mano

de nuevo mucho buzz pero no me estais diciendo problemas reales que resuelva terraform. si no tengo multiprovider (ni quiero), no veo ningun problema en a;adir una tabla en dynamo, un rol o configurar un SNS o SQS... que lo haces 1 vez cada 3 meses?

para actualizar el stack usamos sceptre..

1 respuesta

GaN2 #37403 Jul '22 Inocente

#37402 Lo mismo en la Fruteria Maripili en la que trabajas no te soluciona nada, en empresas en las que tienes cientos o miles de recursos/servidores en Azure/AWS/GCP te soluciona la vida porque solo tienes que hacer el codigo y luego creas/modificas/destruyes recursos como si nada. Es mas, si lo tienes montado en condiciones puedes destruir todo y montarlo pulsando un boton a base de TF, Ansible o la herramienta que toque. Todo, absolutamente todo y sin intervencion manual.

El picarse las cosas a mano en AWS/GCP/Azure es tipico de Pajeets. Y Cloudformation es cancer comparado con Terraform.

#37399 Nosotros lo hacemos asi y es como la noche y el dia. Ya no solo porque automatizas la creaccion de todo, simplemente por el mero hecho de quitarme que alguien tenga que hacer toda la configuracion manualmente con la posibilidad de que haya errores.

2 respuestas

aren-pulid0 #37404 Jul '22

#37403 pasame empresa que tiro cv

1

desu #37405 Jul '22

#37403GaN2:
en empresas en las que tienes cientos o miles de recursos/servidores en Azure/AWS/GCP te soluciona la vida porque solo tienes que hacer el codigo y luego creas/modificas/destruyes recursos como si nada

no tienes ni idea de lo que hablas o estas sencillamente trolleando.

si google tiene 5000 equipos de desarrollo, de 500 sub-empresas distintas, yo que trabajo en google/platform/cloud/.../team_2515 que me importa a mi los otros 4999 equipos?

es que en fin, no se porque estas trolleando de esa manera. o no sabes como se gestiona el cloud desde infra. xq estas viendo cosas donde los hay, y te suenan campanas pero a lo lejos. tonto.

#37403GaN2:
con la posibilidad de que haya errores.

es imposible que despliegue un error. tonto. que eres un bocazas.

que tenga que explicar yo estas cosas que ni se lo que es terraform (ni me importa). no dice mucho del nivel devops del hilo. asi os va.

1 respuesta

GaN2 #37406 Jul '22 Inocente

#37405 Porque aunque tengas 5000 equipos de desarrollo de 500 sub-empresas distintas lo que te interesa es mantener unos estandares y herramientas a nivel de empresa. Lo que no tiene sentido es que dentro de la misma empresa crees recursos de una manera dependiendo del departamento, equipo o desarrollador sin seguir unos estandares predefinidos.

A ti te importara un huevo y parte del otro lo que haga el Pajeet de turno del equipo de Machine Learning, a un tio que lleva el soporte del cloud de turno lo que le interesa es que los recursos se creen en ese cloud siguiendo los mismos estandares y no que cada uno usa la nomenclatura que le salga de los cojones, la arquitectura que quiera, etc. Lo vuelto a repetir, para la Fruteria Maripili donde trabajas pues genial que cada equipo haga lo que le salga de los cojones pero para empresas grandes no tiene ningun sentido que cada departamento se monte sus historias sin seguir los estandares que marcan los SAs a nivel de empresa.

Y lo mismo lo puedes aplicar a nivel de administracion de sistema operativo, gestion de containers en el Kubernetes/Docker/Rancher/etc de turno o lo que tu quieras.

P.D: No te enfades.
EDIT: Pero como va a ser imposible que despligues con errores si el trabajo se realiza manualmente? En serio te lees?

3 1 respuesta

desu #37407 Jul '22

#37406 sabes lo q es un test? Tiro sceptre, pasan los tests, se despliega, vuelvo a tirar acceptance tests...

Osea en tu empresa no se puede usar python en un equipo y java en otro. Porque usan standards para el nombre de las variables y funciones distintos HHAHAHAHAHHA

Veus problemas de fperos donde no lls hay. De nuevo dime el poblema real de usar nombres distintos para las colas de SQS i.e... A ver sorprendeme. Si cada equipo tendrá múltiples cuentas de aws para empezar.

2 respuestas

wdaoajw #37408 Jul '22

#37407 no sabes ni por dónde te da el aire al hablar de infra

5 2 respuestas

Kaledros #37409 Jul '22

Lo siento, yo me he quedado atascado en lo de encontrar "day zeroes" y romper "la mitad del stack" de Hashicorp y no salgo del bucle.

2 1 respuesta

JuAn4k4 #37410 Jul '22

Horrorform lo llamamos nosotros a Terraform jaja

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales