Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Role of integration in Digital Transformation

792 vues

Publié le

Every enterprise has a multitude of existing systems - including on-premise as well as cloud solutions - that perform critical functions. Integrating data and services across these systems is critical for an enterprise to successfully implement its digital transformation efforts. Therefore, most often than not, enterprise integration is at the heart of any organization’s digital transformation strategy.

Publié dans : Technologie
  • Soyez le premier à commenter

Role of integration in Digital Transformation

  1. 1. The Role of Enterprise Integration in Digital Transformation Kasun Indrasiri Director – Integration Technology March 2017
  2. 2. Agenda  Digital Transformation and Integration  Centralized Integration  Future Integration needs  Microservices and Integration  Decentralized Integration – Micro-Integration  State of the art integration middleware  WSO2’s Next generation integration platform with Ballerina 2
  3. 3. Digital Transformation and Enterprise Integration 3  DT in a nutshell o Evolving Business Models o Focus on customer experience o Optimize Operation  Brown-field reality requires integration o Hence Enterprise Integration is a key step towards Digital Transformation.
  4. 4. State of Integration Technologies Landscape 4  Application and data integration technologies are moving to a dynamic space – Cloud, Mobile, APIs, IoT, Convergence of Data and Application Integration
  5. 5. Centralized Integration 5  A central integration middleware that connects application, services and data  Conventional SOA/ESB approach  Legacy systems to cloud services connected with services, data, messages and processes.
  6. 6. Centralized Integration WSO2 Enterprise Integrator 6.0 6
  7. 7. Centralized Integration 7  WSO2 Enterprise Integrator 6.0 – Runtime Structure o ESB and DSS as a single runtime o Message Broker o Business Process Server o Application Server o Analytics (primarily ESB analytics)
  8. 8. Can Conventional Integration Middleware survive? 8  Drastic changes in modern Enterprise Integration needs.  Not compatible with new architectural paradigms (e.g. Container Architecture, Microservices)  Almost all integration middleware solution more or less offer the same set of functionalities for a decade or so.
  9. 9. Future Integration needs 9  Microservices and ESB/Integration Middleware o Increasing adaptation of Microservices Architecture o Microservices do not encourage the conventional centralized integration middleware. o Integration middleware solutions are not container native.
  10. 10. Microservices architecture rejects ESB? 10  Smart endpoints and Dumb pipes. o No ESB! o All the business logic and routing logic should be moved to the endpoints.
  11. 11. Microservices architecture rejects ESB? 11  Smart endpoints and Dumb pipes => Point to point Integration
  12. 12. Microservices and Enterprise Integration – In Practice 12  Netflix API “The Netflix API is the “front door” to the Netflix ecosystem of microservices. As requests come from devices, the API provides the logic of composing calls to all services that are required to construct a response.” Source : http//techblog.netflix.com/2016/08/engineering-trade-offs-and-netflix-api.html
  13. 13. Microservices and Enterprise Integration – In Practice 13  Uber Uber uses ‘Edge Services’ which are exposed to the external client/mobile applications and the service orchestration logic is burnt into the edge service. Source : https://www.infoq.com/presentations/uber-darwin
  14. 14. Microservices and Enterprise Integration – In Practice 14  Paypal The API façade layer exposes Paypal business functionalities to various internal and external client applications and orchestration logic resides at that layer. Source : https://www.infoq.com/presentations/paypal-api-evolution
  15. 15. Microservices and Enterprise Integration – In Practice 15  Microservices still requires an integration layer that can implement service/API orchestrations and connect to any other external system.  Use monolithic centralized integration middleware? – NO  Need of ‘Decentralized Integration Middleware’
  16. 16. Decentralized Integration 16  No centralized integration bus/ESB.  Build independent integration scenarios using integration framework -> Micro- Integrations/Integration Microservices
  17. 17. Micro-Integration/Integration Microservices 17  Build a specific integration scenario and run that scenario independently with a light-weight integration framework.  One integration scenario per each runtime.  Runtime is extremely lightweight fully container native.  Develop, deploy and scale each integration scenarios Independently.
  18. 18. Micro-integration 18  Integrating Microservices
  19. 19. Micro-integration 19  Integrating applications, services and data.
  20. 20. Micro-integration 20  Integrating Microservices and other conventional applications
  21. 21. Micro-integration 21  Scaling Micro-integrations 5 – Instances 2 – Instances 10 – Instances
  22. 22. Types of Micro-integration
  23. 23. Future Integration needs 23  Growth and diversity of Integration needs o APIs and SaaS o Internet of Things o On-premise applications • B2B, Proprietary, Legacy systems
  24. 24. Future Integration needs 24  Agility and ease of Integration o Minimum integration skills and operational overhead. o Customize existing integrations rapidly. o Visual modeling, debugging, trouble shooting o Analytics – Statistics, message tracing o Error handling. o Streamlined development life cycle.
  25. 25. Future Integration needs 25  Orchestration – Implementing complex orchestration logics o Proliferation of services, APIs and applications to integrate. o Complexity of the orchestration logic increases o Need a simple and agile development of orchestration logic – Visual modeling tools.
  26. 26. Future Integration needs 26  Orchestration – Implementing complex orchestration logics o Use case : Netflix API: Single API call to nested, conditional, parallel execution of multiple backend network.
  27. 27. Future Integration needs 27  Integrating applications, services, data, APIs and identity o There’s a broad integration challenge than the traditional ESB related integration. o Integration Server, Data Integration, Identity Bus, API GW/Composition
  28. 28. Future Integration needs 28  Performance o No of transactions and latency o Ever increasing growth of traffic. Source : http://blog.mailchimp.com/10m-api-calls-per-day-more/
  29. 29. Future Integration needs 29  Performance o No of transactions and latency per container o Startup Time o Memory foot print o Distribution size o Average CPU consumption, Load Average
  30. 30. Future Integration needs 30  Scalability o Container based scaling o Scaling based on the integration solution o E.g : Ability to scale a given integration solution without scaling others integration solutions.
  31. 31. Future Integration needs 31  Scalability o Container based scaling o Scaling based on the integration solution o E.g : Ability to scale a given integration solution without scaling others integration solutions.
  32. 32. Next generation WSO2 Integration Platform Addressing the future Integration needs.
  33. 33. Ballerina 33  A new programming language, that is designed and optimized for integration, with text and graphical syntaxes  Sequence diagram programming model  Modern, network-aware, data-aware, security-aware programming system inspired by Java, Go, Maven, ...
  34. 34. Ballerina 34  Graphical/textual parity with ability to switch back and forth  Common integration capabilities are baked into the language: • Deep HTTP/REST/Swagger alignment • Connectors for Web APIs and non-HTTP APIs • Support for JSON, XML, (No)SQL data and mapping  No magic – no weird syntax exceptions, everything is derived from a few key language concepts  Maximize developer productivity and
  35. 35. Ballerina Concepts 35
  36. 36. Ballerina Concepts 36
  37. 37. Ballerina Concepts 37
  38. 38. Ballerina Concepts 38
  39. 39. Ballerina Concepts 39
  40. 40. State of the art Integration with Ballerina 40  Light-weight container native runtime— Micro-integrations.
  41. 41. State of the art Integration with Ballerina 41  Light-weight container native runtime— Micro-integrations.
  42. 42. State of the art Integration with Ballerina 42  Revolutionized Graphical and textual representation o Innovative textual and graphical programming syntax based on Sequence diagram metaphor o The graphical and textual syntaxes would maintain parity and would be 100% interchangeable. o Unlike GPLs (Java, Node.js), Ballerina is designed and optimized for integration - ease of integration
  43. 43. State of the art Integration with Ballerina 43  Orchestrations, Choreography and Multi- party interactions o Simpler to model complex orchestrations
  44. 44. State of the art Integration with Ballerina 44  Orchestrations, Choreography and Multi- party interactions o Multi-party interactions, Parallel-executions
  45. 45. State of the art Integration with Ballerina 45  Support diverse integration requirements o Client and server connectors for HTTP 1.1/2, WebSockets, JMS, (S)FTP(S) and more o Client connectors for BasicAuth, OAuth, AmazonAuth o Connectors for Web APIs: Twitter, GMail, LinkedIn, Facebook, Lambda Functions o EIPs – As language features o Graphical Data/Type mapping
  46. 46. State of the art Integration with Ballerina 46  Performance o Ballerina uses latest WSO2 Netty HTTP transport (over 5x of performance improvement compared to traditional HTTP transport implementations) o Super-fast startup and low memory foot print. (100% container native) o Fully non-blocking execution.
  47. 47. State of the art Integration with Ballerina 47  Streamlined design, development, testing and deployment life cycle “Technology for developing, maintaining, testing, deploying, and governing interfaces between applications, machines, or databases” (source : Forrester TechRadar™: Integration Technologies 2015
  48. 48. State of the art Integration with Ballerina 48  Streamlined design, development, testing and deployment life cycle o Configuration over code myth? o Ballerina is a programming language- Hence it support all the generic software development lifecycle stages. o Packaging, sharing and executing o Ballerina composer : Graphical/textual editor/debugger o Testerina and Dockerina
  49. 49. WSO2 Enterprise Integrator 7.0 49  EI 7.0 : Ballerina replaces the ESB, Data Services runtime.  EI will have two parallel versions for a long time.  Migration tool will be able to handle about 80% of ESB and Data Services to Ballerina.  We will continue to evolve and support Enterprise Integrator v6! - EI v6 will have continuing minor releases - ESB users will not be left hanging
  50. 50. Conclusion 50  Integration middleware is not disappearing…  Rather growing to cover broad integration scenarios.  Micro-integration will rule the world.  Next generation WSO2 Integration Platform is addressing those new paradigm shifts in Enterprise Integration with Ballerina.  Ballerina 1.0 GA will be available as a fully fledge production-ready programming language for building integrations
  51. 51. Questions? 51 kasun@wso2.com
  52. 52. References 52  ballerinalang.org  infoq.com  https://medium.com/ballerinalang  https://medium.com/@kasunindrasiri/rejuvenating- enterprise-integration-with-ballerina- 70b29c2c44bf#.j4w7nuu19
  53. 53. THANK YOU wso2.com

×