Osd 2016 Middleware Track

1. MIDDLEWARE TRACK A cura del Middleware Solution Architect team di Red Hat #redhatosd

2. Agenda Middleware Track part 1 ● 14.00 MicroServices, le dimensioni non contano ○ Ugo Landini, Samuele Dell’Angelo ● 14.30 Wildfly Swarm, Spring Boot & Vertx.io: il nuovo che avanza ○ Ugo Landini, Samuele Dell’Angelo ● 15.00 Microservices con JBoss EAP 7: innovare in continuità ○ Giuseppe Bonocore ● 15.30 Microregole per grandi progetti con il BRMS ○ Andrea Leoncini

3. Agenda Middleware Track part 2 ● 16.00 Integrazione e microservizi: come un cammello può passare dalla cruna di un ago ○ Filippo Calà, Giuseppe Bonocore ● 16.30 API Management con 3Scale nell’era dei microservizi ○ Luca Bigotta ● 17.00 SALA PLENARIA ● 17.15 ESTRAZIONE FINALE PREMI

4. #redhatosd

5. MicroServices: le dimensioni non contano Ugo Landini & Samuele Dell’Angelo #redhatosd

7. 10 Deploy al giorno Come è possibile?

8. Cos’è una Microservice Architecture (MSA)? Un approccio architetturale per decomporre applicazioni complesse in sistemi indipendenti ● Organizzati per business capabilities ● Scalabilità indipendente ● Ciclo di vita indipendente ● Governo decentralizzato ● Data management decentralizzato

9. Cos’è una Microservice Architecture (MSA)? Picco di aspettative gonfiate x Disillusione Qui si fa sul serio

10. Your Journey to Microservices :-) Self-Service, On-Demand, Elastic, Infrastructure as Code (Cloud) Re-Org -> DevOps Automazione: Puppet, Chef, Ansible e/o Containers CI & CD Deployment Pipeline Un Microservizio Silicon Valley DotCom Startup Cos’è una Microservice Architecture (MSA)?

11. 1. Self-Service, on-demand, elastic infrastructure as code a. Quanti gg per il provisioning di una nuova VM? 2. Dev vs Ops Chi risponde al telefono se l’app non funziona? 3. Automation Phoenix vs Snowflake 4. CI & CD a. Deployment Pipeline Cos’è una Microservice Architecture (MSA)?

12. Cos’è una Microservice Architecture (MSA)? GREEN BROWN

13. A Development / Deployment Time: ● Automation ● Continuous Integration / Delivery ● Configuration Management ● Service / API design ● Rigorous Testing ● Dependency management ● Design for eventual consistency ● Artifact repositories Container: standardizzazione, automation e dependency management User Experience: maggiore produttività per gli sviluppatori A Runtime: ● Standardization ● Isolation ● Service Discovery ● Load Balancing ● Circuit Breaker, Fallback ● Health checks & automated recovery ● Distributed logging ● Tracing ● Infrastructure Monitoring

14. ● Deploy facile e portabile ● Creato da immagini immutabili e a strati (layered) ● Isolato dal sistema operativo dell’host. I Container impacchettano le applicazioni con le loro dipendenze, isolando il runtime Alta densità e massima efficienza HOST OS SERVER CONTAINER LIBS APP CONTAINER LIBS APP

15. DEMO BUILD YOUR OWN CONTAINER IN 50 lines

16. ● Isolati e sicuri ● Sembrano girare in un loro ambiente ● Se ne possono far girare centinaia in una sola macchina ● Le funzionalità sono nel kernel ● Docker è semplicemente un formato I Container sono dei semplici processi Linux Alta densità e massima efficienza HOST OS SERVER CONTAINER LIBS APP CONTAINER LIBS APP

17. Kubernetes è un container orchestrator per le applicazioni (non per le macchine) Dal greco “pilota”: radice della parola “governatore” (dal latino: gubernator) Master Node Bare Metal Virtual Private Cloud Public Cloud Storage Operator External Services

18. A Development / Deployment Time: ● Automation ● Continuous Integration / Delivery ● Configuration Management ● Service / API design ● Rigorous Testing ● Dependency management ● Design for eventual consistency ● Artifact repositories Kubernetes aggiunge caratteristiche fondamentali per le MSAs (e non solo!) Kubernetes è la versione open di Borg, il sistema usato internamente da Google per scalare. A Runtime: ● Standardization ● Isolation ● Service Discovery ● Load Balancing ● Circuit Breaker, Fallback ● Health checks & automated recovery ● Distributed logging ● Tracing ● Infrastructure Monitoring

19. OpenShift Container Platform è la versione ENTERPRISE di Kubernetes SERVICE CATALOG (LANGUAGE RUNTIMES, MIDDLEWARE, DATABASES, …) SELF-SERVICE APPLICATION LIFECYCLE MANAGEMENT (CI / CD) BUILD AUTOMATION DEPLOYMENT AUTOMATION CONTAINER CONTAINERCONTAINER CONTAINER CONTAINER NETWORKING SECURITYSTORAGE REGISTRY LOGS & METRICS CONTAINER ORCHESTRATION & CLUSTER MANAGEMENT (KUBERNETES) RED HAT ENTERPRISE LINUX CONTAINER RUNTIME & PACKAGING (DOCKER) ATOMIC HOST INFRASTRUCTURE AUTOMATION & COCKPIT

20. A Development / Deployment Time: ● Automation ● Continuous Integration / Delivery ● Configuration Management ● Service / API design ● Rigorous Testing ● Dependency management ● Design for eventual consistency ● Artifact repositories Openshift Container Platform aggiunge ulteriori servizi per gli sviluppatori Il developer si deve concentrare solo sul design & development dei microservizi A Runtime: ● Standardization ● Isolation ● Service Discovery ● Load Balancing ● Circuit Breaker, Fallback ● Health checks & automated recovery ● Distributed logging ● Tracing ● Infrastructure Monitoring

21. Wildfly Swarm, Vertx.io & Spring Boot: Il nuovo che avanza Ugo Landini & Samuele Dell’Angelo #redhatosd

22. MicroProfile 1.0! Ottimizzare Enterprise Java per i Microservices Microservice Collaboration and Innovation in the Java Community Learn more @ microprofile.io

23. DropWizard www.dropwizard.io JAX-RS API Il primo sul mercato DropWizard Metrics Embeddable servers: Jetty Spring Boot projects.spring.io/spring-boot Spring API (@RestController) ‘Starter’ POMs: start.spring.io Embeddable servers: Tomcat, Jetty, Undertow WildFly Swarm wildfly-swarm.io Java EE 7 APIs ‘Starter’ POMs: wildfly-swarm.io/generator Embeddable servers: WildFly (Undertow) Opinionated & java -jar myapp.jar

24. ● Stesse tecnologie di JBoss, ma diverso punto di vista ● Si “monta” tanto Application Server quanto basta per il servizio ○ MicroProfile 1.0 ○ Flat jar ○ Interfaccia web o via JBoss Forge per scegliere cosa serve

25. (Un-Opinionated) Toolkit per applicazioni reactive & async Low-latency microservices che interagiscono con l’EventBus Elasticità e resilienza “built-in” Democratico, parla con tutti (.NET, Go, Ceylon, Rust, Cobol, Java EE, Spring...) vertx.io http://vertx.io/blog/my-first-vert-x-3-application/

26. Vert.x EventBus Verticle1 Verticle2 Verticle3 Verticle4 Verticle5 JVM Vert.x Instance Verticle1 Verticle2 Verticle6 Verticle7 JVM Vert.x Instance vertx.eventBus

27. DEMO VERTX.IO, SWARM & SB & All in One

28. Release It! Michael T. Nygard (Java outdated, ma le storie dei fallimenti sono eccezionali) Il libro che ha inventato il Circuit Breaker

29. Service A Service B Circuit Breaker

30. Service A Service B Hystrix - circuit-breaker, bulkhead

31. Distributed Tracing

32. App tradizionali Microservizi

33. Virtuale Cloud Fisico App tradizionali Microservizi

34. Red Hat xPaas Application Server Pivotal tc Server, VMware vFabric, Oracle WebLogic Server, IBM WebSphere JBoss EAP JBoss Web Server In-memory data grid IBM WebSphere eXtreme Scale, Oracle Coherence, Pivotal GemFire, Software AG Terracotta JBoss Data Grid Application integration IBM Integration Bus, Oracle SOA Suite and ESB, MuleSoft AnyPoint Platform, Sonic ESB, Tibco ActiveMatrix JBoss Fuse Business rules and process automation IBM Operational Decision Manager and BPM, Oracle SOA Suite and BPM Suite, Pega BPM, FICO Blaze Advisor JBoss BRMS JBoss BPM Suite Messaging IBM WebSphereMQ, Pivotal RabbitMQ, VMware vFabric, Tibco Enterprise Message Service JBoss A-MQ Mobile IBM MobileFirst, SAP Mobile Platform, Kony Mobility Platform, Telerik Platform, AnyPresence Mobile Application Platform Data virtualization and data services IBM InfoSphere, Progress DataXtend SI, Composite Information Server, Denodo JBoss Data Virtualization

35. Links Microservices Playground bit.ly/msa-instructions http://developers.redhat.com/downloads Container Development Kit Recorded Demo: https://youtu.be/SPATMHP-xw8 https://github.com/redhat-italy/osd-microservices-apps OSD Demo Applications

36. MICROSERVICES con EAP7: Innovare in continuità Giuseppe Bonocore #redhatosd

37. JBoss Enterprise Application Platform ● Basato su WildFly ○ Hibernate, CXF, Infinispan... ● Utilizzato da migliaia di aziende in Italia e nel mondo ○ Banking, Telco, Utility, mission critical ● Semplice e performante ○ Packaging, boot time, performance #1 Open Source JEE Server

38. Enterprise Application Platform 7 ● JEE 7 certified ○ WebSocket, batch, JSon ● Semplificazione ○ Port reduction, graceful shutdown ● Consolidamento ○ Undertow, Artemis Cosa c’è di nuovo

39. Enterprise Application Platform 7 ● AngularJS ● Arquillian ● jQuery, jQuery Mobile ● Spring (Web Flow, WS, Security) Tested Frameworks

40. Enterprise Application Platform 7 Scenari Fisico Virtuale Cloud Applicazioni Tradizionali Microservizi

41. Enterprise Application Platform 7 Scenari Applicazioni Tradizionali Microservizi

42. Enterprise Application Platform 7 ● Microservizi in Java: UberJar con Hibernate, CXF, Log4j… ○ Il rischio è di ricostruire un application server… ● EAP: Ottimizzato per i Microservizi ○ Boot time in 2 sec (circa), lazy loading modules, 2 (o 1) porte, containerizzabile, scriptabile Microservices in JEE ?!?!

43. Enterprise Application Platform 7 ● Riutilizzo di codice e skills ○ JEE features in un microservizio (Clustering con OSE !) ● Hipster ready :-) ○ Wildfly Swarm, JS Server side Microservices in JEE ?!?!

44. EAP S2i Nome App Puntamenti GIT

45. Enterprise Application Platform 7 Red Hat xPaas Enterprise Application Platform JBoss Web Server (Tomcat) JBoss Data Grid JBoss Developer Studio Fuse A-MQ Data Virtualization * Business Process Management * Business Rules Management System Red Hat Mobile / FeedHenry Application Container Services Integration Services Business Process Services Mobile Services * Coming Soon

46. Enterprise Application Platform 7 Red Hat xPaas OPENSHIFT CONTAINER PLATFORM Red Hat Enterprise Linux Red Hat Enterprise Linux Red Hat Enterprise Linux Container ContainerJBoss EAP JBoss Data Grid JBoss Fuse Container JBoss A-MQ ContainerJBoss BRMS ORCHESTRATION

47. Architettura

48. OpenShift può girare su qualsiasi tipo di infrastruttura

49. I nodi sono istanze di RHEL

50. I servizi girano in container Docker

51. Registry I Pod eseguono uno o più docker container

52. I Master orchestrano i nodi e le app

53. I Master forniscono API per autenticazione di utenti & client

54. I Master usano etcd per la persistenza

55. I Master forniscono lo scheduler per la gestione dei pod sui nodi

56. Il posizionamento dei Pod è determinato da una policy

57. I Service permettono ai pods di connettersi l’un l’altro

58. I Management/Replication controller gestiscono il ciclo di vita dei pod

59. OpenShift gestisce il recover in automatico

60. OpenShift gestisce il recover in automatico

61. I Pods possono connettersi ad uno shared storage

62. Il Routing layer “ruota” richieste esterne ai pod

63. I Dev accedono ad openShift via web, CLI o IDE

67. MicroRegole per grandi progetti con il BRMS Andrea Leoncini #redhatosd

68. La comunità Drools Workbench (web UI per la redazione e la gestione delle regole) Expert (Rule Engine) Fusion (CEP, Complex Event Processing) jBPM (integrazione con processi) OptaPlanner (pianificazione delle risorse)

69. Cos’è un motore di regole (Rule Engine)? A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation ("An employee can be fired for any reason or no reason but not for an illegal reason"), company policy ("All customers that spend more than $100 at one time will receive a 10% discount"), or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from application code. Source: wikipedia

70. DROOLS/Red Hat JBoss BRMS ● Vantaggi di un Motore di Regole: ○ Permette di dire "COSA fare", e non "COME farlo". ○ Separazione della logica e dei dati ○ Centralizzazione della conoscenza ○ Integrazione dei Tool ○ Regole Understandable ○ Velocità e Scalabilità

71. Quando dovreste usare Red Hat JBoss BRMS ● Scenari molto complessi, difficili da definire anche per i business experts ● Non esiste o non è noto un ben definito algoritmo ● Requisiti che hanno bisogno di essere modificati molto spesso ● Necessità di prendere decisioni molto velocemente, spesso su set di dati non completi

72. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated() ) then // sound the alarm end Una semplice regola Una semplice regola CEP, senza il concetto di tempo

73. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated() ) then // sound the alarm end Una semplice regola Nome Regola Una semplice regola CEP, senza il concetto di tempo

74. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated() ) then // sound the alarm end Una semplice regola LHS Una semplice regola CEP, senza il concetto di tempo

75. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated() ) then // sound the alarm end Una semplice regola Una semplice regola CEP, senza il concetto di tempo RHS

76. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated( this after[0s,10s] $f ) ) then // sound the alarm end Una semplice regola CEP Una semplice regola CEP, con il concetto di tempo

77. rule "Sound the alarm" when $f : FireDetected( ) not( SprinklerActivated( this after[0s,10s] $f ) ) then // sound the alarm end Una semplice regola CEP Una semplice regola CEP, con il concetto di tempo TEMPO

78. CEP con il BRMS Complex Event Processing: accorgersi di eventi significativi per il business riconoscendo time-based patterns in uno o più data feed in real-time... ● Regola + Tempo: aggiunge il concetto di tempo alle regole base ○ Sliding windows ○ Entry points ○ Time operations

79. Rule Engine taglia slim ● Possibilità di invocare le regole ○ localmente al runtime ○ da remoto ● Deploy ○ JEE ○ OSGI ○ Wildfly Swarm ○ Spring-Boot ○ Java standalone ○ Docker

80. Lanciamo la campagna Pro If ● Non preoccupatevi se la logica della vostra applicazione è piena di If. ● Soprattutto non preoccupatevi se non l’avete capito subito... ● Lanciamo ufficialmente la campagna Pro If ○ Gli if dal codice li togliamo noi!

81. Scenario di deploy

82. KIE factor Sviluppatori e analisti lavorano ai progetti e producono regole, servizi, modelli di dati e processi

83. KIE factor La build dei progetti produce i cosiddetti “artefatti”

84. KIE factor L’Execution Server prende gli artefatti con cui crea la propria base di conoscenza direttamente dal server Maven

85. KIE factor L’Execution Server può essere eseguito nel “Java Flavour” preferito.

86. Uso del Rule Engine

87. Uso del Rule Engine Un Engine “Specializzato” No scanner, uno specifico GAV, integrato nella mia pipeline di rilascio

88. E se serve un motore di regole scalabile ed in alta affidabilità? HACEP: https://github.com/redhat-italy/hacep/ ● Si possono gestire, grazie a JBoss Data Grid, un certo numero di Engine contemporanei ○ Mantenendo contemporaneamente copie di backup ● Distribuzione degli eventi per uno o più gruppi uniformi (carta di credito, utente, giocatore, ecc.) ● Scalabilità fino a centinaia di nodi ● Prestazioni del cluster direttamente proporzionali al numero di nodi BRMS

89. HACEP: https://github.com/redhat-italy/hacep/

90. DEMO RULE BRMS

94. Integrazione e Microservizi: come un cammello può passare dalla cruna di un ago Filippo Calà & Ugo Landini #redhatosd

95. Che cosa NON è Apache Camel? Non è un Enterprise Service Bus

96. Che cos’è Apache Camel? Camel è un potente Framework Open Source di Integrazione basato sugli Enterprise Integration Pattern

97. Che cos’è Apache Camel? JBoss Fuse Open Source Lightweight Integration Platform

98. Che cos’è Apache Camel? JBoss Fuse Architettura modulare e capacità di integrazione

99. Che cos’è Apache Camel? JBoss Fuse JBoss Fuse include Apache Camel

100. Che cos’è Apache Camel? JBoss Fuse Facile da estendere

101. Che cos’è Apache Camel? JBoss Fuse Facile da gestire

102. Che cos’è Apache Camel? JBoss Fuse Fa tutto quello che fanno gli ESB e molto di più

103. Integration Framework

104. Enterprise Integration Patterns

107. Enterprise Integration Patterns Content Based Router

108. Enterprise Integration Patterns Content Based Router from newOrder

109. Enterprise Integration Patterns Content Based Router from newOrder choice

110. Enterprise Integration Patterns Content Based Router from newOrder choice when isWidget to widget

111. Enterprise Integration Patterns Content Based Router from newOrder choice when isWidget to widget otherwise to gadget

112. Enterprise Integration Patterns Content Based Router from (newOrder) choice when (isWidget) to (widget) otherwise to (gadget)

113. Enterprise Integration Patterns Content Based Router from (newOrder) .choice() .when(isWidget) .to(widget) otherwise().to(gadget);

114. Enterprise Integration Patterns Content Based Router from (newOrder) .choice() .when(isWidget) .to(widget) otherwise().to(gadget);

115. Enterprise Integration Patterns Content Based Router from (newOrder) .choice() .when(isWidget) .to(widget) otherwise().to(gadget); Endpoint newOrder = endpoint("activemq:queue:newOrder");

116. Enterprise Integration Patterns Content Based Router from (newOrder) .choice() .when(isWidget) .to(widget) otherwise().to(gadget); Endpoint newOrder = endpoint("activemq:queue:newOrder"); Predicate isWidget = xpath("/order/product = 'widget'");

117. Enterprise Integration Patterns Content Based Router from (newOrder) .choice() .when(isWidget) .to(widget) otherwise().to(gadget); Endpoint newOrder = endpoint("activemq:queue:newOrder"); Predicate isWidget = xpath("/order/product = 'widget'"); Endpoint widget = endpoint("activemq:queue:widget"); Endpoint gadget = endpoint("activemq:queue:gadget");

118. Enterprise Integration Patterns Java DSL import org.apache.camel.builder.RouteBuilder; public class MyRoute extends RouteBuilder { public void configure() throws Exception { from("activemq:queue:newOrder") .choice() .when(xpath("/order/product = 'widget'")) .to("activemq:queue:widget") .otherwise() .to("activemq:queue:gadget"); } }

119. Enterprise Integration Patterns XML DSL <route> <from uri="activemq:queue:newOrder"/> <choice> <when> <xpath>/order/product = 'widget'</xpath> <to uri="activemq:queue:widget"/> </when> <otherwise> <to uri="activemq:queue:gadget"/> </otherwise> </choice> </route>

120. Architecture

121. Componenti

122. Fuse Brownfield ● Runtime: ○ Pure Java ○ Karaf ○ EAP I ferri del mestiere ● Wiring: ○ Blueprint ○ CDI ○ Spring

123. Fuse Greenfield ● Runtime: ○ Pure Java ○ Karaf ○ Spring Boot I ferri del mestiere ● Wiring: ○ CDI ○ Spring

124. Fuse e Openshift ● Fuse + Openshift = Fuse Integration Services ● Parte dell’offerta Red Hat xPaas ● Lavoro della community Fabric8 Camel Riding in the Cloud

125. Fuse e Openshift ● Build then push: ○ Compilo usando il maven plugin di Fabric8 ○ Push del risultato (Container Image + Metadata) in OCP ● Push then build: ○ Push del progetto su git ○ Source 2 image in OCP Modalità di deployment

126. Fuse e Openshift ● Soap2Rest: ○ CXF, Freemarker ○ Pure Java, CDI ○ S2I Un caso concreto

127. Fuse e Openshift Camel Context

128. Fuse e Openshift Camel Context Definizione Endpoint

129. Fuse e Openshift Camel Context Definizione Endpoint Rotta in Java DSL

130. Fuse e Openshift Camel DSL

131. Fuse e Openshift Hystrix Circuit Breaker

132. Fuse e Openshift Nome App Puntamenti GIT

133. DEMO CAMEL + OSE

137. API Management con 3Scale Nell’era dei Microservizi Luca Bigotta #redhatosd

138. ● Il 22 giugno Red Hat annuncia l’acquisizione di 3Scale ● Inizia la roadmap di evoluzione verso Open Source di 3Scale ● 3Scale complementa il portfolio middleware nella definizione delle “Strategia API" di Red Hat BREAKING NEWS!!! https://www.redhat.com/it/about/press-releases/red-hat-acquire-api-management-leader-3scale

139. La Strategia API di Red Hat

140. Un esempio del valore di 3Scale + Fuse insieme: Composizione API + Management API

141. 3scale è la soluzione API management più adottata nel mondo (750+ clienti) L’architettura di 3Scale è stata progettata per garantire: 1. incomparabile Scalabilità e Alta affidabilità e Performance 2. Il minor time-to-value possibile 3. pricing competitivo sul mercato. 3Scale in breve ... Component Technology Front End Ruby on Rails Gateway NGINX, Lua Back End Ruby, Sinatra, Redis Perchè 3Scale è sempre stata “interessante” per Red Hat? propensione all’Open Source: l’architettura è completamente basata su componenti Open Source esiste da diversi anni una collaborazione fattiva tra 3Scale e Red Hat 3Scale e il Middleware Red Hat si complementano a vicenda Il Traffic manager di 3Scale è da diverso tempo disponibile in Openshift

142. Alcuni clienti 3Scale

143. Mobile & supporto a IOT Ecosistema dei clienti Ecosistema dei partner Agilità interna Monetizzazione delle API Gestione canali multimediali e transazionali Use Case di adozione di 3Scale

144. Da applicazione monolitica a microservizi applicazione monolitica microservizi

145. API management: elemento essenziale nei Microservizi API APIAPI API API API API Management Develop Deploy Scale Manage Container Application Platform (PaaS)

146. Use Case di adozione di 3Scale Controllo Flessibilità e capacità di scalare Visibilità

147. Full Control delle API con 3Scale Controllo ● Sicurezza ● Gestione Chiavi autenticazione ● Limiti di traffico & SLA ● Policy Enforcement ● Gestione Apps & Users ● Provisioning Flessibilità/scalabilità ● Deployment distribuito ● Multi-dipartimento ● Multi-Ambiente ● Estrema scalabilità ● Multi-protocollo ● Webhooks Visibilità ● Analytics ● Tracking Apps ● User Tracking ● Alerts sull’ utilizzo ● On-boarding ● Supporto agli Sviluppatori

148. API Management: il ruolo di 3Scale

149. Architettura modulare e flessibile ● Modulare ○ Configurazioni, Analytics, Portale clienti/sviluppatori ○ Traffic Manager ● Nessun “single point of failure” ● Configurazioni in Cloud su Tenant dedicato ● Molteplici Scenari di deployment del Traffic Manager ○ Managed (Saas) ○ Self-managed: ■ on-premise (fisico o virtuale) ■ in OpenShift ■ come libreria (gateway-less) ■ come CDN (negli scenari di content delivery management)

150. a) Alta Affidabilità garantita: 99.999% uptime negli ultimi anni. b) 100.000.000+ di chiamate ad API gestite ogni girono c) Nessun single point of failure, architettura in HA e traffico bilanciato sui più nodi d) Bassissima latenza aggiunta dal traffic manager: tra 20 ms and (at max) 50 ms e) Ogni singolo nodo di traffic manager può gestire più di 10.000 calls per second f) Architettura del traffic manager è scalabile, e configurabile in base alle esigenze 3Scale Traffic Manager: principali caratteristiche

151. Sicurezza e Privacy ● Diverse modalità di autenticare la API previsti di default ● Flessibilità e possibilità di estendere il supporto ad altri meccanismi di autenticazione ● Privacy garantita sul contenuto del messaggio. 3Scale lavora al livello degli header ● PCI-DSS and HIPAA compliant ● ISO27001 and SOC3 compliant Utilizzato per la verifica delle policy e aggiornamento delle statistiche NON utilizzato

152. 3scale API Management principali caratteristiche: 1/5 Controllo degli accessi alle API flessibile e granulare ➢ API keys ➢ coppia App_ID e App_key ➢ Supporto allo standard de-facto: OAuth v1.0 and 2.0

153. 3scale API Management principali caratteristiche: 2/5 Configurazione di contratti di livello di servizio ➢ Configurazione granulare dei livelli di servizio per gruppi API consumer ➢ Configurazione di limiti flessibile per-time-period

154. 3scale API Management principali caratteristiche: 3/5 Statistiche di utilizzo API ➢ Identificazione pattern di traffico ➢ Top API utilizzatori ➢ Alerts, creazione reporting ad hoc

155. 3scale API Management principali caratteristiche: 4/5 Documentazione delle interfacce automatica e interattiva ➢ Documentazione API Interattiva ➢ Swagger-based ➢ Self-service developer portal

156. Portale degli sviluppatori & clienti/partner esperienza utente completamente personalizzabile

157. 3scale API Management principali caratteristiche: 5/5 Gestione granulare della monetizzazione delle API ➢ pricing model flessibile ➢ Fatturazione automatica ➢ Servizi di pagamento pre-integrati

158. Monetizzazione delle API Regole di pricing • Pagamento One time & canone fisso mensile • Canone mensile variable (a consumo, pricing dipendente dal volume) Ciclo di fatturazion e • 2 opzioni (prepagato e postpagato) • Fatturazione mensile Compliancy • Nessun salvataggio di informazioni di carta di credito Integration • payments gateways pre-integrati

159. 3Scale Traffic Manager e Openshift URL tenant 3Scale admin Chiave autenticazione al tenant 3Scale admn Nome traffic manager

160. GRAZIE! #redhatosd

161. #redhatosd

162. ● Il 7 settembre Red Hat pubblica una customer reference che dimostra la validità delle “Strategia API” di Red Hat. ● Prima referenza full Red Hat ● Red Hat 3Scale + JBoss Fuse BREAKING NEWS!!! https://www.redhat.com/it/about/press-releases/flytoget-deploys-red-hat-jboss-fuse-and-3scale-api-management-technology-further-its-digital-ambitions