0% encontró este documento útil (0 votos)
43 vistas12 páginas

Ibm Challenge

Este documento especifica los requisitos funcionales y técnicos para dos microservicios que deben ser implementados como parte de un desafío. El Microservicio 1 recibe y ordena arrays de valores, mientras que el Microservicio 2 calcula estadísticas sobre arrays numéricos. Cada microservicio debe tener dos versiones desplegadas con diferentes comportamientos. Se evalúa el cumplimiento de los requisitos a través de pruebas automatizadas.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
43 vistas12 páginas

Ibm Challenge

Este documento especifica los requisitos funcionales y técnicos para dos microservicios que deben ser implementados como parte de un desafío. El Microservicio 1 recibe y ordena arrays de valores, mientras que el Microservicio 2 calcula estadísticas sobre arrays numéricos. Cada microservicio debe tener dos versiones desplegadas con diferentes comportamientos. Se evalúa el cumplimiento de los requisitos a través de pruebas automatizadas.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 12

Table of Contents

1. Alcance 1
2. Requerimientos Funcionales: 2
3. Especificación Técnica de los Servicios 3
Modelo de Evaluación 3
Documentación Microservicio 1 version 1.0: 3
POST /element_sorter 4
Documentación Microservicio 1 version 1.1: 5
POST /element_sorter 5
Documentación Microservicio 2 version 1.0: 6
POST /statistics 7
Documentación Microservicio 2 version 1.1: 8
POST /statistics 8
Documentación Servicio de Validación: 10
POST /validate-exercise 10
4. Material de Educación 12

1. Alcance
En un pasado cercano en que los servidores tardaban semanas en aprovisionarse y minutos en
iniciarse, estaba de moda alardear de cuánto tiempo podría mantener sus servidores funcionando sin
fallas. El hardware era costoso y cuantas más aplicaciones pudieras empacar en un servidor, menores
serían los costos de funcionamiento. La alta disponibilidad (HA) se manejó mediante el uso de pares
de servidores, y el escalamiento se realizaba de forma vertical, agregando más núcleos a una máquina.
Cada servidor era único, precioso.

Los tiempos han cambiado. El hardware está virtualizado. Además, con tecnologías de
contenerización, como Containerd/Docker, puede reducir al mínimo el sistema operativo circundante
para que pueda iniciar un proceso aislado en segundos, como máximo. En esta nueva infraestructura,
típicamente basada en la nube, el escalado puede ser horizontal, agregando y eliminando servidores
o contenedores a voluntad, y pagando solo por lo que usa. Con esa libertad, ahora puede implementar
"capas delgadas" de lógica de aplicaciones en tiempos de ejecución minimalistas en contenedores
independientes y livianos. Ejecutar mucho más que solo un par de contenedores es común y limita los
efectos de la caída de un contenedor. Mediante el uso de marcos de orquestación de contenedores,
como Kubernetes, se puede introducir o eliminar contenedores rápidamente para escalar cargas de
trabajo hacia arriba y hacia abajo. Hoy es posible tenerlo TODO definido por código, haciendo posible
nuevos niveles de agilidad y resiliencia, aplicando DevSecOps de punta a punta.
Con el reto IBM queremos incentivar a los concursantes a adquirir los conocimientos que les permitan
dominar esta nueva realidad, mediante la construcción de una prueba de concepto sencilla en IBM
Cloud.

Quienes se inscriban, recibirán un código promocional que les permitirá contar con la capacidad
necesaria para desarrollar, probar y poner en producción su prueba de concepto. También vamos a
proveer links y documentación que sirva de guía en este desarrollo.

2. Requerimientos Funcionales:
El concursante deberá crear dos microservicios, cada uno con dos versiones distintas desplegadas en
producción:

● Microservicio 1: Recibe un arreglo no ordenado de valores escalares, numéricos y


alfanuméricos, ejecuta un algoritmo de ordenamiento y devuelve el resultado.
o La versión 1.0 del microservicio realiza su ordenamiento considerando a todos los
elementos del arreglo como cadenas tipo string y retorna un JSON con los valores
ordenados (ver la especificación del microservicio)

o La versión 1.1 divide el arreglo en dos partes: 1) numéricos y 2) alfanuméricos, los


ordena por separado y retorna un JSON con la siguiente lógica (ver la especificación
del microservicio):
● En un campo retorna los valores numéricos ordenandos.
● En otro campo retorna los alfanuméricos descartados.

● Microservicio 2: Recibe un arreglo no ordenado de valores escalares numéricos y devuelve, un


objeto JSON con los campos (ignora cualquier valor no-numérico recibido):
o count (cuenta total de elementos del arreglo)
o average (promedio de los valores entregados)
o median (media aritmética de los valores)
o mode (moda estadística)
o max (valor máximo del arreglo)
o min (valor mínimo del arreglo)
o stdev (desviación estándar)

o La versión 1.0 del microservicio ignora cualquier valor no-numérico recibido.

o La versión 1.1 agrega al objeto JSON un campo llamado "discardedElements" con un


arreglo de los valores no-numéricos recibidos.

Los microservicios deberán desplegarse en contenedores independientes y deben requerir


autenticación básica para ser llamados.

Los usuarios y contraseñas que se usarán son:

● Para los robots:


User: ibm_test_robot_1
Password: ibm_test_1.123#

User: ibm_test_robot_2
Password: ibm_test_2.123#

User: ibm_test_robot_3
Password: ibm_test_3.123#

El despliegue de la solución deberá incluir reglas de ruteo para dirigir los requerimientos recibidos de
acuerdo con las siguientes reglas:

● Microservicio 1: el 80% de los requerimientos los atenderá la versión 1.0 y el 20% la versión 1.1
● Microservicio 2: los requerimientos del usuario ibm_test_robot_1 serán atendidos por la
versión 1.0. Los requerimientos de los demás usuarios serán atendidos por la versión 1.1

3. Especificación Técnica de los Servicios

Modelo de Evaluación

Los concursantes deberán proveer el endpoint para los servicios construidos. Este endpoint deberá
estar hosteado en la nube de IBM (*.appdomain.cloud). Una vez que el concursante haya completado
el reto deberá subir su respuesta en el formulario provisto en devsucodejam.com/ibm. Al ingresar sus
datos, se ejecutará pruebas automatizadas y evaluará los resultados, confirmado que cumplen con los
esquemas descritos en la especificación técnica y que la distribución de carga no tuvo una desviación
mayor al 3% en ninguno de los casos.

En caso de que no cumpla con las especificaciones, se mostrará un mensaje de error, y el usuario
podrá hacer las correcciones necesarias y volver a subir su información.

El usuario concursante que complete exitosamente la prueba recibirá un correo electrónico con un
número de boleto para participar en el sorteo. El sorteo se realizará una vez que haya culminado la
final del Devsu Code Jam, el 30 de noviembre de 2019, en la UDLA, Campus Queri, en Quito.

Documentación Microservicio 1 version 1.0:

Version: 1.0.0
BasePath:/ibmchallengemic1

Access

1. Basic Auth

Methods:

● POST /element_sorter
POST /element_sorter

Receives a set of values and returns them back sorted


Consumes
This API call consumes the following media types via the Content-Type request header:

● application/json

Request body
Example data
Content-Type: application/json

{
"elements" : [1, "a", 12.4, "text"]
}

Produces
This API call produces the following media types according to the Accept request header; the media
type will be conveyed by the Content-Type response header.

● application/json

Responses:

200
200 OK
When request is success:
status: “success”
message: “ok”

400
400 Bad Request
When request has wrong values or generate any kind of error:
status: “error”
message: error message

Example ok data
Content-Type: application/json

{
"status": "success",
"message": "ok",
"data": {
"sorted": ["1", "12.4", "a", "text"]
}
}
Example data error message:
Content-Type: application/json

{
"status": "error",
"message": "The method add(Object, String) in the type ArrayList<String> is not applicable for the
arguments (Object)",
}

Documentación Microservicio 1 version 1.1:

Version: 1.1.0
BasePath:/ibmchallengemic1

Access

1. Basic Auth

Methods

● POST /element_sorter

POST /element_sorter

Receives a set of values and returns them back sorted


Consumes
This API call consumes the following media types via the Content-Type request header:

● application/json

Request body
Example data
Content-Type: application/json

{
"elements" : [25,4,”","Banana", "Orange", "Apple", "Mango",1]
}

Produces
This API call produces the following media types according to the Accept request header; the media
type will be conveyed by the Content-Type response header.

● application/json

Responses:
200
200 OK
When request is success:
status: “success”
message: “ok”

400
400 Bad Request
When request has wrong values or generate any kind of error:
status: “error”
message: error message

Example data
Content-Type: application/json

{
"status": "success",
"message": "41",
"data": {
"numbers": [1, 4, 25],
“others”:["Apple", "Banana", "Mango", "Orange"]
}
}

Example data error message:


Content-Type: application/json

{
"status": "error",
"message": "The method add(Object, String) in the type ArrayList<String> is not applicable for the
arguments (Object)",
}

Documentación Microservicio 2 version 1.0:

Version: 1.0.0
BasePath:/ibmchallengemic2

Access

1. Basic Auth

Methods

● POST /statistics
POST /statistics

Receives a set of values and returns statistics data


Consumes
This API call consumes the following media types via the Content-Type request header:

● application/json

Request body
Example data
Content-Type: application/json

{
"elements" : [“a”,1,4,5,”1”,7,8,4,3,0,”texto”]
}

Produces
This API call produces the following media types according to the Accept request header; the media
type will be conveyed by the Content-Type response header.

● application/json

Responses:

200
200 OK
When request is success:
status: “success”
message: “ok”

400
400 Bad Request
When request has wrong values or generate any kind of error:
status: “error”
message: error message

Example data
Content-Type: application/json

{
"status": "success",
"message": "ok",
"data" : {
"mode" : 4.0,
"average" : 4.0,
"min" : 0.0,
"max" : 8.0,
"median" : 4.0,
"count" : 8,
"stdev" : 2.725540575
},
}

Example data error message:


Content-Type: application/json

{
"status": "error",
"message": "The method add(Object, String) in the type ArrayList<String> is not applicable for the
arguments (Object)",
}

Documentación Microservicio 2 version 1.1:

Version: 1.1.0
BasePath:/ibmchallengemic2

Access

1. Basic Auth

Methods

● POST /statistics

POST /statistics

Receives a set of values and returns statistics data


Consumes
This API call consumes the following media types via the Content-Type request header:

● application/json

Request body
Example data
Content-Type: application/json

{
"elements" : [“a”,1,4,5,”1”,7,8,4,3,0,”texto”]
}

Produces
This API call produces the following media types according to the Accept request header; the media
type will be conveyed by the Content-Type response header.
● application/json

Responses:

200
200 OK
When request is success:
status: “success”
message: “ok”

400
400 Bad Request
When request has wrong values or generate any kind of error:
status: “error”
message: error message

Example data
Content-Type: application/json

{
"status": "success",
"message": "ok",
"data" : {
"mode" : 4.0,
"average" : 4.0,
"min" : 0.0,
"max" : 8.0,
"median" : 4.0,
"count" : 8,
"stdev" : 2.725540575,
"discardedElements" : [”a”,”1”, “texto”]
},
}

Example data error message:


Content-Type: application/json

{
"status": "error",
"message": "The method add(Object, String) in the type ArrayList<String> is not applicable for the
arguments (Object)",
}
Documentación Servicio de Validación:

Version: 1.0.0

End Point URL: https://us-south.functions.cloud.ibm.com/api/v1/namespaces/e4740ab8-


3670-46d5-a803-8c42e856b4ce/actions/sumbission/validate-exercise

Access

1. Basic Auth

Methods:

● POST /validate-exercise

POST /validate-exercise

Para consumir el servicio de validación los atributos requeridos son:

1. URL del end point en donde se encuentran los microservicios para consumirlos con el robot
2. Se debe ejecutar el siguiente comando desde la terminal:

# kubectl get pods --all-namespaces -o wide

La salida del comando debe ser codificada en un string base 64.


3. ID del robot que podemos utilizar
4. Email del usuario participante

Consumes
This API call consumes the following media types via the Content-Type request header:

● application/json

Request body
Example data
Content-Type: application/json

{
"endpoint" : https://xxxxx appdomain.cloud/,
“commandOut”:
“QXZhaWxhYmxlIENvbW1hbmRzOgogIGN1cnJlbnQtY29udGV4dCBEaXNwbGF5cyB0aGUgY3VycmVud
C1jb250ZXh0CiAgZGVsZXRlLWNsdXN0ZXIgIERlbGV0ZSB0aGUgc3BlY2lmaWVkIGNsdXN0ZXIgZnJvbSB0
aGUga3ViZWNvbmZpZwogIGRlbGV0ZS1jb250ZXh0ICBEZWxldGUgdGhlIHNwZWNpZmllZCBjb250ZXh0
IGZyb20gdGhlIGt1YmVjb25maWcKICBnZXQtY2x1c3RlcnMgICAgRGlzcGxheSBjbHVzdGVycyBkZWZpb
mVkIGluIHRoZSBrdWJlY29uZmlnCiAgZ2V0LWNvbnRleHRzICAgIERlc2NyaWJlIG9uZSBvciBtYW55IGNvb
nRleHRzCiAgcmVuYW1lLWNvbnRleHQgIFJlbmFtZXMgYSBjb250ZXh0IGZyb20gdGhlIGt1YmVjb25maW
cgZmlsZS4KICBzZXQgICAgICAgICAgICAgU2V0cyBhbiBpbmRpdmlkdWFsIHZhbHVlIGluIGEga3ViZWNvb
mZpZyBmaWxlCiAgc2V0LWNsdXN0ZXIgICAgIFNldHMgYSBjbHVzdGVyIGVudHJ5IGluIGt1YmVjb25ma
WcKICBzZXQtY29udGV4dCAgICAgU2V0cyBhIGNvbnRleHQgZW50cnkgaW4ga3ViZWNvbmZpZwogIHN
ldC1jcmVkZW50aWFscyBTZXRzIGEgdXNlciBlbnRyeSBpbiBrdWJlY29uZmlnCiAgdW5zZXQgICAgICAgICA
gIFVuc2V0cyBhbiBpbmRpdmlkdWFsIHZhbHVlIGluIGEga3ViZWNvbmZpZyBmaWxlCiAgdXNlLWNvbnRl
eHQgICAgIFNldHMgdGhlIGN1cnJlbnQtY29udGV4dCBpbiBhIGt1YmVjb25maWcgZmlsZQogIHZpZXcgIC
AgICAgICAgICBEaXNwbGF5IG1lcmdlZCBrdWJlY29uZmlnIHNldHRpbmdzIG9yIGEgc3BlY2lmaWVkIGt1Y
mVjb25maWcgZmlsZQ==”
“userid”:””,
“useremail”:”[email protected]
}

Produces
This API call produces the following media types according to the Accept request header; the media
type will be conveyed by the Content-Type response header.

● application/json

Responses:

200
200 OK
When request is success:
status: “success”
message: “ok”

400
400 Bad Request
When request has wrong values or generate any kind of error:
status: “error”
message: error message

Example ok data
Content-Type: application/json

{
"status": "success",
"message": "ok"
}

Example data error message:


Content-Type: application/json

Examples:
Case 1:
{
"status": "error",
"message": "Servicio no responde"
}

Case 2:
{
"status": "error",
"message": "Error de autenticación"
}

Case 3:
{
"status": "error",
"message": "Comando incorrecto"
}

4. Material de Educación

Los concursantes pueden utilizar el siguiente material de estudio para adquirir los
conocimientos necesarios para construir este API:
https://developer.ibm.com/series/kubernetes-learning-path/

También podría gustarte