- Autoalojamiento sencillo: diseñado para que la instalación y el mantenimiento requieran el mínimo esfuerzo. La aplicación está hecha para funcionar sin tener que resolver problemas internos complejos.
- Escalabilidad horizontal: con una arquitectura simple pero potente, Lapdev puede escalar desde una sola máquina hasta una flota de servidores, ofreciendo un sistema de gestión de entornos de desarrollo que puede crecer junto con el equipo de desarrolladores.
- Entornos de desarrollo definidos como código: usando la especificación abierta de Devcontainer, es posible definir los entornos de desarrollo como código, lo que permite replicar entornos estandarizados entre distintos desarrolladores para evitar problemas relacionados con el entorno y garantizar una configuración consistente para todos.
- Ahorro de tiempo en el onboarding: al incorporar desarrolladores a un proyecto nuevo, ya no hacen falta horas o días para preparar el entorno en una máquina. Se puede empezar a programar de inmediato.
Funciones planificadas
- Soporte para varios tipos de espacios de trabajo: actualmente Lapdev solo admite espacios de trabajo basados en contenedores, pero esto tiene limitaciones, por ejemplo cuando se quiere ejecutar un clúster de k8s dentro del flujo de desarrollo. El soporte para VM y máquinas bare metal está en la hoja de ruta, y también se planea compatibilidad con distintos sistemas operativos como Windows, Linux y macOS. Esto permitirá a los desarrolladores desarrollar y depurar en la misma máquina local sin necesidad de cambiar de equipo.
Opinión de GN⁺
- Lapdev es una herramienta que permite a los desarrolladores configurar y administrar fácilmente entornos de desarrollo remoto en sus propios servidores o en la nube, y puede aumentar la eficiencia al hacer posible la estandarización del entorno de desarrollo y un onboarding más rápido.
- Este tipo de herramientas puede ser especialmente útil para equipos de desarrollo grandes u organizaciones que manejan varios proyectos al mismo tiempo, ya que ofrece escalabilidad mientras mantiene la consistencia de los entornos de desarrollo.
- Sin embargo, antes de adoptar esta tecnología, puede haber consideraciones relacionadas con seguridad, compatibilidad y soporte, y también se debe tener en cuenta la carga adicional de mantenimiento que puede surgir al usar una solución autoalojada.
- Actualmente existen otras herramientas en el mercado que ofrecen funciones similares, como Remote Development Extensions de Visual Studio Code, y los usuarios deben elegir la herramienta que mejor se adapte a sus necesidades.
- El hecho de que Lapdev tenga planeado soporte para VM y máquinas bare metal puede verse como parte de un esfuerzo por satisfacer necesidades más diversas de entornos de desarrollo, lo que ofrecerá a los desarrolladores un rango más amplio de opciones.
1 comentarios
Opiniones de Hacker News
Se ve muy bien poder usar contenedores de desarrollo (devcontainers) en hardware de servidor local sin pagar una cuota mensual. Hasta ahora he estado usando Docker-compose y el desarrollo remoto por SSH de JetBrains, pero espero que este nuevo enfoque sea mucho mejor.
Me interesan los entornos de desarrollo remotos, pero no me emociona demasiado tener que administrar más software en la nube. Me parece una buena idea usar Skypilot, ya que tiene un plugin para APIs de nube y permite iniciar máquinas de desarrollo sin tener que administrar un clúster de k8s. Me funcionó mejor para levantar un servidor de Jupyter, pero una máquina de desarrollo "completa" parece posible con solo algo de configuración de SSH/VS Code.
Los entornos de desarrollo remotos pueden tener limitaciones para ciertos tipos de desarrollo. Por ejemplo, el desarrollo de apps para iOS y Android puede ser complicado, o en desarrollo de juegos que requiere GPU la descarga de artefactos de compilación puede ser lenta. Me pregunto si hay alguna guía para resolver eso.
Me gustaría saber más sobre estas herramientas. Vi que Coder incluye soporte alfa para
.devcontainer, pero no conozco otras opciones OSS.Con una configuración de Proxmox, puedes clonar una VM/contenedor existente y simplemente apuntar VSCode hacia ahí. ¿Qué agrega realmente esto? No es automatización (en Proxmox puedes automatizar unos cuantos clics), ni gestión de recursos (Proxmox maneja el almacenamiento, etc.). ¿La identidad del desarrollador? Si eso es lo único que hace falta, entonces habría que escribir un script (relativamente simple) para desplegar llaves SSH en el entorno.
Por mi experiencia teniendo que instalar juntos code-server y SSH en una máquina remota, una experiencia donde ambos estén mucho mejor administrados resulta muy interesante.
Otra implementación en este espacio es devpod.sh.
Un consejo de diseño: centrar el texto del botón para que parezca un botón. Si el texto está alineado a la izquierda, puede parecer una etiqueta, así que es un cambio pequeño, pero podría mejorar la conversión.
Entiendo lo que está instalado en el servidor remoto. Pero, ¿esto proporciona un entorno remoto o un entorno local? ¿Y qué significa exactamente "entorno" en este contexto? ¿Es un archivo Docker compose y un
.env? ¿Es el código o la configuración de vim? ¿Es una VM como Vagrant?Actualmente, el principal problema de devcontainers es que al ejecutar apps con GUI de forma remota, la GUI solo se abre en el servidor. Me pregunto si esta solución puede exportar la GUI de forma remota.