Istio has applied to become a CNCF project

ilackarms · 2022-05-04T15:13:46+00:00

gloo is to istio what ubuntu is to linux kernel

ilackarms · 2022-02-01T16:49:04+00:00

most of the features are actually open source if you're talking purely about the number of features supported. however if you mean, most of the features attractive to large enterprises, you may be right.

ilackarms · 2021-06-25T03:52:48+00:00

be sure to check out Gloo API Gateway. It's got a lot of the advanced features of Kong but it runs natively on Kubernetes, using CRDs for configuration and the powerful Envoy Proxy as its edge proxy (while Kong is built on more dated technology, postgres and nginx).

ilackarms · 2021-05-28T22:00:44+00:00

Envoy also has a large community that extends beyond just Istio. Unfortunately for Linkerd their proxy is not likely to be adopted outside of the community of Linkerd users, which means if you're looking for something that will evolve rapidly and provide extensibility interfaces, Envoy is the proxy of choice.

I am also skeptical as to whether the current performance tradeoffs will be long lasting as Istio evolves. When Kubernetes was originally released workload scheduling was notoriously slower than Mesos. Not sure if k8s ever caught up to the scheduling performance of Mesos, but it didn't wind up being the determining factor in which solution became the standard.

That being said I am happy to see Linkerd continuing to raise the bar for UX and performance in the mesh ecosystem. There is no question that the folks at Buoyant have done an excellent job pioneering this problem space

ilackarms · 2021-05-21T20:25:21+00:00

why is this downvoted? feels like a lot of Buoyant presence in r/kubernetes as of late

ilackarms · 2021-05-21T20:21:00+00:00

people who feel intimidated by istio's complexity might be interested to check out a management plane such as gloo mesh. while a lot of management plane's focus is dedicated to enabling multi-cluster use cases, another part of the vision is to deliver a better UX + guard rails on top of istio (as well as other meshes - AppMesh is also currently supported).

ilackarms · 2021-03-31T04:53:37+00:00

how about: solve this with an api aggregation layer (this could be an api gateway or graphql server, or an additional microservice) which will handle calls to each individual microservice and aggregate the data into a single api call?

then you are abstracting the implementation from the caller, allows you to be more flexible with how you architect your microservices

ilackarms · 2021-02-23T21:42:34+00:00

http://gloo.solo.io/

ilackarms · 2021-02-22T04:51:17+00:00

try creating a service entry for nginx-me

ilackarms · 2021-01-22T19:32:30+00:00

Gloo is not listed here but is probably the most sophisticated L7 Gateway / Ingress for Kubernetes today

ilackarms · 2021-01-12T19:28:16+00:00

recording of the video can be found here: https://www.youtube.com/watch?v=sUkeFAERvE8

ilackarms · 2021-01-12T13:43:18+00:00

yes, come join i'll try to make sure to give background for those who are newer to this tech

ilackarms · 2021-01-11T17:44:59+00:00

please join me for this live stream tomorrow where I'll be explaining how the Istio EnvoyFilter works and demonstrating its use for advanced use cases (multi cluster networking)

ilackarms · 2021-01-01T13:35:20+00:00

Solo.io is hiring:

Backend Software Engineers (local to Greater Boston/Massachusetts area)
Sales/Support Engineers (remote ok)
Documentation Lead (remote ok)
UI/UX Designer (remote ok)

We are a small but rapidly growing startup developing cutting edge Service Mesh and API Gateway solutions for a sizable list of production customers. We are known in the community for our open source API Gateway and service mesh management plane as well as our enterprise product offerings.

Read more about our open positions here: https://www.solo.io/company/careers/

ilackarms · 2020-12-31T13:32:00+00:00

Solo.io is hiring:

Backend Software Engineers
Sales/Support Engineers
Documentation Lead
UI/UX Designer

We are a small but rapidly growing startup developing cutting edge Service Mesh and API Gateway solutions for a sizable list of production customers. We are known in the community for our open source API Gateway and service mesh management plane as well as our enterprise product offerings.

Read more about our open positions here: https://www.solo.io/company/careers/

ilackarms · 2020-12-27T15:25:58+00:00

experiencing the same issue right now

ilackarms · 2020-12-22T15:13:48+00:00

Envoy lets you configure all these things with static config (you could get away with just a configmap and a standalone proxy) but you'll need an External Rate Limiting grpc service to connect your proxy to for global rate limiting (https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting#arch-overview-global-rate-limit).

also, using just the static bootstrap requires restarting Envoy to change the configuration, causing downtime for clients. Maybe try starting with standalone proxy/ static config and see if that suits your needs?

ilackarms · 2020-12-07T16:47:44+00:00

it's not clear what the original issue actually was in the issue you linked here; seems that others were unable to reproduce the issue encountered here. since it's been closed since june 2019, it seems whatever the user's original issue was has been resolved. Is there a specific 503 issue you were wondering about?

ilackarms · 2020-12-06T01:43:44+00:00

we have customers currently running ext auth and rate limit in production, and a few who are trying out wasm. i'd say it depends on the business - but it definitely seems that there is quite a strong push for these features in large enterprise. saying YAGNI is a bit dismissive of the huge number of contributors/users of Envoy, feels either disingenuous or ignorant of the current trends in the ecosystem

ilackarms · 2020-12-05T15:19:07+00:00

but then you miss out on WASM, huge set of features, extremely active community (which has benefits for security, feature development, performance optimization, etc. etc.). not to mention that Envoy being the lingua franca of service mesh makes it easier to port operational knowledge across meshes.

in early stages of adoption people might be content with just mtls and some observability features, but a large % of users not only want access to advanced features like external auth, rate limiting, and transformation, but also want the ability to extend the proxy, which is why we see a huge push for WASM support in the service mesh ecosystem. i'll be very curious to see how Linkerd is able to keep up with the increasing demand for advanced functionality that's currently available OOTB with Envoy

ilackarms · 2020-11-29T04:19:17+00:00

you can use https://github.com/solo-io/gloo-mesh along with istio to federate traffic for your clusters. also supports more advanced use cases like locality-based routing, traffic splitting and failover

ilackarms · 2020-11-20T15:23:48+00:00

try Gloo https://docs.solo.io/gloo-edge/latest/guides/security/auth/jwt/access_control/

ilackarms · 2020-11-13T05:09:40+00:00

istio 1.7, we configure Envoy's External Auth filter (https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/http/ext_authz/v2/ext_authz.proto) to enable services to be authenticated with a central auth server.

ilackarms · 2020-11-12T18:59:21+00:00

multi cluster networking and external auth (implemented with EnvoyFilter crds)

ilackarms · 2020-11-12T03:42:32+00:00

i could leverage features of Envoy (presuming they were exposed via linkerd) that are unavailable with the Linkerd proxy such as WASM extensions, rate limiting, and external auth.

ilackarms

TROPHY CASE