Opiniones, noticias y artículos de nuestro equipo

Entradas etiquetadas como ‘arquitectura’

Una guía de SAP en Amazon Web Services

aws-sap
Una de las consultas habituales que nos hacen nuestros clientes es qué relación hay en la actualidad entre SAP y AWS y si ya es posible instalar SAP en instancias de AWS o si existe alguna modalidad de subscripción.

Desde 2008, año en que SAP se convirtió en cliente de AWS, la relación de partnership tecnológico entre ambas compañías no ha dejado de incrementarse y en nuestros días AWS ya es “SAP Global Cloud Services” y “SAP Global Technology Partner”.

A fecha de hoy ya existe un conjunto de soluciones SAP certificadas para entornos de producción (con ciertas limitaciones) que pueden ser suministradas desde AWS:

  • SAP Business Suite, el SAP clásico.
  • SAP Business All-in-One, la solución pre-configurada de SAP basada en SAP Business Suite.
  • SAP Rapid Deployment Solutions, SAP Business Suite preconfigurado y con servicio de Hosting.
  • SAP BusinessObjects BI Solutions, DataWareHouse.
  • SAP Afaria, la parte de movilidad de SAP y acceso al transaccional y al BI desde dispositivos móviles.
  • SAP HANA One, la nueva arquitectura de SAP, evolución de NetWeaver, que incluye base de datos “in-memory”.

Y en proceso de certificación:

  • SAP Business One, la solución SME de SAP no basada en SAP Business Suite.
  • Sybase Unwired Platform, el PaaS de SAP para desarrollo entorno móvil.

Sistemas Operativos y base de datos certificados

Ni todos los sistemas operativos ni todas las bases de datos que funcionan en R3 de SAP están certificados para AWS.

Quizás la limitación más evidente a la fecha, para actuales clientes SAP que exploren la posibilidad de moverse hacia AWS, es que Oracle DB no está certificada aun para entornos de producción (a fecha de hoy).

En este ámbito, los sistemas operativos certificados son:

  • SUSE
  • Red Hat
  • Microsoft Windows Server 2008

Y las bases de datos certificadas son:

  • IBM DB2
  • SAP MaxDB
  • Microsoft SQL Server 2008
  • Sybase

Licencias

SAP habilita el BYOL (Bring-Your-Own-License) para aquellos clientes que quieran probar/migrar sus soluciones SAP a AWS.

La lógica, en cualquier caso, aconsejaría negociar, a ser posible, de forma particular estas condiciones, ya sea con la misma SAP o con el partner de turno.

Otros tipos de licencias disponibles incluyen SAP HANA One Business Edition a 0,99$/hora (consultar disponibilidad por zona geográfica) y BI-BO para 5 usuarios.

De forma adicional los desarrolladores disponen licencias Trial/Developer para SAP Afaria, SAP Process Orchestration, Sybase Unwired Platform y SAP HANA One.

Algunos partners globales y locales de SAP ya ofrecen soluciones personalizadas basadas de forma parcial o total en AWS.

Tipos de Instancias EC2 y precios

Los requerimientos de tipo de instancia EC2 para correr SAP en entorno productivo, según lo que el mismo Amazon ha realizado en los benchmarks de cálculo de SAPS, parten de instancias de alto consumo de recursos, y no de las básicas. Éstas últimas pueden utilizarse en entornos de test o desarrollo.

Los cálculos anteriores empiezan con instancias de la familia “High-Mem” y, en concreto, las de “Double Extra Large” y saltan a las de la familia “Cluster Compute”. Ambas dan valores de SAPs óptimos para el benchmark, pero son de las instancias EC2 más caras.

El pasado 13 de Febrero de 2013 AWS hizo el ejercicio de cálculo para el coste mensual de 1 instancia EC2 “on-demand” para correr SAP. La instancia del cálculo era una M1 “Extra Large” activa de lunes a viernes de 8 de la mañana a 8 de la tarde, con 200 GB de almacenamiento permanente en volumen EBS y de 300 GB de almacenamiento para Backups en S3. Todo por 198 $.

Si bien los precios de Amazon tienen por costumbre bajar, según lo visto en los últimos tiempos, hay que tener en cuenta en el cálculo anterior dos factores que AWS no incluyó y que condicionan el precio al alza, en caso de realizar los cálculos reales desde Europa.

  • Restringir el tiempo de actividad de una instancia para SAP de 8 de la mañana a 8 de la tarde puede no ser realista para muchos SAP transaccionales con operaciones continuas programadas fuera de horas de oficina.
  • Los mencionados precios están calculados para la región “US-East” (más económicos que para Europa – Irlanda) y no incluyen el recomendable “Business Support” que incrementaría en unos 100 $ el precio mensual, además han incorporado el pequeño descuento que se aplica para nuevos clientes el primer año con el “Free-Tier” que ofrece AWS.

Más información

  1. Aquí puedes acceder a la calculadora que AWS ha utilizado para realizar el mencionado cálculo del artículo.
  2. Listado de recursos SAP dentro de la web de AWS.
  3. Durante el pasado SAPPHIRE NOW USA realizado en Julio de 2012, SAP registró un capítulo de “Inside The Ecosystem”, en el que desde un punto de vista más de negocio se habló de SAP en AWS.

Sobre el autor

Tomàs Manzanares - Sales Consultant at CAPSiDE

Tomàs Manzanares es Sales Consultant en CAPSiDE, consultor certificado por SAP, Blogger/Founder/Media Producer en MossegaLaPoma.cat y formador en el post-grado en Community Management y comunicación digital de la UPC School of Professional & Executive Development.

El valor de la independencia

En una empresa como la nuestra, que no vende productos sino que es proveedora de servicios (y de “tranquilidad”), los principales activos son las personas y los valores que se establecen para prestar dichos servicios.

Uno de los valores fundamentales que hemos adoptado es el de la independencia, frente a proveedores de soluciones y fabricantes de Hardware y Software. Después de trabajar varios años siendo proveedores de servicios mono-marca sacamos una conclusión muy clara: una sola marca no puede dar la mejor solución a todos los problemas de un cliente y, para que los clientes la obtengan, se necesita asesoramiento profesional de una figura independiente y especialista que les pueda guiar entre el sinfín de tecnologías y soluciones del mercado.

Un ejemplo donde podemos apreciarlo de forma bastante clara:

  • Somos partners de Microsoft y buenos conocedores de la tecnología Exchange Server.
  • Cada vez nos llegan más clientes con peticiones de migración de su servidor Exchange interno a versiones más recientes.
  • La complejidad de la migración, el coste de las licencias y del mantenimiento posterior son factores que hay que tomar muy en cuenta para ver si tener el Exchange dentro de casa es a día de hoy la solución más adecuada.
  • Seguramente en el año 2003 o en el 2007 era la mejor solución, pero ahora con la versión de Exchange Online, los costes de mantener un servidor Exchange en casa ya salen difícilmente y es necesario estudiar con cuidado la oportunidad de ir a la propia solución Hosted de Microsoft.
  • Buzones de 25GB, integración con Active Directory, pago por usuario, alta disponibilidad asegurada por la red de centros de datos de Microsoft, etc.
  • “Todo” son ventajas, a un coste de alrededor de 3€ por mes y por usuario.

Para CAPSiDE sería mucho más rentable recomendar y dirigir a los clientes hacia mantener su servidor interno, realizar la migración y el posterior mantenimiento. A corto plazo, el beneficio económico para CAPSiDE es infinitamente mayor si el cliente sigue con una solución Exchange en su casa. Pero, ¿quiere decir esto que vamos a recomendar esta solución? No.

Recomendaremos la solución que tenga el mayor sentido para el cliente.

Y si no es Exchange online podría ser Gmail u otra solución de correo, incluyendo soluciones propias de CAPSIDE  que perfilen el servicio que necesita el cliente final si sus requisitos así lo dictaminan.

Comprender las necesidades de negocio reales del cliente

En CAPSiDE creemos firmemente que el primer requisito para que el factor de la independencia funcione es escuchar al cliente y empatizar con él. Es decir, no recomendarle directamente la solución que conocemos mejor (con la que hemos trabajado en más proyectos anteriormente) y/o que revendemos con un cómodo margen.

Para eso se necesita pasar tiempo con el cliente, entendiendo y comprendiendo su negocio y el porqué de las decisiones que ha tomado hasta la fecha. Una vez hayamos entendido los criterios propios que mueven a nuestro cliente, podremos empezar a buscar una solución que cubra los requisitos reales de su proyecto y las necesidades de negocio que derivan del mismo. Cada cliente tiene unas necesidades únicas y sólo el conocimiento de su negocio, de sus criterios y de la importancia que le da a cada uno permite en consecuencia ofrecerle una solución adecuada. Adecuada hasta cierto punto, dado que hoy en día los negocios y la tecnología se mueven de forma tan rápida que la validez de una solución también puede venir con fecha de caducidad. Y es aquí donde la independencia vuelve a jugar un papel importante. Como proveedores e ingenieros independientes, nuestra capacidad de cambiar proactivamente la solución de un cliente (si la actual ya no encaja en sus nuevos criterios de decisión) es mucho mayor.

Tenemos varios ejemplos de éxito, experiencia de CAPSiDE en servicios de brokerage de infraestructura y premios de grandes proyectos que nos avalan. Cuando una infraestructura ha soportado ya durante varios años el negocio online de un cliente, la aparición de nuevas tecnologías  mucho más evolucionadas y estables, con costes escalables como el Cloud Computing harán que desde CAPSiDE planteemos al cliente migrar su infraestructura para beneficiarse de las ventajas del nuevo modelo. Si fuéramos revendedores exclusivos de un proveedor de infraestructura lo que seguramente no haríamos es ir en nuestra propia contra invitando los clientes a migrar a otra solución por entender que no les podemos ofrecer una solución de continuidad adecuada.

De allí sacamos otra conclusión fundamental para que el valor de independencia funcione de verdad:

no aplicar margen sobre los servicios de terceros.

En este sector, donde muchas empresas generan negocio basándose únicamente en la reventa de servicios, eso parece una regla contra natura pero es la única que garantiza una real independencia. Aunque no aplicamos margen sobre servicios de terceros, aplicamos un concepto que corresponde al coste de gestión del proveedor. En efecto la interacción con el soporte y la “re-facturación de servicios” representan horas de servicio por parte de nuestro equipo, que valoramos y añadimos a la facturación mensual. El coste dependerá de la complejidad de la infraestructura y también de factores ligados al propio proveedor, como por ejemplo la calidad y respuesta de su soporte técnico.

Benchmarking activo de proveedores de infraestructura

Ser independiente significa también para nosotros no disponer de infraestructura propia.
Hoy en día la oferta de infraestructura es muy extensa, y existen proveedores que pueden ofrecer soluciones para todo tipo de necesidades y de presupuestos. Tampoco queremos revender en exclusividad las soluciones de un proveedor determinado lo que iría en contra de nuestra libertad de elegir. Existen todavía en el mercado mucho actores más pequeños que se esfuerzan en montar soluciones para sus clientes basadas en infraestructura propia alojada a veces en centros de datos de dudosa solvencia técnica o bien revendiendo servicios de terceros de baja calidad. En CAPSiDE la independencia se manifiesta por nuestra capacidad de realizar un benchmarking activo de las soluciones del mercado para nuestros clientes. Es activo porque proviene de la experiencia real de ver como funcionan las soluciones en el día a día, de la respuesta del proveedor en temas comerciales y técnicos, y de su capacidad de hacer frente a problemas y respondiendo a incidencias. Es este valor el que trasladamos a nuestros clientes en la consultoría donde valoramos dónde y cómo montar una infraestructura.

Una posible crítica al modelo de independencia tal y como lo planteamos puede ser el hecho de que queriendo abarcar demasiados proveedores y tecnologías acabemos siendo generalistas, lo que va claramente en contra de nuestro foco de expertise. Eso nos ha obligado a limitar el número de proveedores en los cuales podemos ofrecer una solución como “prime contractor” por el SLA global que ofrecemos. También podemos trabajar con otros  proveedores, pero sin incluir la parte de infraestructura en nuestra garantía de servicio, por el desconocimiento o la falta de confianza hacia dicho proveedor.

Ahora bien, el criterio de independencia muestra claramente al cliente que nuestros intereses están alineados con los suyos. No por administrar más infraestructura tendremos más margen en la operación, con lo cual nuestras recomendaciones siempre irán enfocadas a la mejora real de las soluciones. Un elemento clave y real que refuerza la confianza que nuestros clientes nos demuestran día a día.

Sobre el autor

Thierry Davin - CTO at CAPSiDE

Thierry Davin es Ingeniero Informático y Senior Director de CAPSiDE. Arrancó su carrera profesional en Francia en 1991, año que nacía Linux. Después de varios años en desarrollo de Software se orientó hacia la administración de sistemas hasta principios de 2001 para adentrarse en el mundo de los servicios relacionados con hosting. Ahora en CAPSiDE se centra en el desarrollo de nuevos servicios.

Architects of the digital society

Es el eslogan de CAPSiDE pero es también una metáfora que encuentro muy  interesante. Los arquitectos tradicionales diseñan edificios cuidando el aspecto visual pero asegurando también un aspecto fundamental, el que el edificio aguante de pie una vez construido.

La analogía con el negocio de IT está clara: al diseñar una infraestructura nueva el arquitecto de IT tiene que asegurar que cumplirá con las funciones para las cuales ha sido diseñada. Al arquitecto IT puede que no se le requiera que el diseño quede elegante pero entrarán en cuenta otros criterios que hacen que su trabajo se complique.

A pocos edificios reales se les pide que tengan flexibilidad en el crecimiento y decrecimiento, disponibilidad total, alto rendimiento y demás cosas que si son criterios muy importantes para un arquitecto de servicios IT. De hecho construir una arquitectura IT es buscar un equilibro entre todos esos criterios, equilibro a veces complicado de encontrar dado que muchos criterios son antagonistas entre sí (coste reducido y alta disponibilidad por ejemplo). Otra diferencia fundamental con el arquitecto de edificios es que el trabajo de arquitecto de TI se basa muchas veces en reingeniería de arquitecturas que tenían previamente un uso distinto. El equivalente a “transformar un rascacielos de 100 pisos en una fábrica de cemento” es algo relativamente frecuente en TI pero imposible en arquitectura tradicional.

Como en la construcción tradicional la creación o transformación de arquitecturas de TI debe de seguir algunas reglas básicas si queremos que el edificio quede de pie pero que también se pueda adaptar a las fluctuaciones del negocio al cual da soporte. En efecto muchas veces se olvida que las infraestructuras de TI no son un fin en sí, sino que son un medio muy importante para hacer que el negocio sea más dinámico, eficiente en costes y en resumen más competitivo.

Las reglas básicas deben evitar que se instale el caos en las infraestructuras de las empresas. Cuantas veces desde CAPSiDE realizando auditorías de infraestructura en empresas de tamaño mediano a grande nos encontramos con un panorama bastante desolador: cada aplicación o proveedor de aplicación vino con la implementación de su propia arquitectura “recomendada” creando un bosque de sistemas y aplicaciones totalmente heterogéneo, muy difícil y costoso de administrar y luego de re-estandarizar.

En ciertos casos como en los de absorción o compra  de empresas la duplicidad e incompatibilidad de sistemas es algo normal y transitorio, pero a veces este caos se consolida como norma de funcionamiento de la empresa. Gestionar la ineficiencia propia se vuelve entonces la única meta de los gestores de IT de la empresa. Se empeoran todavía más los problemas cuando el crecimiento del negocio pide más a los sistemas de información de la empresa hasta la rotura completa: pérdida de datos, incapacidad de acompañar el negocio, problemas de seguridad, etc. Es en este momento que los gestores de TI tienen la difícil tarea de explicar y justificar frente al negocio como se ha podido crear un foso tan profundo entre los dos mundos.

Para evitar llegar a situaciones tan críticas es fundamental tener en mente algunas reglas básicas:

  1. No dejar por completo la empresa en manos de los proveedores.
    La externalización es en muchos casos un factor positivo que permite a las empresas ser más competitivas, llegar antes al mercado, ahorrar en costes y centrarse en su core business, pero no se puede externalizar sin una definición clara de las funciones a realizar y sin ejercer un control fuerte sobre el proveedor para que siga las normas pactadas. Muchas veces aun siendo básicas esas no se cumplen: documentación de los procesos, SLAs entendibles y medibles, control regular de costes, adaptación a los estándares de TI de la empresa, etc.
  2. El departamento de TI debe de estar presente desde el  arranque en todos los proyectos de la empresa porque todos tendrán una repercusión sobre los sistemas de información. Como motor de la empresa las TI deben de ser una pieza clave en todas las decisiones de negocio.
  3. Se debe de crear y mantener actualizado un plan estratégico de sistema que defina un rumbo claro en el desarrollo de las TI acompañado de una planificación que permita medir su cumplimiento efectivo.
  4. Definir y mantener una infraestructura de sistemas que permita responder de forma ágil a las necesidades del negocio siguiendo sus propios criterios. No será lo mismo definir una arquitectura de sistemas para una empresa industrial consolidada que para un negocio nuevo en Internet.
  5. Las personas son como siempre el factor clave pero con la transformación que ha experimentado las TI en los últimos años la calidad de las personas es todavía más un factor crítico de éxito. En especial, el CIO ha pasado de tener un perfil altamente técnico para convertirse en el interlocutor privilegiado del negocio, sabiendo rodearse de las personas adecuadas para facilitar el alineamiento de las TI con las prioridades de la empresa.

En CAPSiDE tenemos la suerte de compartir la realidad del  departamento de TI de muchas empresas en sectores muy distintos y desde distintas perspectivas (marketing, ventas, producción, el propio departamento de TI, etc.). Eso nos proporciona experiencias muy diversas y enseñanzas que capitalizamos y usamos para ayudar a mejorar el funcionamiento de los departamentos de TI nuestros clientes.

CAPSiDE: “architects of the digital society”.

Sobre el autor

Thierry Davin - CTO at CAPSiDE

Thierry Davin es Ingeniero Informático y Senior Director de CAPSiDE. Arrancó su carrera profesional en Francia en 1991, año que nacía Linux. Después de varios años en desarrollo de Software se orientó hacia la administración de sistemas hasta principios de 2001 para adentrarse en el mundo de los servicios relacionados con hosting. Ahora en CAPSiDE se centra en el desarrollo de nuevos servicios.

Seguir

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