alexk

Can I offer a complementary non-practical founders reading list then? :)

* Dostoevsky "Crime and punishment".

Discover how important is to take care of yourself and avoid entering the downward spiral of depression and anxiety.

* Jack London "Smoke Bellew".

Get a boost of the startup-like resourceful energy the heroes of the previous Golden-Rush at Klondike.

* Herman Hesse "Siddhartha".

Get a break from the startup grind by going on the spiritual journey of self-discovery and peaceful reflection.

* Arkady and Boris Strugatsky. "Far Rainbow".

Get to know the limits of human intelligence and capacity for overcoming the difficulties.

Hope you enjoy it!

The community is not static, and new people join every day. Also, lots of people never heard about signal and would be interested to learn about it.

Without MIT.... but with Apache2 ! :)

https://github.com/gravitational/gravity

In all seriousness though, gravity is an open core toolkit to package and deliver complicated sets of micro services in air gapped and restricted environments as a virtual installable appliance.

It takes care of both application and Kubernetes lifecycle, software distribution and licensing workflows.

This looks very useful, I'd definitely buy a book on the subject. Does anyone know about more Go-specific performance book/articles out there? Please share!

Gravitational (YC S15) | Systems Engineer | Seattle, Toronto | https://gravitational.com

Do you enjoy building security and deployment tools for other engineers? Join us to hack on open source software in Seattle or Toronto. Most of our code is Go, we have very little technical debt, our codebase is clean and small.

We expect you to be comfortable with the following (and if you are not, we’ll help you get there):

  * Go.
  * Linux, networking.
  * Kubernetes.

We’re looking for junior and senior engineers to join the team. Gravitational is a company started by engineers to build products for engineers. We are not a SaaS, we are stable, profitable and growing.

We offer:

  * Competitive salary and equity.
  * 401k with company match.
  * Christmas bonus.
  * Offsite retreat for everyone once a year.
  * Excellent health insurance.
  * Flat company structure: report directly to the CTO.
  * Relocation package, including international relocation to Toronto.

Apply: jobs@gravitational.com

James, we respectfully disagree.

I think it's helpful if you (or anyone reading this) compare two projects side by side.

This is the project you have submitted:

https://github.com/jameskeane/scrambler

It is a prototype of IPSec CNI plugin using Bash. We are happy you are promoting your project online and as we've discussed during the interview, you could use it as you wish as it's your work.

This is the project that we have created at Gravitational:

https://github.com/gravitational/wormhole

It is using Go, Wireguard and is designed for production use under Apache 2 license.

I understand that similarities in the problem statement may have led you to believe that we could re-use the project idea, I'm assuring that you that we have not.

There are many OSS CNI plugins in the market solving the similar problem in a similar fashion (e.g. flannel with IPSec backend).

As a matter of fact that's the main reason we have picked this as a problem statement - to make it easier for candidates to look around for prior work.

For example, this is a submission of the engineer we've hired based on their similar execution of the assignment from April 2018:

https://github.com/webvictim/k8s-ipsec-cni

James, I wish you the best and hope that my response clarifies some confusion around this.

Sasha, CTO and co-founder at Gravitational

Gravitational (YC S15) | Multiple Positions | Toronto, Oakland | ONSITE REMOTE | https://gravitational.com

We are building next generation, open source systems software: Teleport [1] and Gravity [2]. We are profitable (through an open-core model) and growing quickly but we still focus on maintaining a work-life balance. We also value our craft and being nice and respectful to each other.

If you enjoy learning and creating systems engineering software as much as we do, or would like to help us sell or write about it, join us:

  * As a Sales Rep [3]
  * As a Senior Golang/Linux systems engineer, Teleport [4]
  * As a Technical Writer [5]

We have two great offices in Toronto and Oakland. For some positions you can also work anywhere from U.S.

Learn more: https://gravitational.com/about#jobs Apply: jobs@gravitational.com

[1] https://github.com/gravitational/teleport [2] https://github.com/gravitational/gravity [3] https://gravitational.com/careers/sales-reps/ [4] https://gravitational.com/careers/systems-engineer-teleport/ [5] https://gravitational.com/careers/technical-content-creator/

I think this project is very cool, great job on splitting the internal logic into components too!

What type and model of networking do you use on 15K servers? Can you share some specs?

It's probably closer to multi-writes though, than transactions in a classic sense, but good improvement nevertheless.

Right, because we write against DynamoDB/Etcd transactions were a non-option anyways, and we only have CompareAndSwap as a locking primitive

https://github.com/gravitational/teleport/blob/master/lib/ba...

In addition to that Golang's context

https://golang.org/pkg/context/

is used to broadcast the failure of a distributed operation and release associated resources with it

I think that microservices are just a deployment model of the service boundary and there should not be really a distinction between whether something is deployed as a microservice or a monolith, because application should support both for the scenarios when it makes sense.

Consider the following API:

  UsersService:
   CreateUser
   GetUser

  AppCatalog:
   GetApp
   CreateApp

What if AppCatalog and UsersService implement both local version of the interface and GRPC one? Then the distinction whether it's a microservice vs a monolith goes away, it becomes a matter of whether they are deployed in a single linux process or across boundaries of processes/servers.

I have implemented this technique in teleport:

https://github.com/gravitational/teleport/tree/master/lib/se...

Integration test suite is run against RPC version and local version at the same time to make sure the contract remains the same:

https://github.com/gravitational/teleport/blob/master/lib/se...

A single teleport binary can be deployed on one server with all microservices, or multiple cluster scenarios.

where the binary is simply instantiated with different roles:

  auth_service:
    enabled: yes
  node_service:
    enabled: no

Is Teleport a monolith? Yes! Is it a micro-service app? Yes! I'm so happy that we don't have to think about this split any more.

This is Embarcadero West, right near Jack London Square!

We moved from SF to Oakland more than a year ago and could not be happier! Here's the view from our Gravitational's Oakland office right now:

https://imgur.com/2p9BX1b

Gravitational (YC S15) | Multiple Positions | Toronto, Oakland | ONSITE | https://gravitational.com Gravitational builds open-core software to automate the delivery and operations of cloud-native software across multiple locations (multi-cloud and on-prem). We are looking for ambitious and talented people across engineering and go-to-market (sales/marketing). Here are some of the things we have built in the past: Mailgun[1], Vulcand[2], OnMetal [3]. And some of the things you will help us with currently: Teleport[4], Gravity[5], Teleconsole[6].

Open positions include:

  * Fullstack engineer (React expertise a +)
  * Head of marketing (demand gen, content marketing, dev evangelism and general growth)
  * Sales Development Reps (qualifying inbound and participating in outbound campaigns for handoff to sales reps)
  * Senior Golang/Linux systems engineer, Teleport

Locations: Toronto, Oakland, Remote Open positions on our about page and github careers: https://gravitational.com/about#jobs

https://github.com/gravitational/careers/blob/master/systems....

Apply: jobs@gravitational.com

[1] https://www.mailgun.com [2] https://github.com/vulcand/vulcand [3] https://www.rackspace.com/cloud/servers/onmetal [4] https://github.com/gravitational/teleport [5] https://github.com/gravitational/gravity [6] https://www.teleconsole.com/

That's helpful, thanks, clarifies key differences in design of Cassandra vs FoundationDB. Are you using a lot of FDB in prod? What are your impressions so far?

What are your next steps with this project?

This looks very interesting. How do you think this concept will perform on larger files (assuming it goes past prototype).

For example, when we started storing data chunks in Cassandra, we found that Cassandra's performance was not optimal due to the way it was dealing with compactions and deleted data.

I'm not familiar enough with FoundationDB's data model design, so would be interesting to know what do you think about possible developments of this project.

I enjoyed reading your blog post and the points you've mentioned are really important, for example suid bit is something that is not obvious at all.

If you'll ever get to writing similar guide for Kubernetes, ping me and I'd be happy to make it a guest blog post at gravitational.com

> I don't think anyone wants to use Helm.

Here is why everyone should use Helm:

Helm 2.0 introduced package as a first-class concept for Kubernetes and created the standard to distribute applications, thanks to Helm thousands of people could discover and collaborate on cloud-native deployments of the open source software https://github.com/helm/charts/tree/master/stable published and managed by organizations and contributors all over the world.

Helm 3.0 keeps innovating, it adopts the most forward-thinking approach to package management and Kubernetes config management by using higher level domain specific language based on Lua to create expressive package management system:

https://sweetcode.io/a-first-look-at-the-helm-3-plan/

Helm is also backed by CNCF[1] and is the best choice so far for organizations to create a reproducible CI/CD pipeline in a Kubernetes cluster.

[1] https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/

Gravitational (YC S15) | Multiple Positions | Toronto, Oakland | ONSITE REMOTE | https://gravitational.com

Gravitational builds open-core software to automate the delivery and operations of cloud-native software across multiple locations (multi-cloud and on-prem). We are looking for ambitious and talented people across engineering and go-to-market (sales/marketing). Here are some of the things we have built in the past: Mailgun[1], Vulcand[2], OnMetal [3]. And some of the things you will help us with currently: Teleport[4], Gravity[5], Teleconsole[6].

Open positions include:

  * Fullstack engineer (React expertise A+)
  * Sales Development Reps (qualifying inbound and participating in outbound campaigns for handoff to sales reps)
  * Senior Golang/Linux systems engineer, Teleport

Locations: Toronto, Oakland, Remote Open positions on our about page and github careers: https://gravitational.com/about#jobs

https://github.com/gravitational/careers/blob/master/systems...

Apply: jobs@gravitational.com

[1] https://www.mailgun.com [2] https://github.com/vulcand/vulcand [3] https://www.rackspace.com/cloud/servers/onmetal [4] https://github.com/gravitational/teleport [5] https://github.com/gravitational/gravity [6] https://www.teleconsole.com/

As someone who actually builds things you have more leverage than you think in this or any other conversation with your manager, you need to learn how to use it better.

I think you would find negotiation practices helpful, e.g. check out the book "Never split the difference" to learn some negotiation techniques and "Elephant in the brain" to understand that this behavior is likely not about technology.

> But say we went with that. Then we'd need to adopt an existing JS engine (most likely written in C++) and then modify it based on our needs.

This is definitely not an easy choice to make and writing a new language interpreter in Go seems a way easier approach initially.

One thing that Go helped me to understand though, is that the language does not matter so much as the tooling around it - debugging, compiling and support around the language are way harder to achieve than writing a language parser.

Thanks for sharing your thoughts on this design choice, I think this discussion is very relevant for a couple of reasons:

There are other Go projects that are taking the same approach to achieve simplicity and not picking the existing language, like OPA [1]. Others, like Helm are picking Lua [2], so there is clearly a problem the Go and infrastructure community is facing and split in the way people are approaching it.

We've faced the similar dilemma with Teleport, as we are designing our extensions system. My original plan was to use Lua, however after discussions with the team we settled on GRPC with Go [3], trading expressiveness/simplicity and freedom of lua/js languages in favor of industrial features Go runtime and GRPC provides out of the box.

For smaller extension plugins we decided not to create a new language, and ended up with interpreted subset of Go [4].

I wonder if there is a place for some subset of javascript or typescript that is fully interpreted by Go, with native extensions for debugging to be used by the community.

[1] OPA policy agent https://www.openpolicyagent.org/ [2] Helm 3.0 Lua plugins https://github.com/helm/community/blob/master/helm-v3/005-pl... [3] Teleport Plugin Design Document https://docs.google.com/document/d/1sPXXxx03P8VXWy-YD5w190g7... [4] Subset of Golang https://github.com/vulcand/predicate

>We chose not to use Lua because it's not a widely known language. Instead, we chose to create a language that looks and feels much like Javascript

This makes sense, in this case why not take strict subset of Javascript?

> Finally, one goal with including the UI in InfluxDB 2.0 is that as we improve it, most users won't have to learn Flux at all. They'll be able to accomplish what hey want by just clicking around the interface.

This will definitely will be helpful, and auto generation makes sense, however in our use-cases we treat Kapacitor alerts as a code that is reviewed.

That's my feedback on TICK as well, it's pretty hard to debug and implement something like this:

https://github.com/gravitational/monitoring-app/blob/master/...

I looked at flux, and it seems pretty compatible with TICK script, although I don't have a clear understanding on how to make it easy to write alerts/queries and debug them yet.

I would be curious to try out REPL:

> We plan to provide a flux command line program that exposes a REPL and talks to various data sources.

Especially interested to see how easy it would be to edit and troubleshoot a multi-line transformation query like this one in it:

   cpu = data 
       // only get the last 5m of data
       |> range(start: -5m)
       // only get the "usage_user" data from the _measurement "cpu"
       |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_user")

Why create a new language vs using javascript or lua?

e.g. your flux example above could have been just:

   let cpu = data.range({start: "-5m"}).filter(func(r){return r.measurement == "cpu" && r.field == "usage_user"})

Is there any specific feature of flux that requires a new language? I read your blog post here:

https://www.influxdata.com/blog/why-were-building-flux-a-new...

and it brings some valid points on Flux vs SQL, however I would be interested how would it compare as Flux vs Javascript or Flux vs Lua :)

My favorite identity provider of all time is https://auth0.com

I was very impressed by their rules concept [1] that allowed me to create quite non-trivial authentication scheme in one day from scratch [2] They also pay attention to development workflows by having great logs and debugging tool chain as a part of their service, very cool!

[1] https://auth0.com/docs/rules [2] https://gravitational.com/blog/aws-github-sso/

Gravitational (YC S15) | Multiple Positions | Toronto, Oakland | ONSITE REMOTE | https://gravitational.com

Gravitational builds open-core software to automate the delivery and operations of cloud-native software across multiple locations (multi-cloud and on-prem). We are looking for ambitious and talented people across engineering and go-to-market (sales/marketing). Here are some of the things we have built in the past: Mailgun[1], Vulcand[2], OnMetal [3]. And some of the things you will help us with currently: Teleport[4], Gravity[5], Teleconsole[6].

Open positions include:

  * Fullstack engineer (React expertise a +)
  * Head of marketing (demand gen, content marketing, dev evangelism and general growth)
  * Sales Development Reps (qualifying inbound and participating in outbound campaigns for handoff to sales reps)
  * Senior Golang/Linux systems engineer, Teleport

Locations: Toronto, Oakland, Remote Open positions on our about page and github careers:

https://gravitational.com/about#jobs

https://github.com/gravitational/careers/blob/master/systems...

Apply: jobs@gravitational.com

[1] https://www.mailgun.com [2] https://github.com/vulcand/vulcand [3] https://www.rackspace.com/cloud/servers/onmetal [4] https://github.com/gravitational/teleport [5] https://github.com/gravitational/gravity [6] https://www.teleconsole.com/

I figured that you have to click "Explore" next and then see the Logging tab, although it was not easy for me to find, may be highlight it as a first class link on the left panel?

For Grafana folks: I got all the way through sign up and sending logs from k8s cluster + setting up logging data source to Loki hosted instance, but could not find a way to actually explore the logs in the hosted grafana instance :)

Hey, these are some pretty wild speculations!

I've had a chance to interact with Craig and Joe on multiple occasions and got an impression that they are rock solid both in their business strategy, team building, technical execution and vision, so not sure where do your assumptions are coming from?