Service Level Agreements en SOA

julio 20, 2015

Categories: AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

En un mundo IT las arquitecturas basadas en servicios (SOA), cada vez tienen más relevancia. Se vuelve imprescindible para toda organización enfocada en el desarrollo de software, contar con una definición precisa y contundente de Service Level Agreement (SLA).

Un SLA es parte del contrato entre el consumidor de un servicio y quien lo provee y formalmente define el nivel del servicio, involucrando cuestiones como disponibilidad, performance y seguridad. Luego, dentro de un sistema basado fuertemente en SOA, donde los arquitectos y equipo desarrollador construyen su solución de software a partir de integrar y combinar distintos servicios, no contar con un SLA detallado y certero lleva irremediablemente al fracaso.

El Software Engineering Institute (SEI) [1] es un prestigioso centro de investigación y desarrollo enfocado en técnicas y herramientas para la Ingeniería de Software, y sus reportes tienen siempre un gran impacto en la comunidad. Uno de ellos [2] se aboca exclusivamente a analizar el rol de los SLA en arquitecturas SOA. A continuación se exponen los principales puntos de este reporte, presentando en primer lugar los lineamientos generales de los SLA y finalizando con la mención de algunas de las herramientas más utilizadas para el monitoreo y administración de los SLA.

SLA: Fundamentos

La importancia de los SLA es ampliamente reconocida. La organización TeleManagement (TM) Forum en su texto sobre SLA [3] profundiza estas razones: “un SLA define la disponibilidad, confiabilidad y performance de las comunicaciones entre servicios y canales de transmisión, al mismo tiempo que asegura que la información llega a la persona indicada, en el lugar y hora indicada.

Algunas de las razones por las que una organización debería definir SLAs para sus servicios son:

1 . Los servicios con SLA claros estarán en mejor estado para competir con otros en un mercado sobrecargado de servicios.

2. Su especificación permite establecer mejores conexiones con las metas de negocio, especialmente donde se entrecruzan distintas áreas de una organización, o incluso participan más de una organización.

3. Se refuerza el concepto de compromiso y calidad.

4. Permite monitorear y validar la calidad de los servicios.

5. Brinda mayor proyección a futuro: sobrevivirán aquellos servicios con reglas claras de uso. Esto permite por ejemplo, ofrecer distinta calidad de SLA a distintos actores. Por ejemplo, 1000 transacciones por segundo a usuarios VIP y 650 por segundo a usuarios estándar.

Ya establecido el marco necesario de un SLA se describe a continuación su aplicación dentro de arquitecturas SOA.
SLA en arquitecturas SOA

En una arquitectura SOA actual es común la integración con servicios externos con grandes compañías como Amazon, StrikeIron o Ebay. Se trabaja en un entorno hiperconectado en donde asegurar la calidad de los servicios prestados es un gran desafío. Esto se debe fundamentalmente a que Internet como fuente de comunicación es altamente dinámica e impredecible, en especial por los siguientes aspectos:

● Escasa presencia de protocolos estandarizados de comunicación.
● Vulnerabilidad a ataques de seguridad.
● Fallas de infraestructura, como la ocurrida con el daño de un cable subterráneo que detuvo toda actividad por días en el este europeo, África y Asia en 2008 [4].

Un SLA es crucial para asegurar la calidad del servicio brindado. Cuando es debidamente negociado y documentado es de gran utilidad al arquitecto SOA para testear y poner en producción nuevos servicios. Para lograr este efecto se debe proveer suficiente información o métricas validables para los consumidores del servicio para poder pre-seleccionarlos basados en los estándares de calidad deseados. Esta información le permite entonces al arquitecto no desperdiciar tiempo y recursos evaluando servicios que no se adaptarán a las necesidades del proyecto.
Las métricas más comunes para definir SLA en arquitectura SOA son la latencia, el número máximo de transacciones por minuto, el costo por invocación y el porcentaje de tiempo disponible del servicio (por ejemplo: 99% de tiempo disponible).

Expresar y monitorear SLA

Si bien para escribir SLAs suele utilizarse habitualmente texto en lenguaje natural utilizando "templates", existen tambien diversos estándares tales como Web Service Level Agreement (WSLA) language y WS-Policy que son utilizados por servicios web en ambientes SOA. Estos estándares son impulsados por companias como IBM, Oracle, Microsoft, SAP, Sonic y VeriSign.

Por otro lado la tendencia indica que es cada vez mayor el uso de herramientas para definir y monitorear SLA. A continuación se introduce una tabla con algunas de las herramientas más utilizadas, y una breve comparación de sus características:

Nombre Vendedor Características
Oracle Web Services Manager Oracle Creación y manejo de políticas de uso de servicios
Utilización de dashboards
Agrupación en jerarquías para la definición de contratos de servicios
Policy Manager Akana  MultiplataformaAdaptable a diferentes lenguajes
No invasivo
Aplicación de métricas y estadísticas
Resolución de conflictos a través de políticas de mediación
Applications Manager Manage Engine Alertas y monitoreo anticipando posibles violaciones SLA
Posibilidad de monitorear estructuras heterogéneas
(base de datos, servicios web, servidores emails, etc)
System Center Global Service Monitor Microsoft Monitoreo Servicios en la nubeSLA sobre URL’s simples y de pasos múltiples incluyendo autenticación
Configuración de permisos de visibilidad y utilización
Visualización detallada de la utilización de servicios

Referencias:

[1] http://www.sei.cmu.edu/

[2] http://www.sei.cmu.edu/reports/08tn021.pdf

[3] http://www.afutt.org/Qostic/qostic1/SLA-DI-USG-TMF-060091-SLA_TMForum.pdf

[4] BBC News. Severed Cables Disrupt Internet (2008).

Top Insights

Ciclos de vida BPM

Ciclos de vida BPM

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Criterios de Aceptación

Criterios de Aceptación

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Escribiendo User Stories en Agile

Escribiendo User Stories en Agile

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
What is TM Forum Frameworx and how to apply it to your business?

What is TM Forum Frameworx and how to...

UncategorizedAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Impact Mapping en Metodologías ágiles

Impact Mapping en Metodologías ágiles

AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Top Authors

Axel Salmeron

Axel Salmeron

Sr Developer

Nicolas Cieri

Nicolas Cieri

Solution Architect

Alvaro Soria

Alvaro Soria

Solution Architect

Sergio Fiorillo

Sergio Fiorillo

Engineering Manager

Pablo Alvarez

Pablo Alvarez

Delivery Director, Finance & Commerce

Blog Categories

  • URL copied!