We've been using Honeycomb at Nylas for 6+ months at this point and love it - the product keeps getting better and better, it's fast and reliable, and it's given us new debugging capabilities that make investigating outages and digging into system performance easier than they were before.
We've also built our own ELK cluster (three times!) and can attest that it takes very significant engineering effort to get a scalable, reliable, high performance cluster, and the ongoing cost in hardware is easily hundreds of dollars a month or more.
Three things that we can do with Honeycomb that we can't do with ELK (or at least not easily):
* Quickly iterate on questions to explore datasets. It makes a huge difference in how you approach a tool when the time between question and answer is milliseconds, not seconds.
* Compare trends in data - Honeycomb can easily group data by field and display many lines on the same graph. As an example: easily break down your API traffic by endpoint to pinpoint a spike in traffic to a specific endpoint. (Or by endpoint and customer, etc.)
* Calculate percentiles, averages, etc. on our data in real-time - without having to set up the calculated metrics beforehand. This makes honeycomb a better tool for performance monitoring than ELK imho.
There may be ways to do some of these things with ELK, but not out of the box and, given the indexed data store behind the stack, it's just not architected to have these same capabilities.
I suspect if you dug into some of Honeycomb's other blog posts, this difference would become more apparent. :)
For now, the encryption plugin is only available on the older version, Nylas Pro. No reason for that other than time to port and QA the plugin to the new free version, which has a completely written mail sync engine that runs locally rather than in the cloud. We're working on porting all Nylas Pro features to the new version as fast as we can!
If you want to keep up to date about the latest features, you can sign up for our newsletter at the bottom of this page: https://nylas.com/nylas-mail/
No new funding model, just better tech! In the new version, we don't sync and store all of your email on our servers, which dramatically drops the cost of running the service.
N1 supports connecting to all the major email providers, as well as pretty much every obscure IMAP server run by your ISP! What's pointed out in the FAQ is just that it uses a cloud service component (also open source! http://github.com/nylas/sync-engine) that we developed first to make it easier to build clients.
Super sad to hear about this, as the Debian project has been hugely influential on my life. (It's the reason I went to MIT and became a software engineer.) Rest in peace, Ian.
Nylas | SRE | San Francisco, CA (ONSITE) | https://nylas.com | Full Time only
Nylas is like a race car moving at 200 MPH, and you are a member of the pit crew--swapping the tires and refueling without slowing down! We're looking for a Site Reliability Engineer to take our infrastructure to the next level, with a focus on tools, availability, performance, and scale.
Critical to this role is supporting the entire engineering org in moving quickly, which includes running our internal tooling infrastructure, creating systems that make migrations/alerts/tests easy to write and run, and further improving our continuous integration and deployment workflows. You should love measuring things, making data-driven decisions, and have excellent written communication skills. As this is an engineering role, you should also be comfortable writing substantial amounts of production-grade code (although it may not be your focus). Bonus points for a deep love for large distributed systems, a knack for creating elegant tools, and experience participating in an on-call rotation and running on AWS. Double bonus points for clear, direct communication and a call-it-like-it-is attitude.
Some technologies we use: Python, AWS, MySQL, Redis, Ansible, Elasticsearch, Kafka, ZooKeeper
I don't expect that we'll have time to put this together officially very soon. If you'd like to help though, the best way would be to figure out how to get N1 building on arch from the open source repo!
You can, but remember the sync engine doesn't provide any authentication layer by default, since people use it in so many different ways. You'll want to run it proxied behind some sort of authentication service. (With AWS, you can do this with different subnets via VPC.)
Bundling the sync engine with the client works if you're willing to download your entire mail archive onto every device that connects to your mail. An implementation of the sync engine that allowed only syncing partial mailboxes would be very difficult to implement on top of (all of) IMAP, Exchange, and Gmail. By abstracting that away into a new cloud service, clients end up being both simpler and more flexible.
It's not something we're likely to support officially in the near future since we don't run PostgreSQL and don't have the ability to test it well with production loads, but it'd be neat to see a working community fork.
Yep, the only reason we didn't have one for launch is a lack of time. :) You want to help? First step is making sure `script/grunt mkrpm` works from https://github.com/nylas/N1!
The main codebase is in `inbox/`, with launcher scripts and tools in `bin/`.
(Might not be totally obvious, because the package namespace is called `inbox/` for legacy reasons.)
If a beginner wants to see real production code, rather than toy examples, I think it's inevitable that there will be some points of confusion. Part of the learning process is diving in and exploring and being okay with not totally understanding everything that's going on. :)
We've also built our own ELK cluster (three times!) and can attest that it takes very significant engineering effort to get a scalable, reliable, high performance cluster, and the ongoing cost in hardware is easily hundreds of dollars a month or more.
Three things that we can do with Honeycomb that we can't do with ELK (or at least not easily):
* Quickly iterate on questions to explore datasets. It makes a huge difference in how you approach a tool when the time between question and answer is milliseconds, not seconds. * Compare trends in data - Honeycomb can easily group data by field and display many lines on the same graph. As an example: easily break down your API traffic by endpoint to pinpoint a spike in traffic to a specific endpoint. (Or by endpoint and customer, etc.) * Calculate percentiles, averages, etc. on our data in real-time - without having to set up the calculated metrics beforehand. This makes honeycomb a better tool for performance monitoring than ELK imho.
There may be ways to do some of these things with ELK, but not out of the box and, given the indexed data store behind the stack, it's just not architected to have these same capabilities.
I suspect if you dug into some of Honeycomb's other blog posts, this difference would become more apparent. :)