1 / 24

Modernize Your Existing Applications with Microservices

Modernize Your Existing Applications with Microservices. Peter Jausovec (@ pjausovec ) Consulting Member of Technical Staff May 11, 2018. Safe Harbor Statement.

jjenkins
Télécharger la présentation

Modernize Your Existing Applications with Microservices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modernize Your Existing Applications with Microservices Peter Jausovec (@pjausovec) Consulting Member of Technical Staff May 11, 2018 Confidential – Oracle Internal/Restricted/Highly Restricted

  2. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Confidential – Oracle Internal/Restricted/Highly Restricted

  3. Agenda What is a Microservice? Best Practices for Building Microservices Interaction Patterns Monitoring and Diagnostics Migrating to Microservices 1 2 3 4 5 Confidential – Oracle Internal/Restricted/Highly Restricted

  4. Business Logic Datastore Datastore Logic Module 1 Module 2 Module N API ”Micro” in Microservices != smaller service Micro is all about less complexity Monoliths Microservices Must support the requirements of ALL modules Must support the requirements of one module Fully Featured Runtimes That Support All Use Cases Light Runtimes That Do One Thing Confidential – Oracle Internal/Restricted/Highly Restricted

  5. Best Practices for Building Microservices • Develop and deploy services independently • Treat every service as its own product with its own codebase and lifecycle • Service boundaries • Loosely coupled (avoid shared libs) with as little as possible dependencies on other services • Adhere to the bounded context pattern • Data handling • Service owns its data store • Data access through public interfaces only! Confidential – Oracle Internal/Restricted/Highly Restricted

  6. Best Practices for Building Microservices • Manage eventual consistency • Avoid distributed transactions – deadlocks! • Perform data tasks in an idempotent way • Ensure consistency through event sourcing, compensating transaction pattern etc. • Document APIs • Make service APIs self-describing (use tools like Swagger) • API changes need to be published to all dependent services • Security of microservices • Make it part of every aspect: platform orchestrator and containers  services Confidential – Oracle Internal/Restricted/Highly Restricted

  7. Microservices Interactions Confidential – Oracle Internal/Restricted/Highly Restricted

  8. Microservices in Action Simplified Illustration Order Frontend LB Service Service Profile Diagnostics Registry Datastore Datastore Order V1 -> http://… Order V2 -> http://… Profile V1 -> http://… Profile V2 -> http://.. Confidential – Oracle Internal/Restricted/Highly Restricted

  9. Microservices Interactions Requirements for service registries & service discovery • Service registry and discovery: • Highly available and scalable • Service announcement and API lookup • Notification and Health Checks • Part of the platform • Service registry and discovery is already part of many platforms – e.g. Kubernetes, DC/OS provide registration (etcd, Zookeeper) and service discovery • Managed Service • For full productivity microservices you can use managed services such as API platform/gateway Confidential – Oracle Internal/Restricted/Highly Restricted

  10. Inventory Promotions API Gateway Microservices Interactions Example: Gateway Pattern • Benefits • Encapsulates the internal structure of the application (similar to the façade pattern) • Clients only need to talk to one endpoint • Less roundtrips • Drawbacks • May introduce a single point of failure • Can introduce a bottleneck • Needs to be developed, deployed and maintained Product Pricing LB Confidential – Oracle Internal/Restricted/Highly Restricted

  11. Microservices Interactions • Communication: more services = more communication and data exchange • HTTP (HTTP/2) for external and internal services • TCP/UDP for internal services • Serialization/deserialization: bottleneck with large scale services • Consider if you need to re-serialize data if a downstream service works with the same object; • Pick JSON serializer wisely; consider other formats: e.g. protocol buffers • For Java: Jersey (RESTful web service framework), Jetty (HTTP server) and Jackson (JSON parser) get you pretty far Confidential – Oracle Internal/Restricted/Highly Restricted

  12. SERVICES WILL FAIL! Microservices Interactions • Retry pattern • Implement a retry policy with an appropriate retry count and interval (e.g. exponential back off, incremental intervals, etc.) • Circuit Breaker pattern • Monitor functionality for failures; once threshold is reached, circuit breaker trips and errors are returned automatically without invoking the functionality • Bulkhead pattern • Partition services into different groups to avoid faults in one part of the system to take down the entire system Confidential – Oracle Internal/Restricted/Highly Restricted

  13. Monitoring and Diagnostics Confidential – Oracle Internal/Restricted/Highly Restricted

  14. Monitoring and Diagnostics Monitoring Best Practices • Define a common log format across all services • Log what’s working, what’s not working and error details (start events, heartbeat, stack traces, user requests, etc.) • Aggregate logs for entire request, use centralized store (e.g. Elastic search) • Log performance data on critical path  identify system wide perf issues • Log healthy state data and set up a baseline for “normal” system status Confidential – Oracle Internal/Restricted/Highly Restricted

  15. Monitoring and Diagnostics Use activity or correlation IDs • Activity/correlation ID • Created on request start • Passed to all downstream services • Each service adds the ID to its logs • Makes end to end trace the entire request across multiple microservices RequestId: a3dg895f A – processing calling C,D A C D C – processing calling D D /Home F B – processing calling F,G B F G G Id: a3dg895f Confidential – Oracle Internal/Restricted/Highly Restricted

  16. Migrating to Microservices Confidential – Oracle Internal/Restricted/Highly Restricted

  17. Migrating to Microservices • Break down the application, if: • Want faster time to market • Need to update some components more frequently than others • Components have different scale requirements • Components should be developed using a different technology • Code base has gotten too big and complex • Options for re-architecting an existing solution: • Strangler Pattern • Anti-Corruption Layer Pattern Confidential – Oracle Internal/Restricted/Highly Restricted

  18. Middleware Datastore Façade Middleware Datastore Module 1 Module 2 Module N New Module Example: Strangler Pattern • New service or existing components are implemented as microservices • The façade routes user requests to the correct application • Over time, more and more features are moved to the new architecture New Service Existing Application Implemented as Microservice Confidential – Oracle Internal/Restricted/Highly Restricted

  19. Façade Middleware Datastore Middleware Datastore Module 2 Module N New Module Module 1 Example: Anti-Corruption Layer Pattern • Use when the new services need to access the legacy application (difference to strangler pattern where the new application does not need to access the old one) • Translates the concepts from existing app to new and vice versa New Service Existing Application AC Layer API Translation Implemented as Microservice Confidential – Oracle Internal/Restricted/Highly Restricted

  20. Additional Microservices Consideration Welcome to the distributed computing world! • More services = more network communication: • (might) decrease overall performance due to network hops & (de)serialization • Requires more failure (timeout) recovery code • Hard to test in isolation without dependent services • Hard to debug/monitor across services • Need good version handling • Support old and new API contracts as services don’t upgrade at the same time • More moving bits and pieces, automation becomes harder • ……… Confidential – Oracle Internal/Restricted/Highly Restricted

  21. Not all of it is bad… • Team autonomy • Build team around business capabilities; less coordination assuming well-defined APIs • Optimize for agility and speed • Get to a state where you can develop and ship services easier and faster • Automate everything! • Be flexible, but provide standards to avoid chaos • Assume failures – build for resiliency • Always plan for failures SERVICES WILL FAIL! Confidential – Oracle Internal/Restricted/Highly Restricted

  22. DEMO Confidential – Oracle Internal/Restricted/Highly Restricted

  23. THANK YOU Confidential – Oracle Internal/Restricted/Highly Restricted

  24. Tools from the demo • Istio (https://istio.io/) • Vizceral (https://github.com/Netflix/visceral) • Grafana (https://grafana.com/) • Zipkin (https://zipkin.io/) Confidential – Oracle Internal/Restricted/Highly Restricted

More Related