rdli

This is addressed in Envoy 1.11.1 (https://www.envoyproxy.io/docs/envoy/v1.11.1/intro/version_h...) and Ambassador 0.75 (https://blog.getambassador.io/multiple-http-2-vulnerabilitie...).

Datawire | Boston, MA | Full time | Onsite | Tech lead

Datawire builds OSS software for Kubernetes, including Ambassador and Telepresence. Demand for our products is skyrocketing, and we're looking for a tech lead who can lead our commercial products team that builds on our open source stack. Our core stack is Golang, Python, Envoy Proxy, and Kubernetes.

(Also, if you're an engineer who likes to hack on this kind of stuff, send us an email too. We're OK with remote engineers, not OK for the tech lead.)

Email careers@datawire.io.

Datawire | Boston, MA | Full-Time | Systems engineer | REMOTE OK

We make two hugely popular open source Kubernetes tools: the Ambassador API Gateway and Telepresence, a CNCF project. We're looking for hard-core systems programmers: if you've ever tried to fix a bug in your proxy and then ended up debugging conntrack, this is the role for you. We work on state-of-the-art infrastructure software: Kubernetes, Envoy Proxy, and such. We're looking for folks who love to learn and are comfortable exploring every part of the infrastructure tech stack.

Languages: Golang, C++11, C, Python (preferably at least 2 of the previous).

Email: careers@datawire.io

Because in modern-day cloud systems there is a lot of service-to-service communication, L7 becomes really important (i.e., you're building a distributed system). Istio (and other meshes) try to abstract away the nuances of distributed computing away from developers, by magically adding timeouts, retries, circuit breakers, observability, etc.

In practice, Istio is pretty complex and not for the faint of heart. You can think of Istio and its cousins (Linkerd, Consul Connect, etc) as the spiritual successors of the original Netflix OSS stack and Finagle.

Did you check out Ambassador by any chance?

From what I gather in the GitHub repository, they implement their own L7 management, instead of using NGINX, Envoy, HAProxy, etc. IMO, this adds quite a bit of development cost with minimum benefit.

Kong has built on OpenResty (which is built on NGINX), Ambassador has been built on Envoy Proxy -- I think these projects will be able to sustain their velocity more so than projects that need to maintain their own L7 engine. Just watching the speed at which Envoy Proxy is adding stuff is kind of staggering; hard to imagine how another company could do the same on their own homegrown engine.

Curious to see if Kong can do true hitless reloads without proxy restart. Envoy can do this but I thought only NGINX Plus has this capability?

If you're using Kubernetes, you should check out Ambassador. Declarative syntax, no database (persists to etcd), very high performance, built on Envoy Proxy.

We're flexible, with folks in 3 different countries outside the US. The biggest thing is that we both feel confident that you'd be able to work productively in a semi-autonomous way. A lot of this is being able to self-correct and adjust, e.g., if an agreed upon plan isn't working, then recognizing this and adjusting the plan, instead of continuing down the original path.

Envoy Proxy is pretty complex. It is really designed for machine configuration. This is one reason projects like Ambassador API Gateway (https://www.getambassador.io) exist -- it translates decentralized declarative Kube config into Envoy configuration (non-trivial exercise).

That said, Envoy has some great features such as distributed tracing, a robust runtime API for dynamic configuration, gRPC load balancing, etc.

Disclosure: I work on Ambassador.

Thanks :). Would love to hear your feedback on Ambassador (my email/Twitter are in my profile), too!

Datawire | Systems Engineer | Boston / Remote OK | Full-time | https://www.datawire.io

We build open source tools for Kubernetes, including Ambassador (API Gateway built on Envoy Proxy) and Telepresence (CNCF Sandbox project for developers). We're looking for systems engineers who are comfortable coding and troubleshooting features at all areas of the systems and network stack. Do you know how to override DNS on Linux so that it points to the DNS in your Kubernetes cluster? Then this is a role for you. We code in C++, Golang, Kotlin, and Python. Past experience with Kubernetes, Envoy/NGINX/HAProxy, and/or open source projects a big plus.

We love people who are (or want to be) members of the Kubernetes/cloud-native open source community, and virtually all of our engineers have given talks at conferences such as KubeCon, Velocity, ApacheCon, DevOpsDays, and such.

Email careers@datawire.io.

Datawire | Systems Engineer | Boston / Remote OK | Full-time | https://www.datawire.io

We build open source tools for Kubernetes, including Ambassador (API Gateway built on Envoy Proxy) and Telepresence (CNCF Sandbox project for developers). We're looking for systems engineers who are comfortable coding and troubleshooting features at all areas of the systems and network stack. Do you know how to override DNS on Linux so that it points to the DNS in your Kubernetes cluster? Then this is a role for you. We code in C++, Golang, Kotlin, and Python. Past experience with Kubernetes, Envoy/NGINX/HAProxy, and/or open source projects a big plus.

We love people who are (or want to be) members of the Kubernetes/cloud-native open source community, and virtually all of our engineers have given talks at conferences such as KubeCon, Velocity, ApacheCon, DevOpsDays, and such.

Email careers@datawire.io.

Ory's great, and glad to see they're integrating more with other technologies, e.g., https://www.ory.sh/api-access-control-kubernetes-cloud-nativ....

Datawire | Systems Engineer | Boston / Remote OK | Full-time | https://www.datawire.io

We build open source tools for Kubernetes, including Ambassador (API Gateway built on Envoy Proxy) and Telepresence (CNCF Sandbox project for developers). We're looking for systems engineers who are comfortable coding and troubleshooting features at all areas of the systems and network stack. Do you know how to override DNS on Linux so that it points to CoreDNS in your Kubernetes cluster? Then this is a role for you. We code in C++, Golang, Kotlin, and Python. Past experience with Kubernetes, Envoy/NGINX/HAProxy, and/or open source projects a big plus. Email careers@datawire.io.

Datawire | Boston| Developer & Support | Full-time | Remote | https://www.datawire.io

We build a number of popular OSS tools for developers on Kubernetes: Telepresence (local coding) and Ambassador (API Gateway). We're seeing lots of user growth, and are expanding the engineering and support teams.

We're looking for systems engineers and support folks who like infrastructure software: Envoy Proxy, Kubernetes, networking, etc. Previous experience with OSS is a plus!

Send an email to careers@datawire.io if you're interested.

I'd also add that the current service mesh solutions are all pretty immature. Linkerd is the most mature, but Buoyant is splitting resources and doing Conduit. There's Cilium. There's Tigera/Calico (sort of). There's now Consul Connect. And of course Istio.

IMO, you don't need a service mesh until you have a complex topology (i.e., services that call other services that call other services). A service mesh fundamentally is designed so that when you have a deep topology, you can manage/mitigate failures better by limiting blast radius/cascade failure/improving mean time to respond.

However, there are a ton of techniques you should consider before you go to a service mesh:

* canary deployments / rolling updates / etc. * monitoring via APM, distributed tracing, etc. * health checking / auto scaling via Kubernetes or equivalent

(I actually wrote an article about this recently that will be published in InfoQ, but it's under embargo. If you ping me, I can send you a not-for-public-yet version.)

Datawire | OSS Engineer | Full-time | REMOTE and ONSITE (Boston)

Datawire is a Boston-based startup that builds open source tools so that developers can code faster on Kubernetes. Our tools include Telepresence (https://www.telepresence.io) for local development; Forge (https://forge.sh) for build/deployment; and Ambassador (https://www.getambassador.io), an API Gateway for Kubernetes.

We're looking for a systems engineer who has a strong understanding of systems and networking. This is not a job if you consider yourself a "full-stack engineer". If you would be comfortable hacking on a VPN client or an API Gateway, consider yourself a strong candidate :-). We're looking for someone who's fluent in at least one of Python/Golang/C. Kubernetes experience a huge plus, but not required.

https://www.datawire.io/careers/

+1. Traefik & Ambassador & the NGINX ingress controllers can persist to Kubernetes, and I think that's a big win for simplicity.

At KubeCon Austin in December there was a lot of conversation about it. Some want portability, some want expressiveness, everyone agrees that current ingress isn't expressive enough.

In practice, everyone adds custom annotations one way or another (whether it's NGINX ingress, or Ambassador, or KongIngress). So at some level, the notion of Kube ingress is a moot point, since everyone has forked it :-).

Some thoughts:

- This implementation is a good example of why Kubernetes ingress has been in beta for 2 years ;-). Ingress doesn't do very much, so the Kong team has had to implement a custom set of extensions to Ingress ("KongIngress") so you get functionality such as rate limiting, etc. This blog post https://blog.getambassador.io/kubernetes-ingress-nodeport-lo... covers some of the nuances of this.

- I wonder how the REST APIs of Kong are reconciled with the declarative config. Seems like this could be complicated.

- IIRC, all of the NGINX ingress controllers take the route of custom annotations on the ingress object vs the KongIngress approach. I wonder what people will prefer.

- The post alludes to intelligent connection draining with Kong but doesn't give any details. I'm particularly curious because I thought Kong was based on NGINX so wondering how Kong does it given the underlying engine.

Datawire | Telepresence OSS Engineer | Full-time | REMOTE and ONSITE (Boston)

Datawire is a Boston-based startup that builds open source tools so that developers can code faster on Kubernetes. Our tools include Telepresence (https://www.telepresence.io) for local development; Forge (https://forge.sh) for build/deployment; and Ambassador (https://www.getambassador.io), an API Gateway for Kubernetes.

We're looking for a systems engineer who has a strong understanding of systems and networking. This is not a job if you consider yourself a "full-stack engineer". If you would be comfortable hacking on a VPN client, consider yourself a strong candidate :-). We're looking for someone who's fluent in at least one of Python/Golang/C. Kubernetes experience a huge plus, but not required.

https://www.datawire.io/careers/

We (Datawire) also wrote https://forge.sh which seems similar to Skaffold in a lot of ways. You can think of it as a Kubernetes-native Docker Compose, letting you declaratively define your app & its dependencies and then deploy them all into Kubernetes. We also wrote Telepresence which is mentioned elsewhere in this conversation, and we're working on integrating it into Forge.

Forge lets you do things like specify different profiles (QA, staging, prod) when you deploy, map branch names to profiles, do super fast incremental Docker builds, dependencies, etc.

What we've found though, over time, is that it's less about the tool and the best practices on how you use these tools -- that's something we're now spending a lot of time now since our users are showing us how they're trying to use this, and it's really fascinating.

Thanks! We (at Datawire) are working towards this with both Telepresence and Forge. Part of the premise is that developers also need self-service features in their operational infrastructure, which is why we also have Ambassador. It's a complex problem!

Datawire | Customer Support Engineer | Boston, MA | Full-time, Contract | ONSITE

We build OSS tools (Telepresence, Forge, Ambassador) for developer workflows on Kubernetes. We're getting a ton of customer usage, so we need someone who can do customer support, work on the documentation, test/repro issues, and fix bugs. We're looking for someone who's very comfortable with Linux / networking / etc who loves talking to customers and troubleshooting. You'll learn a ton about state-of-the-art tech: Kubernetes, Envoy, Docker, among others. Email careers@datawire.io.

While microservices might be helpful for scaling from a perf level, a lot of the situations where I've seen microservices apply is the organizational scale challenge.

How do you get lots of engineers to work on a single monolithic application, while releasing the app into production on a very frequent basis (e.g., daily)?

The traditional answer has been to add complexity into your workflow (e.g., feature freezes, staging environments, code reviews, more testing). These are all reasonable things and good ideas. But at some point your velocity starts to slow down dramatically because of all this complexity.

Worst of all, this complexity isn't necessary for every feature. You might be prototyping some stuff, for example. But a monolithic architecture forces everyone onto the same workflow.

Microservices enables different workflows for different features (services). The value of this, even when you're at a small scale, can be pretty significant.

Take a look at https://www.cncf.io/blog/2017/12/06/cloud-native-technologie.... It already has, more or less.

So in reading this link where information is scarce, this seems like an alternative to minikube (e.g., bundling Kubernetes as part of Docker CE/EE). Is that the right interpretation?

FWIW, we've found minikube a bit wonky. It's resource intensive, so if you want to run more than a couple services, your laptop starts to melt. One of our open source projects is Telepresence which relies heavily on Kubernetes networking, and we definitely see more weird/networking issues with Telepresence/minikube than with regular K8S clusters.

Datawire | C++11 engineer | Boston/SF/remote possible

We are a startup building open source dev tools for Kubernetes developers. We're looking for an open source hacker to work on the Envoy proxy. This means you have to systems programmer fluent in C++11. Lots of bonus points if you've been a committer on an open source project of some reasonable size.

More details: https://angel.co/datawire-io/jobs/265354-principal-software-....

Email careers@datawire.io. Your resume is fine, but even better would be a couple sentences on your C++, OSS, and systems programming experience.