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.
When you say authentication, do you mean the cloud engine doesn't authenticate against your email providers, or that the desktop client doesn't authenticate against the cloud engine?
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.
My involvement in Debian is part of what helped me become a programmer too. I didn't go to college for CS, so finding a group of smart people to learn from was hugely influential.
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
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. :)