Blog de Fernando Machado Piriz

Artículos sobre arquitectura corporativa y temas relacionados

Road to the Cloud: Montevideo Estrategia de negocios y networking para ISVs

leave a comment »

image

El miércoles 10 de diciembre de este 2014, de 16:00 a 19:30, Microsoft organiza un evento para compartir con sus pares en la industria que han utilizado los beneficios de la nube para construir negocios exitosos. Comparta acerca de las mejores prácticas y lecciones aprendidas, y conozca las oportunidades desde el punto de vista del nuevo modelo de negocios.

Más información y registro aquí.

Written by fernandomachadopiriz

24/11/2014 at 13:18

Publicado en Anuncios, Azure

Toda empresa es una empresa de software, y toda empresa de software puede ser un proveedor de servicios

leave a comment »

El software está en todos lados. Excepto tal vez en los negocios como los carritos de chorizos de calle, todos los negocios funcionan en base a software. Y el carrito de chorizos es una excepción si y sólo si no acepta pagos con tarjeta de crédito, o no utiliza algún servicio en línea para pedir las materias primas con las que prepara después los chorizos. Al fin y al cabo, cada empresa es una empresa de software, ya sea que sólo consuma software, o que desarrolle y consuma software a la vez.

Para aquellas empresas que hacen desarrollo de software en la propia empresa y luego usan ese software para gestionar su negocio, incluso si es sólo una parte del total de software que utilizan, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado en algunas circunstancias, como lo veremos en un minuto.

Y para aquellas empresas cuyo negocio es el desarrollo de software para que otras empresas o individuos consuman, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado tampoco.

Por tradicional ciclo de vida de desarrollo de software me refiero al proceso que crea un producto de software al final. No me importa si se trata de desarrollo en cascada o ágil, lo único que me importa es que un producto de software es creado como resultado de ese proceso. Tiene las siguientes características:

  • Muchas características. La diferenciación de los productos se basa en tener tantas características como sea posible para un público tan amplio como sea posible. Los productos raramente están dirigidos a funciones o necesidades específicas del cliente.
  • MTTF o tiempo medio entre fallas. Al igual que con los productos manufacturados tradicionales, su objetivo principal es el tiempo medio entre fallas: los productos son mejores si tienen pocas fallas.
  • Cadencia de actualización lenta. Las actualizaciones de productos de software son relativamente poco comunes; pueden ser a través de parches para corregir errores, a través de paquetes de servicio para agregar nueva funcionalidad, o por medio de versiones completamente nuevas. El tiempo de desarrollo de productos de software suele ser largo, seguido por período de garantía de mantenimiento, y luego de un descanso antes de empezar todo de nuevo.
  • Hábitos de consumo desconocidos. Una vez que los productos son liberados, es difícil saber cómo son consumidos por los usuarios, y tomar decisiones en base a los patrones de uso.
  • Dentro del calendario, dentro del presupuesto. La prioridad más importante es liberar productos a tiempo y dentro del presupuesto.

Además, como ocurre con los productos fabricados tradicionales, la confiabilidad es percibida desde la perspectiva de cada unidad individual. Proporcionar confiabilidad requiere control de calidad dentro del proceso de producción. Cuando los usuarios experimentan problemas con los productos, por lo general están dispuestos a esperar hasta el horario de oficina para reportar su problema. Un problema raramente impacta más de una persona a la vez. Y por lo general está claro para los usuarios cuando los problemas se deben a problemas en el producto de software, en lugar de problemas en el entorno en el que el software está ejecutando.

Pero cualquiera de estos negocios podría verse afectados por la transformación actual de las demandas de software:

  • Su empresa desarrolla una aplicación de software para móviles, puede ser una aplicación de línea de negocio en el mundo de las empresas, o puede ser otra aplicación de software de propósito específico del mercado de aplicaciones en el mundo de los consumidores. En el segundo caso, la mayoría de estas aplicaciones por lo menos almacena algunos datos o hace algún tipo de procesamiento en un servidor remoto, lo que las pone en el mismo grupo que las que están en el primer caso: aplicaciones móviles que consumen servicios remotos.
  • Su empresa hace negocio electrónico con otras empresas, puede ser exponiendo los procesos internos a través de software donde otros pueden participar, o utilizando aplicaciones de software para el intercambio de información con el fin de completar una transacción. De una forma u otra están proporcionando servicios basados en software, o consumiéndolos; probablemente ambos.

¿Notaron la palabra software al principio de las dos frases anteriores y la palabra servicio al final? No es casualidad –yo lo escribí de esa manera- pero eso es lo que estamos viendo y vamos a ver en un futuro próximo: aplicaciones de software móviles que consumen algún tipo de servicio remoto y servicios basados en software siendo expuestos para que otros puedan consumirlos.

Si siente que cualquiera de las dos categorías antes mencionadas son aplicables a su empresa, ya sea creando software para su propio consumo, o si está en el negocios de desarrollo de software para que otros utilicen, y todavía está desarrollando software como productos, ¿adivine qué? Usted no está desarrollando software, usted está proporcionando servicios. Los llamo proveedores de servicios basados en software. Y eso es una cuestión completamente diferente, ¿quiere saber por qué? Veamos:

  • Confiabilidad y agilidad en vez de más características. La diferenciación de los servicios se basa en las capacidades de alta confiabilidad que se ajustan a un conjunto específico de necesidades del mercado. Los servicios más eficaces y efectivos ponen la confiabilidad y la agilidad por encima de la candiad de características.
  • MTTR o tiempo medio de resolución. Al igual que con los servicios públicos tradicionales, su foco está en el tiempo medio de recuperación: las interrupciones van a ocurrir, por lo que los servicios son mejores cuando más rápido estén funcionando de nuevo.
  • Actualizaciones continuas, desarrollo continuo. Las actualizaciones de software son continuas; podrían libear nuevas funciones o nuevas versiones enteras con mucha frecuencia, y corregir los errores todos los días. El desarrollo de software para servicios suele ser continuo; puede ser que haya ciclos de liberación, pero por lo general esos ciclos son muy cortos.
  • Patrones detallados de uso. Por lo general es posible recopilar cantidades enormes y muy precisas de datos sobre el uso del servicio, lo que permite tomar mejores decisiones.
  • Siempre funcionando, a costos adecuados. La prioridad más importante es tener el servicio en funcionamiento, manteniendo el costo de operación apropiado.

Además, como ocurre con los servicios públicos tradicionales, la confiabilidad es una función de todo el sistema. Proporcionar confiabilidad requiere monitoreo proactivo en tiempo real del comportamiento de cada componente del sistema. Cuando los usuarios sufren interrupciones del servicio, el impacto es mucho más amplio, un problema impactar una amplia gama de clientes. La respuesta no puede esperar al horario de oficina. El soporte tiene que estar disponible 24x7x365. Los usuarios no se preocupan dónde están los problemas cuando se producen cortes en el servicio. Puede ser que estén en el software en el que se basada el servicio, o en el centro de datos, o en la red, o en cualquiera de los componentes dependientes.

¿Su fábrica de software no puede seguir el ritmo de las solicitudes de cambio y no tiene suficiente agilidad para acompañar a transformación de su negocio? ¿Tiene requisitos contradictorios de diferentes unidades de negocio o diferentes grupos de usuarios? ¿No puede encontrar una buena manera de organizar sus equipos de operaciones de software y de desarrollo de software? ¿Quiere saber una cosa?… su fábrica de software probablemente no está organizada como tiene que ser organizado un proveedor de servicios.

Las fábricas de software se organizan en torno a los productos de software, mientras que los proveedores de servicios se organizan en torno a los servicios. ¿Y todavía se preguntan por su fábrica no funciona?

La organización de los equipos alrededor de los productos significa dos cosas. Uno: que muy probablemente tenga un equipo para cada producto, algunos de los miembros podrán ser compartidos entre los equipos, pero los equipos trabajan para un sólo producto. Y dos: que muy probablemente tenga una segregación de tareas dentro de los equipos: analista de negocios, arquitectos, diseñadores, desarrolladores, probadores, y hasta operadores si ejecuta su propio software. ¿Un producto utiliza otros? Por supuesto, excepto si tiene pedazo gigante de software monolítico, en cuyo caso usted está peor que el resto de nosotros, y tiene problemas más urgentes e importantes que resolver. Cada una de las funciones de un equipo de producto que he mencionado antes, trabaja para su propio producto. Los equipos de un producto realmente no se preocupan por otros los productos que utilizan los suyos y ciertamente no controlan los demás productos que ellos consumen. Y la transición desde desarrollo hasta operaciones se parece a desarrolladores que lanzan algo sobre el muro para que la tomen los operadores… ¿a quién le importa lo que sucede en el otro lado? Invariblemente hay una venganza, los operadores siempre pueden enviar solicitudes de corrección de errores hacia los desarrolladores.

La organización de equipos alrededor de los servicios, significa que un equipo de servicio tiene todo lo que necesita para ofrecer el servicio y cumplir con el acuerdo de nivel de servicio. No hay muros. El dueño del servicio, analistas de negocio, desarrolladores, probadores y operadores se sienta juntos por adelantado para definir cómo lucirán en el futuro el servicio en sí y el proceso de desarrollo del servicio, de extremo a extremo. Radical, ¿no? Sí, pero es lo que necesita. Un operador diciéndole a un desarrollador de software qué tipo de despliegue automatizado, monitoreo y capacidades de telemetría necesitará para operar el servicio. Estos son requisitos no funcionales y los arquitectos y desarrolladores de software están acostumbrados a tratar con este tipo de requerimientos. Un probador diciéndole a un desarrollador de software la manera en la que debe diseñar el software para que él o ella pueda probarlo de forma eficaz y eficiente. Estos son requisitos no funcionales también. Un arquitecto de software o desarrollador diciéndole al dueño del servicio lo que se puede o no se puede construir en un momento dado y las restricciones de recursos y presupuesto. Parece una locura, pero estos ejemplos son tan sólo requerimientos del negocio, el propietario del servicio está acostumbrado a tratar con ellos durante la definición del servicio.

Si piensa que los servicios están sólo en la capa externa en contacto con el mundo exterior, está equivocado. El mismo concepto se puede utilizar en las capas internas, en lo que me gusta llamar como arquitectura empresarial orientada a servicios. No es lo mismo que la arquitectura orientada a servicios simple y llana, donde los servicios de aplicación eran la piedra angular. Estoy hablando de servicios de negocio, servicios de aplicaciones y servicios de infraestructura, todos organizados de la misma manera, confiando uno en uno a través de acuerdos de nivel de operación bien definidos desde el lado de los consumidores de servicios, y de acuerdos de nivel de servicio como parte de una clara definición de servicio desde el lado del proveedor de servicios.

Las empresas de software más grandes (bueno, depende de su definición de grande) son de hecho proveedores de servicios basados en software (Microsoft, Google, Amazon, Facebook, Twitter, WhatsUp, Apple, y así sucesivamente). Su empresa podría no ser tan grande como éstas, pero si se trata de un proveedor de servicios basado en software, es posible que tenga más cosas en común con ellos de lo que usted piensa. De alguna manera u otra, todos ellos se organizan detrás de los servicios que proporcionan. ¿Por qué no habría de hacerlo usted?

Written by fernandomachadopiriz

20/11/2014 at 09:58

.NET Conf UY 2014 – Arquitectura para Windows Azure: Pienso, luego existo

leave a comment »

Gracias a los amigos de .NET Conf UY la charla que dí sobre arquitectura para Windows Azure en ese evento está disponible en YouTube:

Written by fernandomachadopiriz

26/10/2014 at 21:47

Publicado en Azure

Una nueva vida para un viejo blog

leave a comment »

Este blog nació hace más de cuatro años. En aquél tiempo trabajaba como Arquitecto de Soluciones independiente y como docente de los cursos Programación e Ingeniería de Software en la Universidad Católica del Uruguay. Había sido designado por Microsoft como Most Valuable Professional desde 2008 hasta 2010 cuando comencé a trabajar como Consultor de Desarrollo en Microsoft.

En aquél tiempo escribía sobre los temas que sabía o aprendía y que creía que a los lectores les podían interesar: programación —C#, .NET Framework, Visual Studio—, gestión del ciclo de vida del software —Team Foundation Server—, nuevas tecnologías —LightSwitch—, y trataba de explicar conceptos difíciles en forma fácil —Covarianza & Contravarianza, Inversion of Control & Dependency Injection, Model View ViewModel-.

Luego por el trabajo que hacía y los temás que desarrollaba dejé de escribir. Ahora hace más de dos años que trabajo como Arquitecto Empresarial en Microsoft y estoy comenzando nuevos cursos de Arquitectura en el grado y en la maestría de la Universidad Católica del Uruguay.

Entonces quiero comienzar a escribir nuevamente pero, en temas de arquitectura, que podrán comenzar a leer en breve. Espero poder escribir artículos tan interesantes como antes, más allá que sean otros temas.

No puedo afirmar si el blog fue exitoso o no hasta ahora, aunque algunos números pueden dar una idea: entre los artículos en español y en inglés más los videos de demos correspondientes en YouTube, hay más de 260.000 visitas en poco más de 4 años y desde los más diversos lugares del mundo:

image

Visitas por mes al blog en español

image

Visitas por país al blog en español

Espero que los viejos lectores todavía quieran acompañarme y espero nuevos lectores también. Hasta la próxima.

Written by fernandomachadopiriz

20/07/2014 at 08:52

Publicado en Anuncios

.NET UY Conf, 3 y 4 de octubre

leave a comment »

Written by fernandomachadopiriz

11/06/2014 at 14:01

Publicado en Anuncios

Conectando una máquina virtual de Hyper-V a Internet a través de una conexión inalámbrica

with one comment

En un artículo anterior escribí acerca de cómo configurar un equipo portátil para actual alternativamente como servidor de virtualización o como un equipo de escritorio casi estándar. ¿Por qué querría hacer eso? Bueno, si necesita usar máquinas virtuales de 64 bits sobre soluciones de virtualización de Microsoft, su única opción es usar Windows Server 2008 o Windows Server 2008 R2 con Hyper-V. Por ejemplo, si necesita tener diferentes configuraciones de entornos de desarrollo SharePoint 2010 en el mismo equipo, necesitará usar máquinas virtuales de 64 bits.

En aquel artículo mostré cómo configurar un sistema operativo hypervisor -específicamente Windows Server 2008 R2- para que se comporte casi como un sistema operativo de escritorio –digamos Windows 7-, habilitando las características que vienen inhabilitadas en forma predeterminada: red inalámbrica, audio, Areo, hibernación, etc. Incluso, como probablemente quieran alternar entre el escenario de servidor hypervisor al escenario de escritorio, incluí algunos archivos de script para habilitar los servicios requeridos e inhabilitar los innecesarios en cada caso.

Aunque puedan correr exitosamente máquinas virtuales de 32 y 64 bits en sus equipos portátiles cuando Hyper-V está configurado correctamente, teniendo los recursos de hardware apropiados, se darán cuenta tarde o temprano que Hyper-V está diseñado para ejecutarse en un servidor físico, no en un equipo portátil. Permítanme darles un ejemplo: ¿Para qué usan un equipo portátil después de todo? Por la movilidad, ¿cierto? Pues bien, con la movilidad estarán conectados a una red inalámbrica, al menos ocasionalmente. Entonces se van a dar cuenta que Hyper-V muestra solamente los adaptadores de red Ethernet al crear conexiones virtuales externas.

Las dos alternativas que encontré en Internet –configurar Internet Connection Sharing o usar Routing and Remote Access Service– no me resultaron útiles porque ICS está inhabilitado por mi administrador y RRAS es demasiado complicado de configurar.

Tengo dos tarjetas de red en mi equipo portátil, una Intel® 82567LM-3 Gigabit Network Connection, y una Intel® Centrino® Ultimate-N 6300 AGN:

clip_image002

Pero sólo una está disponible en la lista de tarjetas de red para ser usadas cuando creo una conexión virtual externa:

clip_image004

Hay una forma fácil que resolver esto, y tener la conexión virtual externa conectada a través de una conexión inalámbrica:

  1. Configuren una conexión virtual externa usando la conexión cableada como es habitual. Las máquinas virtuales usan esta conexión cuando están conectados por cable para acceder a Internet.
  2. Cuando no estén conectados por cable, creen un puente entre la conexión inalámbrica y la conexión externa virtual, seleccionando ambas conexiones en la ventana Network Connections, haciendo clic con el botón secundario, y seleccionando Bridge Connections del menú desplegable.

Verán una conexión de red adicional llamada Network Bridge y podrán acceder a Internet desde la máquina virtual a través de la conexión inalámbrica. Borren la conexión puente cuando estén conectados por cable nuevamente.

clip_image006

Como probablemente no necesiten estar permanentemente conectados a Internet, pero quieran acceder a los archivos y carpetas del equipo huésped, habitualmente configuro una red interna virtual además de la externa, y todas mis máquinas virtuales tienen dos adaptadores de red conectados a cada una de estas conexiones.

Si tienen un escenario similar al mío, este dato puede simplificarles el trabajo. Saludos.

Written by fernandomachadopiriz

26/03/2011 at 08:28

Publicado en SharePoint

Tagged with

Nueva versión de Visual Studio 2010 and .NET Framework 4 Training Kit

leave a comment »

imageDesde ayer está disponible para descarga desde el sitio de Microsoft la actualización de marzo de 2011 del Visual Studio 2010 and .NET Framework 4 Training Kit. Pueden descargar el kit desde aquí. Este training kit incluye presentaciones, hands-on labs y demos, que cubren las últimas novedades en las versiones de Visual Studio 2010 y .NET Framework 4 recientemente actualizadas . Que lo disfruten.

 

 

 

 

 

 

Written by fernandomachadopiriz

15/03/2011 at 19:03

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 222 seguidores