Microsoft Certifications

Microsoft Certifications

Al estar muy de cerca de Microsoft durante muchos de los años en los que tengo de laborar y ser contacto principal de dicha empresa en el lugar en el que trabajo, además de que muchas personas me consultan sobre este respecto, se me ocurrió recopilar un poco de la información que he recolectado durante todo este tiempo y me pareció interesante agregar un artículo en el blog sobre esto, la idea es ver un poco la historia y documentar qué es lo que existe hoy en día (2014) y las preguntas más frecuentes sobre qué hacer para certificarse con Microsoft.

Primera Generación

Hasta donde tengo memoria, las primeras certificaciones proveídas por Microsoft incluían la MCP (Microsoft Certified Professional), MCAD (Microsoft Certified Application Developer), MCSD (Microsoft Certified Solution Developer), MCDBA (Microsoft Certified Data Base Administrator) en el área de desarrollo o MCSE (Microsoft Certified Systems Engineer) y MCSA (Microsoft Certified Systems Administrator) en el área de infraestructura, entre muchas otras, estas evolucionaron de entre tecnologías tan variadas como Visual Studio 5.0, 6.0 (Incluyendo Visual Fox), 2002, 2003, SQL Server 6.5, 7.0 o 2000.

Segunda Generación

Casi que Con la salida del Visual Studio 2005 y SQL Server 2005, surgió lo que Microsoft denominó certificaciones de la nueva generación que ahora eran más orientadas hacia una especialización particular:

MCTS (Microsoft Certified Technology Specialist): Digamos que Homólogo al MCP, una de sus principales similitudes es que consistían en certificaciones que se ganaban con tan solo un examen, aunque algunos MCTS requerían de dos exámenes, adicionalmente, el MCTS venía más orientado a una especialidad en específica, mientras que el MCP era totalmente genérico, tomando en cuenta gran variedad de especialidades como SQL Server 2005 o BizTalk 2006, así con el MCTS existían certificaciones con “apellido” por decirlo así como por ejemplo: “MCTS SQL Server 2005”.

MCITP: Microsoft Certified IT Professional, que podía tener especialidades en el área de Business Intelligence, como DB Developer o como DBA (Homólogo al MCDBA).

MCPD: Microsoft Certified Professional Developer, que podía tener especialidades en aplicaciones Windows, Web (Homólogo al MCAD) y aplicaciones Enterprise (Homólogo al MCSD, que era por decirlo así, un escalafón más por encima del MCAD). Esta certificación también tenía “apellido” como por ejemplo: “MCPD: Web Developer”.

Adicionalmente se incluye un nivel nuevo, el Microsoft Certified Architect Program que reúne como requisitos 10 años de experiencia y 3 años como arquitecto, además de una tutoría de un arquitecto certificado de Microsoft.

Una característica de esta generación de certificaciones era que existían muchos exámenes que se podían reutilizar, por ejemplo el examen 70-536 podía servir para varios MCTSs y para todos los MCPDs), por esta razón siempre es muy importante el conocer muy bien todos los exámenes requeridos para cada certificación lo que se conoce como el Certification RoadMap.

Tercera Generación

Actualmente ya existe una nueva generación, esta se divide en cuatro grandes áreas (Business, Client, Server, Database y Development) en prácticamente todas estas áreas existe la certificación (aunque al no tener la palabra “certified”, digamos que es más como un asociado) MTA (Microsoft Tecnology Associate), la cual llega a sustituir al MCTS, la principal diferencia radica en que los exámenes para los MTA no se reutilizan en las certificaciones de mayor nivel.

Un dato curioso es que en los siguientes niveles de esta generación prácticamente todos los acrónimos de las certificaciones coinciden con acrónimos de la primera generación, aunque no necesariamente tienen relación con los mismos, de hecho podríamos decir que prácticamente no tienen relación. Por ejemplo el siguiente nivel consiste en el MCSA (Microsoft Certified Solutions Associate) que aplica para las áreas de Client, Server y Database, el en área de Business el análogo al MCSA es el MOS Specialist (Microsoft Office Specialist), mientras que en el área de desarrollo (development) no hay una certificación para este primer nivel.

El siguiente nivel lo conforman el MOS Master (en el área de Business), MCSE (Microsoft Certified Solutions Expert) para las áreas de Server y Database, estas también poseen apellidos como por ejemplo (MCSE Data Platform) y digamos que están al nivel de los anteriores MCPD y MCITP, mientras que en el área de desarrollo a este nivel tenemos la certificación MCSD (Microsoft Certified Solutions Developer), interesante notar que esta dice “Solutions” y no “Solution” como la de la primera generación, estás también tienen “apellido” como por ejemplo: “MCSD Web Apps”.

En la cumbre de esta pirámide, nos encontramos con el Microsoft Certified Solutions Master (MCSM) y Microsoft Certified Architect (MCA).

Quiero certificarme, ¿qué hacer?

Cuando alguien va a empezar a certificarse siempre es recomendado empezar por la última generación disponible y estudiar muy bien el RoadMap, así se podría determinar por qué ruta empezar, por ejemplo podría determinarse que el área de su interés es desarrollo (development) y más específicamente el área Web por lo que tendría muy claro que el primer examen a llevar a cabo sería el 70-480.

En el sitio Web www.microsoft.com/learning, se puede encontrar información muy útil sobre todas las certificaciones disponibles de Microsoft, los exámenes que estos requieren, los cursos necesarios para optar por los diferentes exámenes, el temario completo de cada uno, así como libros recomendados entre los que se encuentran los famosos self-paced que según Microsoft contienen la información necesaria para aprobar un examen en específico. Por supuesto dicho sitio solamente incluye material de Microsoft pero existe mucho más material de estudio de terceros incluyendo libros, simuladores, etc. Siempre lo más importante de estos ejercicios de certificación es el homologar conocimientos e ir siempre aprendiendo cosas nuevas con el fin de utilizar dicha información en la labor diaria, talvez es muy difícil que alguien domine perfectamente cualquier tema y/o tecnología pero es muy útil el conocer al menos gran parte de las opciones que nos brinda Microsoft, para explotar de una mejor forma dichas tecnologías.

Para realizar un examen de certificación de Microsoft al igual que cualquier otro tipo de certificación como Cisco, Solaris, Oracle o Adobe, estos no pueden ser realizados por universidades si no que requiere de proveedores de exámenes reconocidos por el ente certificador (Exam Providers), como por ejemplo VUE, Thomson Prometric o Certiport, en el caso de Microsoft actualmente solamente tiene un proveedor certificado, Thomson Prometric (http://www.prometric.com), los exam providers, tienen a su vez asociados Test Centers que es donde se realiza físicamente el examen, por ejemplo en Costa Rica tenemos New Horizons o Biznet. Desde el sitio de Prometric se pueden revisar los test centers, además se pueden inscribir para programar y pagar un examen (actualmente el costo es de $100) también se puede revisar la disponibilidad de horarios.

Load Balancing

Load Balancing o Balanceo de Carga, es una técnica aplicada a través de software o hardware (routers, switches), para la distribución de trabajo entre dos o más dispositivos, con el fin de maximizar el rendimiento, este es un término que muchas veces se confunde con Clustering, para aclarar un poco este punto, las técnicas de Clustering son mayormente aplicadas para asegurar una alta disponibilidad y confiabilidad, y se da principalmente en los que respecta a bases de datos; en cuanto al balanceo de carga, es un concepto que es mejor conocido en aplicaciones Web, en donde se desea mejorar el rendimiento de la aplicación a través de una distribución del procesamiento a través de N servidores, conformando lo que se conoce también como granja de servidores (Web Farm).

Uno de los grandes temas cuando se habla de balanceo de carga en aplicaciones Web, es lo concerniente al manejo del estado, como es bien sabido, un sitio Web es una aplicación Stateless (o sea que no mantiene información de estado por sí sola), para esto han existido innumerables técnicas ya sean desde el lado del cliente o el servidor, donde podríamos decir que la más popular es una técnica de servidor denominada Session State. El Session State consiste el almacenar en la memoria del servidor Web información de estado por cada cliente. En un ambiente de granjas esto puede acarrear inconvenientes, debido a que si un cliente hizo una solicitud al sitio que se procesó por el Nodo X, puede ser que la siguiente solicitud se haya procesado por el Nodo Y, y al ser estos dos nodos servidores diferentes, cada uno con su memoria propia, es imposible para ellos compartir dicha información, por lo que se perdería. Algunas de las técnicas utilizadas para solventar esto es la Persistencia, que consiste en que una vez que se ha creado una sesión para un cliente, el balanceador debe ser responsable de manejar los siguientes requests en el mismo servidor que lo atendió hasta que la sesión del mismo haya expirado. Talvez los dos principales inconvenientes achacados a esta técnica son las siguientes: primero, que si el servidor que estuvo atendiendo al cliente, falla, toda la información del mismo se perdería; y segundo, que no se estaría explotando el concepto de balanceo, sobre todo en aplicaciones que manejen pocos usuario que realizan muchos requests, aunque este último caso conformarían un escenario realmente atípico. Volviendo al primer inconveniente, igualmente en un ambiente en el que no existiese balanceo de carga, el problema de pérdida de sesión en caso de fallo se daría, por lo que esta situación no es achacable al uso de un balanceador. Una técnica de balanceo muy conocida que es propietaria de Microsoft es el NLBS (Network Load Balancing Service), esta técnica es por software y maneja persistencia a través del concepto de Afinidad del Cliente (Client Affinity), la cual se puede manejar por cliente (Para Intranet) o por dirección IP de clase C (para Internet).

Otra opción para evitar el problema de pérdida de información de estado, es almacenar dicha información en un servidor dedicado; ya sea este una base de datos, otro servidor Web, o un servidor con algún tipo de servicio o demonio, accesado a través de un puerto. Principalmente con la solución de base de datos se resuelve el problema de la pérdida de información en caso de fallo. Con las otras técnicas la caída de un servidor Web no acarrearía la pérdida de información, pero sí la caída del servidor dedicado, a no ser que dicha información no se almacene en memoria, si no en algún repositorio de información persistente como un archivo o una base de datos.

Un tema interesante al que se le puede seguir el rastro es el concepto de Application Delivery Controller, que ha sido nombrado Next Generation Load Balancer (balanceador de carga de la siguiente generación), el cual consiste en un dispositivo de red que a la hora de asignar un servidor busca el servidor más rápido que esté disponible y maneja aspectos tales como caché y seguridad.

Tracing en ASP.Net

Por muchos es bien conocido las herramientas de diagnóstico y tracing de Microsoft ASP.Net. En este contexto teníamos objetos como el Debug y el Trace. Con el objeto Trace la gente tendía mucho a confundirse, ya que existían dos tipos diferentes, el objeto trace de System.Diagnostics que era el que trabajaba con los famosos Listeners (por ejemplo, un archivo de texto, el Event Viewer, o un tipo custom, para guardar por ejemplo en una base de datos) y que tenía métodos como el “TraceInformation”, “TraceError”, “Write”, etc; y estaba el objeto Trace del contexto de la página con métodos como el “Write” y el “Warn” (que escribía un texto en rojo).

Una buena forma de tracear información tocando lo menos posible la aplicación y haciendo una combinación de estos dos objetos trace es la siguiente; en el archivo de configuración de la aplicación habilitar el trace a nivel de página dentro de la sección “system.web”:


< trace enabled="true" writeToDiagnosticsTrace ="true" pageOutput="false" traceMode="SortByTime" requestLimit="20"/>


Con valor de “false” en el atributo “pageOutput“, se evita ver la información de traceo en cada página, para utilizar la página genérica, http://servidor/directorioRaizApp/Trace.axd. Aquí el atributo clave es “writeToDiagnosticsTrace”, el cual lo estamos asignando a “true” con el fin de que todo lo que procese por el Trace de la página, se redireccione a los listeners de System.Diagnostics, que dicho sea de paso, aunque se pueden agregar por código, también se pueden agregar por archivo de configuración, dentro de la sección “configuration”, como se muestra a continuación:


< system.diagnostics>
< trace autoflush="true" indentsize="2">
< listeners>
< remove name="Default"/>
< add name="EventLogListener" type="System.Diagnostics.EventLogTraceListener" initializeData="MiSource"/>
< add name="LogFileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\TraceInfo.txt" />
< /listeners>
< /trace>
< /system.diagnostics>


Con esto estaríamos viendo la información, tanto en el Trace.axd, como en el archivo de texto y el Event Log respectivo. Y enviar información adicional sería tan fácil como utilizar la siguiente línea de código:


Trace.Warn(string.Format("Paso anterior al proceso a las {0}", DateTime.Now.Ticks));


Por supuesto esto se puede combinar también con un Switch para también contolar a través de archivo de configuración de la aplicación si se va a instrumentar o no, a través del siguiente código dentro de la sección “configuration” dentro del archivo de configuración de la aplicación, se muestra cómo hacer esto:


< system.diagnostics>
< switches>
< add name="SwitchApp" value="4"/>
< /switches>
< /system.diagnostics>


En este caso estamos asignando un nivel de “Verbose”. El código de la aplicación sería el siguiente:


TraceSwitch SwitchApp = new TraceSwitch("SwitchApp", "Switch de la aplicación");

if (SwitchApp.Level >= System.Diagnostics.TraceLevel.Verbose)
Trace.Warn(string.Format("Paso anterior al proceso a las {0}", DateTime.Now.Ticks));
…


Como en el caso anterior, estoy usando un nivel de “Verbose” para tomar la decisión de si instrumento o no. Obviamente este trabajo se puede hacer más simple y reutilizable a través del uso de clases utilitarias.