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

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 http://microprofile.io/ 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 http://microprofile.io/

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

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.

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

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

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

Workgroup Work in MicroProfile community Define the specification in microprofile-service-mesh (https://github.com/eclipse/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.

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

MicroProfile Config ConfigMap io_openliberty_guides_port_number

MicroProfile Health Check

MicroProfile Metrics Add more metrics

MicroProfile Open API /openapi

MicroProfile JWT Propagate authentication info

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

MicroProfile Fault Tolerance Retry Timeout CircuitBreaker Bulkhead Fallback Retry Timeout CircuitBreaker

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

Fault Tolerance Conflict scenario Multiple microservices use http for communication

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

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.