In June last year I reported here the open sourcing of Amalgam8 – a microservice fabric first to provide a central control over layer 7 routing across a mesh of microservices that constitutes a cloud app. The value of Amalgam8 is in removing the burden and complexity of integrating the smaller microservices that comprise an app, by addressing dynamic discovery, failure resiliency, load balancing, and smart content-based routing. Further, Amalgam8 enables high value DevOps capabilities such as canary testing and resiliency testing necessary for agility with control and quality.
Fast forward one year: we upped the microservice game with Istio – a collaboration between IBM, Google and Lyft on a microservice mesh that includes all of the Amalgam8 features and so much more!
This collaboration enables the three of us to combine the best of breed technologies and skills to form a truly unique value proposition addressing both Enterprise CIO need for policy, security, and control, and developers’ needs for productivity – namely, delivering code in the cloud with speed and quality.
Why Google? Istio is the next layer up the cloud stack after Kubernetes, originally designed by Google. Think of Kubernetes as the cloud’s Operating System, and Istio as the cloud middleware. Crossing the line to the application layer enables powerful control to route requests between multi-versioned microservices based on the content of the request, such as geographic location, mobile users, or actual user identity. The Google team contributed their knowledge in rate limiting, access control lists, authentication and telemetry collection, as well as the Kuberenetes integration. It is important to note that while we are starting with Kubernetes as a base layer, the plan is to evolve Istio to support hybrid cloud environments, including private clouds, CF apps, and VMs.
Why Lyft (the engineering arm of the rideshare service)? Istio is based on the key idea that all routing across microservices is done through an overlay network of “proxies.” This network of proxies not only provides a way to control microservice traffic rules, but is also used to collect valuable data. Istio uses Lyft’s distributed, high performance, secure proxy, called Envoy, that Lyft initially developed for their own production use, and that gained significant popularity following its open sourcing. Our research team worked with Lyft to deliver capabilities for failure and delay injection – functions necessary for controlled resiliency testing, traffic splitting across versions of microservices, and Zipkin’s distributed tracing system.
Out team is extremely excited to continue to work on the next layer of value, contributing to, extending, and leveraging Istio. In particular, we are working on providing powerful security policy and analytics, to help the CIO meet their security and compliance goals with cloud native development. We are also working on advanced (cognitive) DevOps capabilities leveraging the powerful app layer communication data and control we get from Istio, and applying machine learning to the data for smart dynamic testing and troubleshooting – stay tuned.
In a previous post we explained how to write a probabilistic model using Edward and run it on the IBM Watson Machine Learning (WML) platform. In this post, we discuss the same example written in Pyro, a deep probabilistic programming language built on top of PyTorch. Deep probabilistic programming languages (DPPLs) such as Edward and […]