1. Modernize Your Existing Applications with Microservices
Sherwood Zern
Consulting Solutions Architect
Oracle A-Team
Peter Jausovec
Consulting Member of Technical Staff
Container Development
October 25, 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. ”Micro” in Microservices != smaller service
Micro is all about less complexity
Monoliths
Microservices
Module 1
Module 2
Module N
API
monolith = various capabilities in 1 app/process
microservice = 1 cap in 1 app/process
Business Logic
Logic
Must support the requirements of ALL modules
Must support the requirements of one module
Datastore
Datastore
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
because each microservice has it’s own datastore we will run into eventual consistency issues and you need to manage it
monolith = updating bunch of things in 1 transaction – microservices require multiple resources to update
Idempotency = add unique IDs to requests/messages; ensure steps can be repeated without any impact
event sourcing = changes stored as sequence of events
Compensating transaction pattern = record information about each step and how the work can be undone
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
Order V1 ->
Order V2 ->
Datastore
Datastore
Profile V1 ->
Profile V2 ->
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. 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
API Gateway LB
Inventory
Promotions
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. Microservices Interactions
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
/Home D F
B – processing calling F,G B G F 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. 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
Existing Application
New Service
Façade
Module 1
Module 2
Module N
New Module
Middleware
Middleware
Datastore
Datastore
Implemented as Microservice
Confidential – Oracle Internal/Restricted/Highly Restricted

19. 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
Existing Application
New Service
Façade
Module 1
Module 2
Module N
AC Layer
New Module
API
Translation
Middleware
Middleware
Datastore
Datastore
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 Optimize for agility and speed
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 (
Grafana (
Zipkin (
Confidential – Oracle Internal/Restricted/Highly Restricted