Caso: Una empresa tiene una aplicación que ha utilizado durante más de 10 años y que le da buenos resultados. Esta aplicación corre en una plataforma que ya no tiene soporte y para la que ya no existen licencias en el mercado (Windows 2003) y las alternativas de sustituirla por otra o inclusive por una versión más moderna de la misma o de portarla a una nueva plataforma, son muy onerosas.

Solución:

La solución es una plataforma virtual Windows 2003 en una red en La Nube, que se interconecta con la red de la empresa. Con esta arquitectura, los usuarios de la aplicación acceden a ésta exactamente de la misma forma como lo habían hecho siempre y la vida útil del software se extiende por lo menos cinco años más, que es el tiempo que se garantiza que las imágenes virtuales estarán disponibles.

Adicionalmente, se tiene que la aplicación es interactiva, por lo que sólo opera en días hábiles, durante el horario de oficina. El servidor que aloja esta aplicación está entonces programado para arrancar automáticamente sólo en días hábiles y para detenerse al final del horario laboral. Esta solución ahorra del orden de un 60% del costo de procesamiento (CPU).

Para más información: contáctenos...

Caso: El negocio cuenta con una aplicación web móvil (Web App) que genera ingreso a través de suscripciones. El sistema tiene una base geográfica en la que se georeferencían ciertos recursos y sus propiedades. La información se mantiene en una base de datos geográfica -residente en un centro de datos físico- y periódicamente se extrae para crear un caché en la aplicación, con el objetivo de minimizar los tiempos de respuesta de la Web App.

Como la mayoría de las aplicaciones Web, ésta sigue un proceso casi continuo de mejora. Los ciclos de mejora, que pueden contemplar nuevas funcionalidades y/o correcciones a errores, tienen una vida de entre una semana y dos meses, dependiendo de su alcance. Al concluir, se cuenta con una nueva versión que, ya probada, se pone en producción.

El acceso a la aplicación móvil, en términos de número de usuarios concurrentes, es muy variable y poco predecible, en rangos de unos cientos, hasta varios miles. Un objetivo importante es que el tiempo de respuesta de la aplicación no se degrade notoriamente con el aumento en la carga de trabajo.

Solución:

La solución que se integró en AWS contempla los siguiente puntos:

El personal de la empresa se conecta al centro de datos virtual a través de VPN. En el centro de datos hay 2 redes, una privada en el segmento 10.16.0.0/24 y una pública (a través de un Gateway), en el segmento 10.16.1.0/24. De esta forma, sólo el servidor de VPN, el extractor de datos geográficos (xtract) y el balanceador de carga (LB) están expuestos en Internet.

Los trabajos de mejora y corrección de la aplicación se llevan a cabo en un servidor “dev”, accesible solamente en la red privada. Este servidor puede ser prendido y apagado bajo demanda, ahorrando así los costos de CPU no requeridos cuando no hay desarrollo.

Igualmente, la extracción de datos geográficos que se ejecuta semanalmente y que procesa datos durante aproximadamente 72 horas, permanece apagado el resto del tiempo, con el ahorro correspondiente.

“xtract” actualiza los datos de “app”. Después de una actualización de app, se crea una imagen virtual que será posteriormente utilizada para lanzar instancias de servidores de la WebApp (rt1 ... rtN).

“rt1” ... “rtN” son instancias del servidor de la WebApp que se generan en función de la carga de usuarios. El balanceador de carga LB está programado para automáticamente crear o eliminar instancias de app en función del tráfico y/o de la carga del CPU en las instancias rt1 ... rtN. El mínimo de instancias disponibles es 2, de manera a que en el escenario de mínima carga y de una eventual falla en uno de los servidores, quede el otro para responder durante el tiempo que tome el balanceador de carga para detectar la falla y crear una instancia de reemplazo.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis lacinia, magna a rutrum tincidunt, sapien tellus pharetra sapien, nec pulvinar magna nunc ut erat. Etiam finibus, nisl id elementum tristique, dui nibh dignissim turpis, nec accumsan ex magna vel libero. Curabitur ut venenatis magna. Donec ut orci sit amet augue molestie fringilla non vel diam. Nunc tincidunt nisi in scelerisque congue. Vestibulum consectetur euismod ante in porta. Phasellus vitae lectus arcu. Phasellus posuere malesuada purus nec bibendum. Phasellus ultricies magna purus. Sed semper, eros non ullamcorper ullamcorper, nunc ipsum suscipit augue, ac scelerisque turpis lacus id dui. Suspendisse potenti.

Para más información: contáctenos...

Caso: El cliente tiene 2 centros de producción en ciudades diferentes. La aplicación crítica para el negocio son un ERP, para el control de almacenes, tanto de materia prima, como de productos y para la planeación de la producción. Adicionalmente cuenta con un CRM para la administración de los clientes.

Antes de proponer una solución, la empresa tenía los sistemas duplicados, un ERP y un CRM en cada uno de los centros de producción. Sin embargo, una buena parte de la información no es exclusiva de un centro, sino común a ambos y se invertía tiempo y esfuerzo significativos para sincronizar los datos de ambos centros, situación, además de ineficiente, propensa a errores.

Adicionalmente, con equipo de cómputo servidor en ambos centros de producción, el mantenimiento de éste se dificultaba. No pudiendo mantener staff en ambos centros, el personal encargado de estas tareas tenía que viajar entre ciudades, lo que ocasionaba una gran pérdida de tiempo y dificultades en la atención a situaciones urgentes.

Solución:

La solución que se implementó, consta de un centro virtual de datos al que se conectan por VPN ambos centros de trabajo. Además de un decremento significativo en costos de TI y de la agilización del mantenimiento de los servidores, los datos de las aplicaciones críticas se integraron, tanto para el ERP, como para el CRM, lo que proporcionó una solución más íntegra y funcional.

Para más información: contáctenos...

Caso: El personal de la empresa (seis personas, entre socios y empleados) trabajan de forma distribuída geográficamente, unos por motivo de constantes viajes de trabajo y otros por economía de tiempo, suprimiendo el transporte diario a la oficina.

Sin embargo, el personal de la empresa trabaja prácticamente todo al rededor de una aplicación que mantiene los datos de proveedores, productos, clientes, cotizaciones y ventas. Esta aplicación se encontaba instalada en todas las computadoras personales, una funcionando como Mastra y las otras como Esclabas, sincronizándose periódicamente.

Solución:

Se implementó un servidor Windows en la nube al que los usuarios se conectan por RDP y lo utilizan como su desktop virtual. De esta forma los usuarios comparten unas base de datos única y las funciones de mantenimiento, respaldo y eventualmente recuperación de fallas se concentran en el "centro de datos".

Para más información: contáctenos...

Caso: La empresa proporciona servicios de alojamiento de sitios Web y contempla los servicios asociados de servidor de nombres de dominio (DNS) y de correo electrónico.

Además de capacidad suficiente y adecuado tiempo de respuesta (baja latencia), la continuidad de los servicios (confiabilidad) es imperativa.

Solución:

La solución contempla la implementación de 2 sitios independientes y geográficamente separados, uno primario y uno de respaldo.

En operación normal, las funciones de servidor Web, servidor de correo electrónico y servidor de bases de datos, se encuentran operacionales en el sitio primario.

En caso de falla o indisponibilidad de los servirores Web, de correo electrónico o de bases de datos primarios, entran en operación los componentes de respaldo correspondientes.

Para los servidores de nombres de dominio, se aprovecha la naturaleza distribuída inherente al sistema DNS y se implementan 3 instancias de servicio, 2 en el sitio primario y una en el sitio de respaldo.

Para más información: contáctenos...

Caso: El caso típico de una pequeña empresa es que un grupo de usuarios de TI acceden a sus aplicaciones desde una misma localidad. Algunos, sin embargo, requieren acceso remoto y/o acceso móvil.

Por otra parte, la empresa tiene una o varias aplicaciones de acceso público, como por ejemplo un sitio Web

Solución:

La solución típica en este caso, contempla la implementación de 2 servidores en la nube, un Windows y un Linux.

El servidor Windows proporciona las funciones de escritorio remoto y compartición de aplicaciones y datos.

El servidor Linux proporciona las funciones de alojamiento de sitio Web, CRM y otros.

Para más información: contáctenos...

Caso: El cliente es una pequeña empresa con aproximadamente 20 empleados y utiliza una configuración de SAP Business One para sus procesos administrativos.

Solución:

SAP ha sido cliente de Amazon Web Services (AWS) desde 2008 y la infraestructura de AWS conforma con las especificaciones de SAP para una variedad de casos de uso y escenarios. A principios de 2011, AWS se convirtió en Socio Tecnológico Global de SAP. Desde entonces, AWS ha trabajado estrechamente con SAP para probar y certificar las soluciones en la nube de AWS para SAP.

Esta configuración, típica para un SAP Business One, contempla un servidor Windows 2012 para las funciones de front-end de SAP y un servidor Linux para las funciones de back-end.

Para más información: contáctenos...

Caso: El cliente es una empresa mediana con aproximadamente 1,500 empleados y utiliza SAP para controlar sus procesos administrativos y de producción.

Solución:

SAP ha sido cliente de Amazon Web Services (AWS) desde 2008 y la infraestructura de AWS conforma con las especificaciones de SAP para una variedad de casos de uso y escenarios. A principios de 2011, AWS se convirtió en Socio Tecnológico Global de SAP. Desde entonces, AWS ha trabajado estrechamente con SAP para probar y certificar las soluciones en la nube de AWS para SAP.

Esta configuración contempla el stack completo de desarrollo (dev), calidad (qa) y operación (ops). Cada etapa contempla dos servidores Linux, uno para las funciones de front-end de SAP y otro Linux para las funciones de back-end (HANA).

Para más información: contáctenos...