¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.dev
Óscar Ferrer y Andrés Navidad 21/06/2021 Cargando comentarios…
Como ya vimos en la primera parte, y como sucede con cualquier tecnología, siempre existen aspectos mejorables o servicios que nos gustaría que funcionasen de otra manera.
En este segundo round seguimos hablando de lo "menos bueno" de Google Cloud, esta vez desde un punto vista más general y de operación. Nos acompañan en este episodio nuestros compañeros de Goodly, Andrés Navidad y Óscar Ferrer.
Esta visión, hasta hace poco, ha tenido una orientación que implicaba querer desarrollar productos como lo hacen desde Google. No hay duda que en Google son expertos haciendo productos digitales, pero la realidad en las empresas es otra. Hay muy pocas al alcance de Google, incluso hay algunas que piensan que no tiene sentido tener ese alcance.
Las empresas cloud native lo tienen muy fácil porque Google ofrece soluciones y servicios que se integran perfectamente unos con otros. Pero si hablamos de una empresa con una experiencia mucho menor, que aún utiliza un legacy, un data center… ahí encontramos fricciones en cuanto a los servicios de Google Cloud.
No poder poner budgets y alertas por proyecto. Solo se puede hacer en la billing account. No tiene mucho sentido, sobre todo para los clientes finales (a diferencia de los partners). Ahí queda camino por recorrer.
En el momento que tenemos que incluir a alguien que no tiene cuenta de Workspace las cosas se complican. Esto se convierte en un quebradero de cabeza para las empresas.
Es algo que suele generar mucho conflicto, sobre todo a nivel seguridad, la pregunta más habitual es qué pasa si la persona que tiene su cuenta asociada se va de la empresa.
Puede ser una ventaja, pero que muchas veces se vuelve en contra. Conseguir tener los permisos necesarios para una funcionalidad lleva bastante tiempo, hasta que somos capaces de tener los permisos correctos. Es complicado si seguimos las políticas, las prácticas de seguridad…
Es cierto que las empresas lo demandan, pero a veces se vuelve complicado. Trabajar en cualquier nube, solicitar los permisos necesarios, suele ser un dolor de cabeza.
Al menos en Node y Python nos encontramos con formas diferentes de hacer las mismas cosas. Por ejemplo, los métodos de autorización que dependiendo del sdk del servicio que sea cambia la manera de pasar las service account o configuraciones. Hace que pierdas tiempo.
Falta una integración más empresarial. Tenemos un dashboard y una página web, pero es una solución arcaica. Podrían tener un sistema integrable con nuestros propios sistemas de monitorización que nos avisasen de que Google está fallando en X servicio o proyecto.
O incluso un aviso de que determinado servicio, que tú estás usando en un proyecto, está dando fallos. Por ejemplo, si en un proyecto usamos GKE, y GKE falla, que recibamos un aviso de que GKE está fallando y debemos tenerlo en cuenta por si lo estamos usando en algún proyecto.
Ayudaría además que ese aviso viniese filtrado por proyecto, por región… Serían mecanismos que darían más seguridad a la hora de usar ciertos servicios.
Si usamos IPs que ya hemos usado, esto se convierte en un problema en los rangos que nos pide (en la distribución de rangos). Es la eterna discusión que se suele dar tanto en los clientes como en las propias empresas. Por ejemplo, para un balanceador interno hace falta un /26 o para un GKE un /23 o para una SQL. Esto genera muchos problemas cuando hablamos de entornos híbridos.
El sistema de compartir, va por roles no por proyectos. La shared vpc se comparten las subnets por usuarios, no por proyecto. Y eso debería de tener más claridad. La shared vpc se comparten las subnets por usuarios, no por proyecto.
Es uno de los últimos grandes productos de Google. Pero tiene una barrera de entrada económica brutal. Lo ideal es que tuviese una “versión reducida”, que nos permitiese incluirla en todas nuestras arquitecturas. El pago por uso sería una buena solución a este problema que nos encontramos con este servicio.
Con este capítulo cerramos la primera temporada de "Cómo conocí a nuestro cloud". Pero puedes escuchar este capítulo y todos los demás en las principales plataformas de podcast: Ivoox, Spotify, YouTube, Google Podcast, Apple Podcast y Amazon Music.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.