Weaveworks Blog

https://www.weave.works/ "Operate and Manage Kubernetes easily" / "GitOps Automation for Kubernetes Stacks"

also props to https://weave.works for creating cortex, open-sourcing it and moving it under cncf, something this blog post leaves out.

> Next step would be a gitops service that will integrate with AKS That means Weaveworks swallowed up soon then[1], with its Flux GitOps for Kubernetes[2]. [1] https://www.weave.works/ [2] https://fluxcd.io/

We tried spinnaker and are now using Weave (https://www.weave.works/). It works pretty well, actually. In particular we like that it stores all state in a git repo which is automatically updated. We have our own monitoring stack, though, so don't use the additional prometheus integrations

I use it every day against a (multi-tenant) Prometheus back-end. You have to put in quite a lot of effort to design the right queries and charts, but after that it works great for my needs. We prefer to have dashboards under source control so generate them using grafanalib - see https://www.weave.works/blog/grafana-dashboards-as-code/ I think this approach shifts the need for roles and permissions as we never save dashboards from the UI.

Hi, alexis richardson here from weaveworks. We have a berlin office and would love to hire people who want to work in our main areas. See https://www.weave.works/company/hiring/

> If you want to use Prometheus as a SaaS we recommend Weaveworks https://www.weave.works/solution/prometheus-monitoring/ Which is also open source! https://github.com/weaveworks/cortex

Hmm... networking + Weave, where have I seen that before? Ah, http://weave.works . Google did the same with Go as a language, didn't they?

I know a bit of the history with this one. Back in the day there was a smaller consultancy with awesome developers called LShift (mentioned here https://en.wikipedia.org/wiki/East_London_Tech_City). They worked out that an open source messaging thing would be useful, and created RabbitMQ (there were details about who, how it was funded internally, etc). That got sold to VMWare, and a bunch of people went with it, but LShift went on as before, happy, but always looking for another Rabbit. Didn't find one, was aquihired in the end. Meanwhile, some of the Rabbit people formed Weave, looking for the killer business around the early container ecosystem (https://www.weave.works/oss/net/ was interesting, eksctl, flux, CNCF, lots of good things). But I guess they took a bite of the VC apple and sustainable technical contributions was no longer the goal. I've huge respect for everyone I knew from Weave. Great people all. Best wishes and I know you'll land on your feet.

I know this isn't the craziest startup shutdown story, but wow. At $10MM of revenue they can afford to keep a staff of 50 at a fully loaded cost per employee of $200,000. Yet, according to Linkedin they peaked at nearly 200 employees. On top of this, they appear to have raised $36 million three years ago - https://www.weave.works/press/releases/weaveworks-raises-36-million-se… In other words they somehow were running at a loss of about 1.5 million a month for three years until their runway "suddenly" ran out today. According to the CEO's linkedin post, they were basically trying to keep up appearances of being a 200 person company until some greater fool bought them out, which appears to have failed. How do you find yourself as Board member or CEO of a company like this and not think to cut expenses a little sooner? Far better to be a growing, profitable 50 person company than a cash-burning Potemkin unicorn.

Weaveworks | Software Engineer, Backend | ONSITE(London)/REMOTE (prefereably EU/US TZs) | https://www.weave.works | Full time Weaveworks aims to empower developers, no matter their background, to take advantage of container technology such as Docker to build faster and more scalable applications. We believe that container software will change the way developers create applications, so much so that many approaches are yet to be imagined. Help us build open source software tools that other developers use to tame their containerized applications. We are looking for experienced software engineers with background in kubernetes, go and AWS. Experience in open source software development practices highly appreciated. The job is with a remote, global team, ability to work unsupervised and coordinate with others on daily basis. Devops experience with one or more public cloud providers. Apply here: https://boards.greenhouse.io/weaveworks/jobs/1829839

This seems especially important if you want to offer Prometheus as SaaS. Your customers won't want to run their own Prometheus installs (that's what they pay you for, after all), and asking customers to open their firewalls so that your Prometheus can discover and scrape their infrastructure is probably a non-starter. At Weaveworks we provide Prometheus as a SaaS using Cortex, which is how the project was started. For our service we have an agent that installs a Prometheus agent (and some other ones) on the customers K8s cluster. The upsides of running the agent on their side is that they benefit from Prometheus' automatic service discovery. They can also use standard Prometheus configuration and scrapers to get the full capabilities for their environment. There are also situations where the user wants to continue to run their own Prometheus, but down sample and send a limited number of metrics for long-term storage in the Weave Cloud SaaS. This can be done with one line in a standard Prometheus. It's true that running the agent takes resources, I think the benefits are worth it. For most people the key question is getting the full value from their metrics data to enable better development and operations. [NOTE]: Full Disclosure I work at Weaveworks where we provide Prometheus-as-a-Service (https://www.weave.works/features/prometheus-monitoring/)

Weaveworks | Senior Backend Engineer, Senior Frontend Engineer | San Francisco, London, Berlin, Madrid | ONSITE, Full-time, https://www.weave.works - Senior backend engineer: develop microservices (primarily in Go) and container tools - Senior frontend engineer: Design and implement reactive web UIs that visualize complex data using state-of-the-industry tools, like React and D3 Come help us build OSS tools that other developers use to tame their containerized applications. Projects like Weave Scope observe containers/pods/services and their interactions to provide visibility and insights. Developers can quickly see the state of the resulting systems and validate their assumptions. We offer family-friendly hours (some of us have kids, too) and encourage a good work-life balance. Feel free to work from home on certain weekdays, or combine work and travel for a month. It's no big deal if you're not a Go expert, we trust that you can learn on the job. Also, all our tools are open source: https://github.com/weaveworks Browse our PRs to see how we work as a team! The hiring process: Checking your CV/GH/SO (if not enough signal: small coding challenge), 45 mins hangout, afternoon take-home coding/design challenge, in person interview with future colleagues If you’re interested please drop us a line with your desired location at jobs (at) weave.works Note: Weaveworks is not set up to sponsor visas at this point.

Weaveworks | Senior Backend Developer | San Francisco, London, Berlin, Madrid | ONSITE, Full-time, https://www.weave.works * Senior backend dev: develop microservices (primarily in Go) and container tools * Senior frontend dev: write reactive and snappy web UIs that show complex data and are easy to navigate (Berlin only) * Developer experience/evangelist: spread the word in meetups/conferences, develop integrations for our tools Come help us build OSS tools that other developers use to tame their containerized applications. Projects like Weave Scope observe containers/pods/services and their interactions to provide visibility and insights. Developers can quickly see the state of the resulting systems and validate their assumptions. We offer family-friendly hours (some of us have kids, too) and encourage a good work-life balance. Feel free to work from home on certain weekdays, or combine work and travel for a month. It's no big deal if you're not a Go expert, we trust that you can learn on the job. Also, all our tools are open source: https://github.com/weaveworks Browse our PRs to see how we work as a team! The hiring process: Checking your CV/GH/SO (if not enough signal: small coding challenge), 45 mins hangout, afternoon take-home coding/design challenge, in person interview with future colleagues If you’re interested please drop us a line with your desired location at jobs (at) weave.works Note: Weaveworks will consider visa sponsorship on case-by-case basis,…

Core Engineer at VC-funded open-source project, Weaveworks, London Weaveworks is a start-up founded by the team that created RabbitMQ and backed by one of the world’s leading tech investors. Headquartered in London, we are hiring engineers to work on our open source software product, Weave. The purpose of Weave is to enable all developers, no matter what their background, to take advantage of container technologies such as Docker and build better software applications. We believe that containers will lead to much more software being built at greater speed and scale than ever before, so much so that many existing approaches will need to be reimagined. We have an experienced team and welcome newcomers who want to progress fast, as well as domain experts in relevant technologies. Currently Weave is a set of network services written in Go, packaged to make distributed Docker applications much easier to construct. But we have considerable ambitions, and the space is evolving rapidly, so we especially seek developers with the right outlook and ability to adapt. Ideally you have real world experience of building and running systems with a focus on resilience and uptime. You are as comfortable designing or debugging a distributed protocol as you are talking to customers building a web app or scaling a data service. We hope to meet developers who share our values: - Complete focus on the simplest possible user experience - A real desire to innovate, and then measure success by…

FYI the link to Flux in > Particularly with GitOps and [Flux](https://www.weave.works/oss/flux/?ref=blog.yaakov.online), making changes was a breeze. appears to be broken. EDIT: oh, I hadn't realized the article was a year old.

We're the folks behind tf-controller, a nifty GitOps tool bridging Flux and Terraform. We just wanted to clear the air that our tf-controller project happily coexists alongside HashiCorp's offerings, with no intention to compete. More here: https://www.weave.works/blog/statement-for-terraform-hashicorp-license…

To me, GitOps means reconciler that can actively move the system (kubernetes or whatever it is) back into the desired state if the actual state changes. Flux is a reconciler. Everything else is CIOps[1] [1] https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-…

I've recently heard about GitOps - https://www.weave.works/technologies/gitops/ but also https://about.gitlab.com/topics/gitops/

Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0], so it has to be done in C before the go runtime initializes. I do think rust is a better choice for this layer than C because there are still security risks, but getting rid of Go for this layer is a win. I'm not sure why RH chose to rewrite it in C rather than using rust[1]. [0]: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix [1]: https://github.com/drahnr/railcar

There are a few ways to use k8s + firecracker, weave has one: https://www.weave.works/oss/firekube/

It would be unfair to simply mention about a technology's "problems" without mentioning even a single point of "features". IMO, Itamar Turner-Trauring has misrepresented Kubernetes. The sole reason of Kubernetes being popular and uprising is because there are genuine pros and features that make many people's lives easier instead of more miserable. So let me point out the pros here: [1]: https://www.infoworld.com/article/3173266/4-reasons-you-should-use-kub… [2]: https://hackernoon.com/why-and-when-you-should-use-kubernetes-8b50915d… [3]: https://opensource.com/article/19/6/reasons-kubernetes [4]: https://www.weave.works/technologies/the-journey-to-kubernetes/

Can’t tell if grandparent post wants to manage apps on a cluster (see below) or apps that are a cluster (see https://cluster-api.sigs.k8s.io/) If it’s letting a dev manage apps on a cluster someone else let them put apps on, while staying in dev mode, maybe devs could appreciate the cluster provisioning SREs enabling app devs with so-called GitOps or AutoDevOps approaches, prescriptivist ways of leveraging Docker, K8s, and Helm, such as: https://www.weave.works/blog/what-is-gitops-really https://docs.gitlab.com/ee/topics/autodevops/index.html

It's usually enough, but not always. For example namespaces and new threads don't handle this well, even if you do LockOSThread https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix

Very cool to see WireGuard being used in a mesh implementation. This reminds me of Weave[0] which has worked well for me. I'll definitely be experimenting with Wormhole. [0] https://www.weave.works/oss/net/

Weave Scope can do that: https://www.weave.works/oss/scope Edit: Not affiliated

And this from Weaveworks: https://www.weave.works/oss/cortex/

Absolutely. I can't imagine doing it any other way anymore. https://www.weave.works/blog/gitops-operations-by-pull-request One of the major reasons Kubernetes is a thing is because all of your deployment can be declarative. Deploy-via-Git means I can destroy my entire world and bring it back in a minute or less.

There's nothing about Go that makes it particularly good for containers. It actually requires some ugly hacks in C to make it handle namespaces correctly (because namespaces are configured per-thread, and Go decides to spawn new threads somewhat arbitrarily which is not visible to the program). https://github.com/docker/libnetwork/issues/1113 https://github.com/docker/libcontainer/tree/master/nsenter https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix EDIT: TIL this is fixed in Go 1.10 which came out in February: https://golang.org/doc/go1.10#runtime If rust continues to improve ergonomics and library support, I don't see anything stopping it from replacing C except in niche embedded systems that don't get LLVM support.