MicroProfile as the Istio Programming Model | Virtual Eclipse Community Meetup

Editor's Notes

• #3: 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.
• #6: 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.
• #8: 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.
• #9: 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.
• #13: 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.
• #23: 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
• #24: 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.