1. MicroProfile Meets Istio
Emily Jiang – Liberty Architect for CDI and MicroProfile

2. What does MicroProfile do?
Vendor-neutral programming model, designed in the open, for Java microservices
Provide core capabilities for building fault tolerant, scalable, microservices
Increasing the rate and pace of innovation beyond Java EE
Standardizing microservices in enterprise Java via the MicroProfile community
Config
Fault Tolerance
Health Check
Metrics
Security (JWT)
Open Tracing
Open API
Rest Client
externalize configuration to improve portability
build robust behavior to cope with unexpected failures
ensure services are running and meeting SLAs
understand the interactions between services while running
provides role based access control (RBAC) for microservice endpoints
Tracing the microservices invocation chain
Easily document microservcie APIs
Simplify the creation of rest clients
See
Graphic shows the community members for MicroProfile who are contributing to the technical direction and development of core capabilities that MicroProfile offers. These form the essential building blocks of microservices and are currently absent from the Java EE specification. By taking a community driven approach to their development, the broader Java developer community can increase the rate and pace of innovation, and prove the technology through the community prior to offering the capabilities to Oracle to standardizes as part of a future Java EE specification.
As MicroProfile is an open source Eclipse project, multiple vendors provide implementations of the MicroProfile specification following the tradition of Java EE itself which provides a vendor neutral specification for enterprise application development. This helps optimize the portability of apps built using the MicroProfile specification and avoids vendor lock-in.
Invite developers to join the MicroProfile community and influence the future

3. What is Service Mesh?
A dedicated infrastructure layer to make service to service communication fast, safe and
reliable

4. What does ‘Service Mesh’ do?
A network for services, not bytes
Observability
Resiliency
Traffic Control
Security
Policy Enforcement
If we were to reimagine the network that connects our microservices, what would we want out of it?
Think of the kernel’s TCP/IP stack today.
Do we care where in the planet an IP address is or how to route to it? No
How about discovering MAC address associated with the IP or the next hop router? Nope.
Do we care about packet loss or congestion control? Heck no.
Essentially, the kernel provides a reliable communication fabric at Layer 4. It frees you from having to deal with discovery, failure recovery, flow control, and a host of other issues that you may not even be aware of.
Isn’t this a nice property to have at the services layer, that is, layer-7? We seem to be having some similar issues: discovery, resiliency, routing, etc. and other issues specific such as load balancing, monitoring, policy enforcement, authentication and authorization, etc.

5. Istio
A service mesh designed to connect, manage and secure your microservices

6. Istio - Putting it all together
svcA
proxy
Pod
Service A
svcB
Service B
Pilot
Control Plane API
Mixer
Discovery & Config data to proxies
Policy checks
Control flow during request processing
Security
TLS certs to proxy
Out-of-band telemetry propagation
Telemetry
Service mesh data plane: Touches every packet/request in the system. Responsible for service discovery, health checking, routing, load balancing, authentication/authorization, and observability.
Service mesh control plane: Provides policy and configuration for all of the running data planes in the mesh. Does not touch any packets/requests in the system. The control plane turns all of the data planes into a distributed system.
Our service mesh is built using Envoy sidecars. If you look at the big picture, its very similar to a SDN (software defined networking).
The sidecars on the data plane carry traffic. Traffic is transparently intercepted using iptable rules in the pod namespace.
The Istio control plane takes care of managing and configuring the data plane.
The Pilot is responsible for providing service discovery to envoys and managing their configuration as well.
The mixer handles policy enforcement, while Istio-auth takes care of authentication and authorization.
We’ll talk about the mixer and Istio-auth later.
Traffic is transparently intercepted and proxied. App is unaware of sidecar’s presence

7. MicroProfile provides the following specifications
Config
Fault Tolerance
Health Check
Metrics
JWT
Open API
Open Tracing
Rest Client
Istio provides
Fault Injection

8. Workgroup Work in MicroProfile community
Define the specification in microprofile-service-mesh (
The people: Emily, Vadim Eisenberg, John Alcorn, Scott Stark (Red Hat), Mike Croft (Payara) and the group is growing rapidly… Ray Tsang (Google) is also interested.

9. Istio and MicroProfile – samples in progress
svcA
proxy
Pod
Service A
svcB
Service B
Pilot
Control Plane API
Mixer
Discovery & Config data to proxies
Policy checks
Control flow during request processing
Security
TLS certs to proxy
Out-of-band telemetry propagation
Telemetry
Write two microservices and demonstrate each MicroProfile programming model, e.g. Config, Fault Tolerance, Open Tracing, Open API, etc
Deploy the microservcies to Kubenetes/icp and then Istio
Utilising Istio policies including Resilience, Fault Injection etc
Demonstrate whether they work together and achieve the ecosystem
Traffic is transparently intercepted and proxied. App is unaware of sidecar’s presence

10. MicroProfile Config
ConfigMap
io_openliberty_guides_port_number

11. MicroProfile Health Check

12. MicroProfile Metrics
Add more metrics

13. MicroProfile Open API
/openapi

14. MicroProfile JWT
Propagate authentication info

15. MicroProfile Open Tracing
7 http headers required by Istio propagated
All JAX-RS requests traced

16. MicroProfile Fault Tolerance
Retry
Timeout
CircuitBreaker
Bulkhead
Fallback
Retry
Timeout
CircuitBreaker

17. Fault Tolerance difference
Apply to all communications
Fine-grained to individual method
Http request only (Retry,Timeout, CircuitBreaker), Connection pool (tcp and http)

18. Fault Tolerance Conflict scenario
Multiple microservices use http for communication

19. MicroProfile Fault Tolerance with Istio – current approach
@Retry
@Timeout
@CircuitBreaker
@Bulkhead
@Fallback
Retry
Timeout
CircuitBreaker
Bulkhead
MicroProfile Fault Tolerance offers Retry, Timeout, Bulkhead, CircuitBreaker, Fallback
Istio offers Failure handling: Timeout, retries, limits on number of concurrent connections, circuit breakers
Istio can not offer fallback
Microservices need both of them sometimes
How to set up a ecosystem of MicroProfile Fault Tolerance with Istio
Use MicroProfile Fault Tolerance without Istio’s Fault Handling
Use Istio’s Fault Handling with MicroProfile Fault Tolerance fallback
MicroProfile Fault Tolerance is configurable and flexible
The Fault Tolerance policies except fallback can be switched off via a configuration property called MP_Fault_Tolerance_NonFallback_Enabled with the value of false.
Unique feature from MicroProfile Fault Tolerance where other Fault Tolerance third party libraries cannot offer easily

20. Ecosystem to be – more complementary
MP Config source
MP Config
MicroProfile FT triggers plugin to generate Istio config rules. For http invocation, set MP_Fault_Tolerance_NonFallback_Enabled to false
Istio config rules will be automatically treated as a config source understood by MicroProfile config. Any value change in the file will be able to feed back to the application.
For http traffic, Istio manages all FT except Retry where MP FT will provide
For other traffic, Istio pretends it manages it but it is not capable. Devops can config the rules by changing the parameters. All the changes will be translated to FT properties and then MP FT obeys the order.
For Devops, it is seemless.