Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices: Where do they fit within a rapidly evolving integration architecture?

5,115 views

Published on

Do microservices force us to look differently at the way we lay down and evolve our integration architecture, or are they purely about how we build applications? Are microservices a new concept, or an evolution of the many ideas that came before them? What is the relationship between microservices and other key initiatives such as APIs, SOA, and Agile. In this session, we will unpick what microservices really are, and indeed what they are not. We will consider whether there is something unique about this particular point time in technology that has enables microservice concepts to take hold. Finally, we will look at if, when, where and how an enterprise can take on the benefits of microservices, and what products and technologies are applicable for that journey.

Published in: Technology

Microservices: Where do they fit within a rapidly evolving integration architecture?

  1. 1. Microservices, SOA and APIs: Friends or Enemies? Co-author: Brian Petrini (petrini@us.ibm.com) Presenter/Author: Kim Clark (kim.clark@uk.ibm.com)
  2. 2. Evolving exposure of business function Service Exposure (enterprise) Low Level APIs (platform/package) Application Integration (application) Service/API Exposure (external known consumers) External API Exposure (public) Future? Differentiating between web APIs, SOA, and integration http://www.slideshare.net/kimjclark/ino-2739-impact2014integrationsoaapiv15 Related article on developerWorks http://ibm.biz/ApiVsSoa
  3. 3. Digital Transformation Creates Multi-Modal IT Digital • Timeframe: Days/Weeks • Scope: Strategic • Sponsor: CMO • Budget: $ • Complexity: Low • Buying behavior: Self service Enterprise • Timeframe: Months/Years • Scope: Strategic • Sponsor: CIO • Budget: $$$ • Complexity: High • Buying behavior: Human engagement Enterprise IT Digital Teams Explore, adopt, adapt with rapid, iterative prototypes Always on, always available Security, control, and governance
  4. 4. Agenda Defining microservices architecture Is this different from Service Oriented Architecture (SOA)? How is integration architecture changing? Where do microservices fit in across the future landscape? How to start an argument about microservices 3
  5. 5. What is microservices architecture Monolithic application Microservices application Silo Microservice (component) Microservice (component) Microservice (component) A microservice is a granular decoupled component within a broader application Agility Scalability Resilience Simplistically, microservices architecture is about breaking down large silo applications into more manageable fully decoupled pieces
  6. 6. Microservice component Microservice component Microservice component Encapsulation is key. Related logic and data should remain together, and which means drawing strong boundaries between microservices. Monolithic application Microservices application Silo logic Silo data
  7. 7. Heterogeneous on the inside, homogeneous on the outside Freedom to choose runtimes, languages, datastores etc. • Wise to encourage preferred technologies. • Convergence often happens naturally. Commonality is in the framework in terms of: • Interconnectivity • Scalability • Resilience 6 Microservices application Microservice (Node.js) Microservice (Java + MongoDB) Microservice (Go + CloudantDB)
  8. 8. Why Microservices? Small scoped, independent, scalable components Scaling Elastic scalability Workload orchestration Agility Faster iteration cycles Bounded context (code and data) Resilience Reduced dependencies Fail fast 7
  9. 9. Microservices: Why now? (technical standpoint) • Internet/intranet/network maturity • Lightweight runtimes (node.js, WAS Liberty etc.) • Methods & tools (Agile, DevOps, TDD, CI, XP, Puppet, Chef…) • Lightweight protocols (RESTful APIs, lightweight messaging) • Simplified infrastructure • OS virtualisation (hypervisors), containerisation (e.g. Docker), infrastructure as a service (IaaS), workload virtualisation (Kubernetes, Mesos, Spark…) • Platform as a service • Auto-scaling, workload management, SLA management, messaging, caching, build management. • Alternative data persistance models (NoSQL, MapReduce, BASE, CQRS) • Standardised code management (Github, …) 8
  10. 10. Microservice component Microservice component Microservice component WAS LibertyNode.js What that might look like in IBM technology? (simplistic representation – NOT a reference architecture!) Monolithic application Microservices application WAS ND DB2 Mongo Db Cloudant Cloudant Node.js IBM Bluemix (PaaS) Message Hub (Kafka) JSON/ HTTP
  11. 11. Microservice MicroserviceMicroservice Microservice Microservices inter-communication Aim is decoupling for robustness Messaging where possible • Lightweight messaging (e.g. AMQP, Kafka) • Publish/subscribe • Eventual consistency Direct calls where necessary Lightweight protocols (e.g. JSON/HTTP) • Load balancing/scaling via service discovery • Circuit breaker • Caching Microservices application Microservice Subscribe JSON /HTTP Microservice Microservice Message Hub API Microservice Publish API JSON /HTTP Publish Service Discovery
  12. 12. Application frameworks at the network level Microservices simplify the creation and maintenance of applications by inheriting key non- functional characteristics from their environment. Sounds familiar? Similar in principle to application container frameworks from the past (e.g. JEE), but: Different because • Framework is agnostic to the runtime/language used by each microservice • Microservices, and framework components sit on the network, rather than within an application server Microservices application Microservice component Microservice component Microservice componentMicroservice componentMicroservice componentMicroservice component Framework provides • Scaling • Availability • Caching • Messaging • Connectivity • …and more Note that from this perspective there is greater parity between microservices architecture and application servers than there is with service oriented architecture11
  13. 13. Can everything become a microservice? What about the things you can’t change? • You can’t refactor all systems to microservices • Most applications have an “if it ain’t broke, don’t fix it” policy • Old systems may be unrealistic to re-engineer • What if you can’t change the datastore? • Are you doing microservices if your data remains in a silo? • Can you manage without transactionality to the database? • Will techniques like BASE, CQRS work? • How do existing systems fit into a microservices architecture? • How do you isolate yourself from their availability issues? • What if they don’t scale as well as your microservices do? 12
  14. 14. Challenges with microservices Automation Automation is key to retaining agility: Test automation. Continuous integration and deployment and more… Managing and monitoring How do you manage and monitor a vast network of microservices Maintenance Given the aim of freedom of language and runtime, will you have the breadth of skillsets to maintain the microservices in the future. Serialisation Data has to get over the wire more often (however, serialisation has advanced massively in recent years) Latency A request/response chained down a set of microservices must incur some extra latency from network hops and serialisation. Data sharing Not all data can be split into a grid, some things are shared. Real-time dependencies What is the combined availability of all dependencies Microservices calling other microservices synchronously need careful consideration. Tends to creep, as one service built on top of another. How does persistence work? Pessimistic vs. Optimistic How handle shared objects Relational/NoSQL ACID/BASE/CQRS/Event Sourcing? 13
  15. 15. Handling distributed objects First law of distributed objects: Don’t distribute your objects! http://martinfowler.com/bliki/FirstLaw.html Microservices and the First Law of Distributed Objects http://martinfowler.com/articles/distributed-objects- microservices.html Don’t go too granular too soon. It is harder to gather up than to break out. 14
  16. 16. Are we really doing microservices? Martin Fowler/James Lewis 1. Componentization 2. Organized around Business Capabilities 3. Products not Projects 4. Smart endpoints and dumb pipes 5. Decentralized Governance 6. Decentralized Data Management 7. Infrastructure Automation 8. Design for failure 9. Evolutionary Design http://martinfowler.com/articles/microser vices.html 15 12 factor apps I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII. Port binding VIII. Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII. Admin processes http://12factor.net Are we really doing microservices or just aligning with some of the microservices principles? Consider the adoption paths of SOA, XP, agile, devops etc. These often come with an “all or nothing” message, but can you take on the whole package?
  17. 17. Agenda Defining microservices architecture Is this different from Service Oriented Architecture (SOA)? How is integration architecture changing? Where do microservices fit in across the future landscape? How to start an argument about microservices 16
  18. 18. Microservice component Common misconception resulting from the term “microservice” Monolithic application Microservices application Exposed services/APIs Microservice component Microservice component Exposed services/APIs Silo component Microservices are just more fine grained web services APIs are microservices “micro” refers to the granularity of the components, not the granularity of the exposed interfaces x 1 x 3 x 4x 4 Is “microservices architecture” is really “micro-component architecture”?
  19. 19. Application SOA relates to enterprise service exposure * Application ApplicationApplication Service oriented architecture (SOA) and microservices architecture relate to different scopes Microservice application µService µServiceµService µService Microservices relate to application architecture * this simple distinction can be contentious depending on your definition of SOA “Microservices, SOA, and APIs: Friends or enemies?” http://ibm.biz/MicroservicesVsSoa
  20. 20. What was SOA really about? Integration or Components? Opinion 1: “SOA is about how to achieve integration often to aging complex back end systems in order to expose services” In this case SOA is primarily a connectivity problem with little relationship to microservices architecture and certainly at a different scope. Opinion 2: “SOA is about re-factoring your IT landscape into components that better align with the business needs and expose the services that it requires” Here the connectivity problem is pushed down to the applications and the focus of SOA is on realignment of to the business needs. The service components look more like applications, and we might consider microservices as “more granular SOA”, or even “SOA done right”. System of Record Integration Hub Adapter Adapter Exposure Gateway Exposed Services/APIs System of Record System of Record Adapter Exposed Services/APIs System of Record Adapter Service Component Service Component Service Component Exposure Gateway However, SOA, despite it’s broader intent, resulted mostly in interface related technology (e.g. WS-*, ESBs). Microservices architecture is more specific on how components should be implemented, and benefits from more real examples of frameworks, and platforms in this area than SOA did at an equivalent time in it’s history. 19
  21. 21. What does a large scale integration landscape look like Systems of engagement • Modern languages/runtimes • Agile • Simple modern connectivity Systems of record • Older technology • Harder to change • Harder to integrate with Integration Hub Integration Hub Adapter Adapter “Systems of Engagement” Applications Exposure Gateway (internal) “Systems of Record” Applications Mature large enterprise (simplified) Exposure Gateway (external) Adapter Adapter “Hub and Spoke” integration “Enterprise Service Bus?” “Web API Gateway”
  22. 22. Why such split opinions on microservices vs SOA? 21 Integration Hub Integration Hub Adapter Adapter Engagement Applications SaaS Application BusinessPartner Systemsof Record Business Partner Exposure Gateway (external) Mature large enterprise Microservices are just one style of application Exposing services is an integration and data challenge Green field online start-up Much of landscape could be microservice based The landscape is as (micro)service oriented architecture Exposure Gateway (external) Microservice application µService µServiceµService µService Exposure Gateway (internal) µService µService µService µService µService µService µService µService µService µService µService EnterpriseBoundary EnterpriseBoundary Adapter Adapter
  23. 23. Where do we typically see microservices in large organisations today? 22 Systems ofRecord Integration Hub Integration Hub Adapter Adapter Engagement Applications Microservice applications SaaSApplications (external) Adapter Externally Exposed Services/APIs Exposure Gateway (internal) Exposure Gateway (external) BusinessPartners
  24. 24. Mapping to example IBM products 23 SystemsofRecord (Internalcoreapplications) Integration Hub Integration Hub Adapter Adapter Engagement Applications Microservice applications SaaSApplications (external) Adapter Externally Exposed Services/APIs Exposure Gateway (internal) Exposure Gateway (external) BusinessPartners WebSphere Application Server (WAS) IBM API Connect or IBM Integration Bus IBM Integration Bus IBM Integration Bus WAS Liberty, Node.js, MongoDb, Cloudant etc. on IBM Bluemix IBM API Connect + IBM DataPower Gateway IBM API Connect IBM MQ feeding events IBM Message Hub in Bluemix, or IIB talking directly to Kafka APIs
  25. 25. Where might we see microservice principles in use going forward? 24 Systems ofRecord Integration Hub Integration Hub Adapter Adapter Engagement Applications Microservice applications SaaSApplications (external) Adapter Externally Exposed Services/APIs Exposure Gateway (internal) Exposure Gateway (external) BusinessPartners
  26. 26. Agenda Defining microservices architecture Is this different from Service Oriented Architecture (SOA)? How is integration architecture changing? Where do microservices fit in across the future landscape? How to start an argument about microservices 25
  27. 27. Integration Domain Enterprise Ownership Boundary The Integration Domain of the Hybrid Enterprise Dedicated CloudPublic CloudSaaS Customers Business Partners Appl. Appl.Appl.Appl.Appl.Appl. Appl. Appl. Appl. Appl. On-Premise Appl.Appl. Appl.Appl. Appl. Local Cloud Appl. Appl.
  28. 28. ApplicationApplication Decentralising synchronous integration Engagement Applications System of Record Integration Public API Enterprise API API Gateway System of RecordSystem of Record Integration EnterpriseBoundary Exposure Gateway (external) SaaS Application Business Partner In a perfect world… • Application teams self- administer exposure of their own APIs • Application teams handle their own integration needs • Access to external APIs is governed using the same mechanisms used to govern access to internal APIs. • Application logic is firmly seated with the application teams • API monitoring/diagnostics would be gathered consistently across the organisation • Security models would be implemented more consistently ApplicationApplication So where is the ESB now? Where might we find microservices here? What about event driven integration?
  29. 29. What is an application boundary in an microservices world? Similar to application boundaries today because • Group related functionality • Enable more coarse grained ownership and responsibility (in addition to full ownership at the microservice level) Different because • Application sub-components (microservices) are truly independent. • Application boundaries can be easily changed – it’s primarily about the right ownership • Application boundaries can spread across network boundaries (e.g. between clouds)…but should they! 28 µService µService µService µService µService µService µService µService µService µService µService
  30. 30. Microservice component Inter-microservice vs. inter-application communication Microservices application Microservice component Microservice component Inter-microservice communication • Lightweight protocols: HTTP, application messaging • Runtime component registry • Client-side load balancing and circuit breaker patterns Microservices application Exposure Gateway Inter-application communication • Enterprise protocols: Managed API gateways, enterprise messaging • Design time developer portals • Gateway load balancing and throttling JSON/HTTP RESTful communication styles may be present in both types of communication, but their implementation may be radically different. JSON/HTTP
  31. 31. Agenda Defining microservices architecture Is this different from Service Oriented Architecture (SOA)? How is integration architecture changing? Where do microservices fit in across the future landscape? How to start an argument about microservices 30
  32. 32. Caution with comparisons (or “how to start an argument”!) Comparisons that make some level of sense Microservice architecture vs. Service oriented architecture Trying to achieve many of the same things (enable the creation of re-usable business functions as isolated components), but at a very different scale. SOA evolved to become focused on the enterprise scale (though some would say that wasn’t the original intent). Microservices, is primarily at the application scale. Microservice component vs. Service component Both describe the actual implementation of a business function. They differ primarily in granularity, but also arguably in maintainability, agility etc. Confusing comparisons Microservices vs. SOA Microservices are components. SOA is an architecture. What you’re probably trying to compare is Microservices Architecture with SOA (see above). Microservices vs. APIs APIs are a interface. A mechanism for exposing business function. Microservices are the component architecture used to implement those business functions. It makes no sense to directly compare them. Microservice vs. Service “Service” means different things to different people. Needs to be qualified. Service Implementation? Service exposure? Service definition? The same could be said for microservice. Need to be specific. 31
  33. 33. Questions? 32 http://www.slideshare.net/kimjclark/presentations https://www.linkedin.com/in/kimjulianclark
  34. 34. Thank You

×