APIdays Helsinki 2019 - Impact of Microservices Architecture on API Management with Sami Koivisto, IBM
•Transferir como PPTX, PDF•
1 gostou•374 visualizações
This document discusses the impact of microservices architecture on API management. It describes how microservices are structured as independently deployable services that communicate over a network. When microservices communicate across organizational boundaries, API management is advised to provide capabilities like a gateway, developer portal, and API management. The document also discusses how a service mesh can be used for internal microservice communication within an organization, making API management optional in that context. It provides examples of how Istio implements a service mesh and its features for dynamic routing and traffic control between microservices without requiring code changes.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a APIdays Helsinki 2019 - Impact of Microservices Architecture on API Management with Sami Koivisto, IBM
Semelhante a APIdays Helsinki 2019 - Impact of Microservices Architecture on API Management with Sami Koivisto, IBM (20)
Mais de apidays
Mais de apidays (20)
Último
Último (20)
APIdays Helsinki 2019 - Impact of Microservices Architecture on API Management with Sami Koivisto, IBM
- 1. Impact of Microservices Architecture on API Management Sami Koivisto
- 2. Modernization will impact more than just your software People & Process Architecture & Design Infrastructur & Technology
- 3. Infrastructure & Technology People & Process Architecture & design Fine grained deployment Improve build independence and production velocity (deployment agility) Decentralized ownership Accelerate agility and innovation (development agility) Cloud native infrastructure Dynamic scalability and inherent resilience (operational agility)
- 4. Microservice component Microservices ApplicationMonolithic Application What are microservices? Microservices is a technique for structuring an application as a collection of services • Self-contained with clear interfaces and a distinct purpose • Loosely coupled – communicate over a network • Independently deployable, scalable, maintainable and testable
- 5. µService µService µService µService µService API Application boundary µService Microservice component µService µService µService API gateway API gateway µService API gateway Silo application Silo application Managed API gateways define and enforce application boundaries Boundaries make complex environments manageable µService µService µService API gateway µService µService µService API gateway µService µService µService API gateway 5https://developer.ibm.com/apiconnect/2018/10/09/apis-microservices-defining-boundaries API gateway
- 6. API management: More than just a gateway Developer Portal API Manager API Gateway: • Decoupling/routing • Traffic management • Security • Translation Developer portal: • API discovery • Self-service • Onboarding • API subscription • Account usage analytics API Manager: • API/plan/product design • Access management • Policy administration • API plan usage analytics The API implementation should not be burdened with the complexities of API exposure beyond the microservices application boundary. Exposure should be delegated to a separate capability providing as a minimum, a gateway, a developer portal, and API management. API Implementation 6 API gateway
- 7. Decentralized API ownership Developer Portal API Manager API Implementation A API Implementation B API Implementation C A B C A B C API gateway API gateway API gateway on a centralized API management infrastructure API gateway 7https://developer.ibm.com/apiconnect/2018/12/10/api-management-centralized-or-decentralized
- 8. Enterprise boundary Federated API gateways, centralized management Developer Portal Line of business A API gateway API gateway API gateway API gateway API Manager Line of business B Line of business C Line of business D
- 9. On premises Federated API gateways, centralized management Developer Portal API Manager Public Cloud A Private Cloud Public Cloud Y Public Cloud Z API gateway API gateway API gateway API gateway API gateway
- 10. Microservice component Inter-microservice vs. inter-application communication Microservices application Microservice component Microservice component Microservices application Exposure Gateway Inter-application communication • Crosses organizational boundaries • Potentially on different platform • API management advised Inter-microservice communication • Within an organizational boundary • Microservices on shared platform • Service mesh (e.g. Istio) for complex routing • API management optional • Event-driven microservices with event backbone Note: the protocol used for the communication may be the same in both cases, (e.g. JSON/HTTP). It is the way that the interfaces are exposed and managed that is different. JSON/HTTP JSON/HTTP 10https://developer.ibm.com/apiconnect/2018/11/13/service-mesh-vs-api-management
- 11. What Is Istio? An open services platform to manage service interactions across container- and VM-based workloads
- 12. IBM is fully committed to Istio IBM is one of the founding members of Istio (along with Google and Lyft)
- 13. What ISN’T Istio It is NOT an API Management solution It does not replace integration needs
- 14. Istio has a lot of features! Provides a network for services: ● Security ● Policy Enforcement ● Resiliency ● Traffic Control ● Observability Key Features: ● Service auth and identity ● Authorization ● Rate limiting ● Load balancing / shedding ● Retries and circuit breaking ● Fine-grained routing ● Metrics and logs generation ● Request tracing ● Fault injection
- 15. Why Istio is changing the game! 36 Microservice Microservice (Micro)service Microservices application Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy NO CODE, EASY TO CONFIGURE: • Add security between microservices • Create new deployment patterns – A/B Deployments – Canary – Circuit breaker – Revert • Add Rate-Limiting/Spike Arrest • Logs, Metrics, tracing • Add Faults (for comprehensive testing) • Discoverability
- 16. 16 Example: Dynamic Routing between Microservices Microservice Microservice (Micro)service Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy Dynamic A/B Routing No code in the microservices for routing (they are “blind” to each other Ops team has complete control over new microservice roll outs Saves time, reduces errors/rework
- 17. 17 A/B Deployment example (NO CODE) 38 Microservice Microservice (Micro)service Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy 38 Microservice Microservice (Micro)service Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy Microserice (V2) Envoy Envoy 10%90% A B
- 18. 18 A/B Deployment example (NO CODE) 39 Microservice Microservice (Micro)service Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy 39 Microservice Microservice (Micro)service Microservice Micro-service (V1) Envoy Envoy Envoy Envoy Envoy Envoy Ingress Envoy Envoy Microserice (V2) Envoy Envoy 10%90%
- 19. Bringing API Management and Istio worlds together bookInfo (beta) DataPower API Gateway bookInfo (stable) Istio Mesh Edge Gateway Security policies (JWT, SSL, ...) Map policy XML <-> JSON Parse policy Custom policies Complex Routing policies Bookinfo Virtual service EnvoyEnvoy
- 20. Context Augmentation using DataPower Gateway bookInfo (beta) bookInfo (stable) Istio Mesh Istio sidecar proxy DataPower API Gateway Augment request context by setting the plan name in a header based on client subscriptions "plan": "premiumplan” OR "plan": "betaplan",
Notas do Editor
- GraphQL tomorrow at 2:25 at main stage
- Digitalization drives IT modernization Modern styles of IT architecture impacts thee aspects of application development Infra -> architecture -> people
- Fine grained deployment is all about splitting things into smaller pieces for more agility Loosely coupled Dependencies Shorter Deplyment cycles Independent management of components Allows Ownership to be decentralized Application teams can be constucted in more agile ways teams, tribes, chapters, guild and so on… Avoid priorities conflict Sits on top of infrastructure that is cloud native through containerization Portability
- 12 factor app self contained with: isolate dependencies Store config in the environment Treat backing services as attached resources Strictly separate build and run stages
- Define boundaries Groups of microservices makes application Reuse through copy Kubernetes namespaces keep microservices contained How to expose services outside the application? Hide implementation complexity
- Publishing API is more than just gateway More customer centric self sufficient API Procut manager Productized API
- Are we saying that you should have gateway per micro service? No, the infrastructure performing API management can still be centralized. Can be managed in a multitenant way in completely isolated way There are reasons why we might end up braking this into multiple developer portals Or even gateways
- Gateways over different organizational boundaries
- Or as typical, over different clouds and environments. Gateways close to services, but you still want centralized management. It’s possible to manage multiple gateways in multiple locations Deployment and architectural flexibility
- API’s in inter-application communications Event driven architecture, using events, Kafka, multiple patterns Service Mesh
- Istio is service mesh to manage microservices
- Having side car proxy micro gateway is not API management solution No producer or consumer organization management capabilities No tools for API Product management Mostly operations tools
- Quite a lot of simalar capabilities than API Management But still different use case
- Network for micro services Service mesh intercepts invocations Side car proxy Control plane (Pilot, Citadel, Mixer), telemetry Policy based routing Patterns visibility
- Sidecar, Control plane, network of microservices, services are blind to each other
- Inside microservice application, but how this relates to API Management?