Categoría: Windows

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Posted on by ecardenas

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

¡Regresando! Con Docker y algunos tips (1)

Posted on by ecardenas

Bueno, sí que he estado ausente, pero ha sido por buenas razones, en este lapso me he puesto a experimentar con las versiones finales de .Net Core, la cual ha tenido ciertos cambios con respecto a lo que vimos hace un tiempo, pero lo más importante es que pude participar en el último Docker Con Recap, gracias a la gentil invitación de los amigos de Docker Lima, y como no podía ser de otra manera pude exponer sobre Despliegue de Aplicaciones .Net Core con Docker.

img_2332

Lo interesante de la experiencia fue todo el proceso de ir recopilando información, probar lo que funcionaba y lo que no, en algunos momentos parecía muy difícil, pero felizmente todo salió bien, la demo funciono, así que de lo que se trata ahora es compartir esta experiencia para que podamos replicarla con nuestros proyectos .net Core, así que de eso hablaremos en las próximas entregas, pero antes cubriremos algunos tips que serán de suma utilidad para el trabajo futuro.

Un ajuste final para Docker para Windows

Docker, si… ya hemos hablado de ello, la posibilidad de generar contenedores que fácilmente sean ejecutables en cualquier anfitrión, no pienso dar la enésima explicación al respecto pero si recapitular lo que nosotros como desarrolladores de Windows hemos visto todo este proceso para terminar con un tip imprescindible para nuestro trabajo.

Si pues cuando nos aproximamos a Docker, ya sabíamos que los contenedores solo corrían en máquinas Linux (Windows está próximo a implementar el modelo, pero esa es otra historia) así que parecía lógico que para poder correr Docker en nuestros equipos se haría necesario instalar una Máquina Virtual Linux, el problema es que el año pasado instalar Docker para Windows implicaba si o si utilizar VirtualBox como gestor de virtualización, por lo que si ya uno tenía ciertas máquinas virtuales creadas usando Hyper-V habría que aparcarlas y no usarlas, pues como es sabido un SO Windows solo permite UN hipervisor, así que pues temporalmente desactive mi Hyper-V (en Windows 8, entonces), reactive una antigua instalación de VirtualBox e instale la versión de Docker para Windows respectiva, en corto… no funciono bien, el uso del famoso boot2docker no era nada sencillo, aparte de lento, así que deje suspendido el tema por un tiempo no sin antes haberme configurado una MV en Azure realizando satisfactoriamente un despliegue de .Net Core sobre Docker… pero ya volveremos sobre eso en otra ocasión.

El caso es que casi en paralelo con mi invitación a participar en el Docker Con Recap, leí que la nueva versión de Docker para Windows había dejado de estar en beta, permitiendo que ahora el sistema se valga del hipervisor nativo del SO o sea Hyper-V, así que lo probé y… totalmente sencillo, el instalador creo transparentemente una MV en mi Hyper-V y seguidamente pude usar la consola de Powershell para poder empezar a ejecutar comandos, siendo que ahí me tope con un pequeño problema que es la razón de este post, cuando quise ejecutar (run) algún contenedor de los libremente disponibles obtuve un error indicando que no podía conectarse, investigando pude darme cuenta que solo tenía que indicarle a Docker para Windows que haga uso de un DNS explícito, así:

clipboard01

Nada complicado, por algún momento pensé que tenía que configurar las conexiones de red vinculadas a la máquina virtual “mini…” pero no.. solo era eso, así que nada, ya puedo ejecutar el “hola mundo” y algunas cositas más con una sencillez y transparencia que no fue posible en las épocas de boot2docker.
clipboard02

Con esto el camino empieza…

¿Windows 7 sin Internet Explorer? (2): Consecuencias

Posted on by ecardenas

Al parecer la decisión de Microsoft de no incluir a Internet Explorer en la distribución de Windows 7 para la Unión Europea, traerá unas consecuencias indeseadas como el hecho de que las nuevas PCs que vengan con Windows Vista no podrán ser actualizadas al nuevo sistema operativo, debiendo hacerse en consecuencia una instalación limpia, con los consiguientes inconvenientes que eso puede ocasionar al usuario inexperto (perder su configuración, tener que instalar todo de nuevo, perder sus datos por si se le ocurre borrar todo por error).

La razón para esta situación es que como Internet Explorer está profundamente integrado con Vista no es posible realizar una actualización que a la vez elimine a Internet Explorer.

Lo curioso del caso es que había estado viendo en la página de Dell, planes que ofrecían el upgrade futuro a Windows 7 si uno compraba ahora un equipo con Windows Vista (y mas extrañamente aun, se ofrece previo pago la opción de hacer el downgrade a XP), como comentaba el articulo los OEMs están planeando soluciones que pasan por entregar brochures para hacer el upgrade, pero personalmente todo esto lo veo como una contradicción a algo que analizaba en Febrero a propósito de una recomendación de Microsoft de hacer ya el upgrade de XP a Vista puesto que eso facilitaría la adopción de Windows 7, con esto un administrador de sistemas en Europa la tendrá complicado, pues hacer un upgrade de XP a Vista, para luego hacer una instalación limpia (desde 0) de Windows 7, como que no tiene mucho sentido.

Esto de la integración del browser con el sistema operativo si que trae cola, por lo que no puedo sino coincidir con lo que dice Daniel Rodríguez Herrera en esta nota: “Al margen de las consecuencias económicas que pueda tener este movimiento (el anuncio del Google Chrome OS) para Microsoft, a corto plazo sí debería servirle de argumento frente a las autoridades antimonopolio, por más que éstas no atiendan a razones sino a conveniencias de los competidores de la empresa fundada por Bill Gates. Si Google anuncia un nuevo sistema operativo que consiste en poco más que en un navegador, ¿cómo es que Bruselas obliga a Microsoft a no atar Windows con Internet Explorer? ¿Tiene acaso bula Google, que va a tener el navegador tan integrado con el sistema operativo que incluso se llamarán igual?”. Efectivamente Microsoft tendría toda la razón para pedir que a Google se le mida con el mismo baremo que se le ha medido en los últimos años, invocar que Google no está ofreciendo libertad al usuario de su sistema operativo para que elija su browser, etc etc…

Al final creo que lo que falta es nuevamente un debate técnico sobre lo que debe corresponder a la arquitectura de un sistema operativo, y que es lo que debería ser periférico, y por mucho que se hayan agregado librerías comunes en versiones pasadas de Windows, o que ahora Google quiera que el browser sea una capa mas por encima del kernel (¡de Linux!!), conceptualmente no tendría que ser así, ahora que comercialmente.. el papel aguanta todo. Pero aun así no me imagino que los futuros estudiantes de los cursos de teoría de Sistemas Operativos, tengan que (en adición a procesos de memoria y gestión de archivos) estudiar la arquitectura de un browser, ni a Tanenbaum actualizando sus libros para incluir a los browsers.

¿Hay margen para un jugador más?

Posted on by ecardenas

AutoCAD, Gimp, Photoshop, Visual Studio, Premiere, Office … ¿qué tienen en común?, que son aplicaciones que requieren el acceso a un API medianamente rica para asi poder aprovechar major los recursos de la computadora, y de esta manera poder lograr su cometido para brindar soluciones avanzadas al usuario final.

¿A cuento de que viene esto? A propósito del anuncio de los planes de Google de desarrollar su propio Sistema Operativo, su enfoque es claro “We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.” Interesante, ofrece una interfaz de usuario ligera para que el uso de las aplicaciones Web sea más óptimo.

Con todo esto, quisiera plantear mi opinión que seguro puede chocar dentro del ánimo actual de considerar que todo lo que produce Google está bien, cuando como con todo debería ser mirado con la misma lupa con que se miraba a Microsoft en los 90s, pero vayamos por el principio, ¿qué es lo que creemos necesario que debería tener un Sistema Operativo para que funcione en el mercado actual y futuro?

  • Una arquitectura robusta y segura
  • Una interfaz de usuario con capacidad de atractivo a los usuarios que facilite su transición (desde Windows)
  • Un conjunto de aplicaciones finales que sean usadas por el público (como las que menciono al principio).
  • Una potente maquinaria de marketing (que ojo, no es lo mismo que publicidad).

Con respecto al punto final quiero detenerme un poco, sin haber llegado a utilizar dichos sistemas, creo que parte de las razones que motivaron el buen pie con que salieron iPhone y Android, se debe a la capacidad de generar una buena oferta de aplicaciones de terceros de una manera muy rápida, razones técnicas o buen mecanismo de convencimiento a los desarrolladores, lo ignoro, pero es algo que no debemos dejar de tener en cuenta, en ese sentido tanto Linux como Windows cuentan con un buen legado de aplicaciones que han ido evolucionando a lo largo de los años.

Rescatemos otros dos detalles del documento de lanzamiento: la primera versión estará disponible para netbooks(ojo a esto de si ¿Las netbooks son una basura?), y que se basara en el kernel de Linux. De ahí se puede inferir que en esta primera iteración del producto no habrá una gran exigencia de máquina, por lo que aplicaciones de alto rendimiento como el AutoCAD podrían quedar descartadas, y por otro lado que habría un mecanismo para poder valerse de todo el parque de aplicaciones existente para Linux. Entonces, tenemos claro que conseguir que se desarrollen aplicaciones para una nueva plataforma es parte del proceso de marketing, asi que podemos dar por descontado de que la maquinaria de Google trabajara duro en ese sentido, la pregunta seria ¿Qué clase de aplicaciones?.

Hasta ahí se podría ver que hay cierto margen de suponer que esta propuesta podría cumplir con los requisitos comentados anteriormente, pero leamos este otro párrafo: “The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies.”, de Nuevo tenemos a la recurrente propuesta de la Web como plataforma (algo de lo que ya comente a proposito del lanzamiento del browser Chrome), siendo así creo que es legitimo preguntarse:

  • ¿Cuál es el rol que piensa Google que jugarían las aplicaciones “tradicionales” dentro de su esquema?
  • ¿Qué tan rápido reaccionara el conjunto de fabricantes de software “no web” a fin de soportar el nuevo sistema operativo?
  • ¿Sera viable técnicamente el hacer esa clase de desarrollos?
  • ¿Lograra Chrome OS la adaptación masiva (por el usuario no tecnológico) que no logro Linux?

Enrique Dans dice en Expansion : «No es Google, sino el paso del tiempo, el que ataca a Microsoft, que no se ha dado cuenta de la evolución de la Red. La época de un sistema operativo grande que se vende en una caja y cuesta 200 euros ha pasado, pero Windows 7 sigue la misma línea. Microsoft ve el ordenador como el centro de la experiencia del usuario, mientras Google lo sitúa en Internet», y es cierto que se podría presumir de que es la diferencia entre paradigmas, pero veamos lo de otra manera: Microsoft ha hecho grandes movimientos para colocar su tecnología de servidores (base para la generación de contenidos y servicios en Internet) en una posición solida en el mercado (eso es algo que es poco evidente), por otro lado Google ha dado el paso de proveedor de servicios a desarrollador de sistemas operativos primero Android (que reconozcámoslo, ha logrado generar mas momentum que las sucesivas iteraciones de Windows Mobile) y ahora Chrome OS.

Entonces hay algo que Microsoft tiene y que Google quiere (una cuota en el mercado de los Sistemas Operativos), pero como apuntaban en Expansión el detalle está en que esa cuota de mercado arrebatada a Windows implica menos licencias de Office vendidas(el cual tampoco ha dejado de evolucionar hacia la Web), puesto que la intención de Google es que la experiencia básica de productividad del usuario pase por la nube (que es donde están las vacas lecheras de Google), pero ¿todo todo es posible de ser manipulado a través de internet? (*).

Si asumimos plenamente la idea de Google de que se necesita efectivamente algo diferente para una era basada en la Web, pues si, cobra sentido su apuesta de estructurar el kernel de esa manera, pero la realidad es algo mas complicada y aun necesitamos la computadora para hacer manipulación de imagen y video (que no es lo mismo que ver fotos y videos) y compilar nuestros programas, por lo que creo que la web aun no está preparada tecnológicamente para ser la plataforma de desarrollo de todas las aplicaciones que vayamos a necesitar, probablemente lo esté en el futuro, y tal vez así se pueda entender un poco mejor la apuesta de Google de poner un primer pie en este terreno.

Al profesor Dans le parecía lógico y razonable esta clase de apuesta de Google desde el principio, y si, si uno veía siguiendo la evolución del mercado eso iba a caer por su propio peso, pero más que saber cuál será el próximo movimiento de Google, en este instante toca plantearse cual sería el escenario luego del lanzamiento de este SO (el cual requiere bastante alianzas de fabricantes de hardware para arrancar con buen pie), por lo que me atrevería a afirmar que estamos viendo el surgimiento de un nuevo actor en el mercado, que muy pronto hará pelea a las diversas distros de Linux (las cuales no tienen algo que Google si tiene: la Web), pero que aún resta por medir si ese mordisco a la torta repercutirá lo suficiente como para debilitar las finanzas de Microsoft, lo que es cierto es que en Redmond no están durmiendo ni nada por el estilo, sino veamos la fuerza con la que ha entrado Bing, el cual como ya opine en su momento espero que le vaya mejor que a Cuil, justamente por la necesidad de que haya competencia en el mercado de búsquedas.

(*) El lector desprevenido puede creer que me resisto al cambio y a la viabilidad del desarrollo de aplicaciones Web, pues no, ya que la mayor parte de las aplicaciones que he desarrollado han sido de tipo Web, pero también se que muchas veces se tomo la decisión de hacer un desarrollo para Web a pesar de la mayor complejidad que implicaba, siendo que usando “clientes ricos” se podría haber logrado una mayor productividad y experiencia de uso, es esta experiencia la que me permite ser un poco escéptico por naturaleza, de ahí mi lema de que “si tienes un martillo cualquier cosa te parece un clavo” y veo que muchos por ahí solo tienen martillos sin mirar mas allá en el espectro de herramientas posibles.