vaidik

Interesting. The github repo seems to be an indirection for the purpose of this post to the actual repo which has the software. Would have been nice that you just used the actual github link. I discovered some other interesting things in the main repo - CI/CD, GitOps, governance related features. Would be nice that other viewers can also discover them. Those are definitely a big requirement for most teams starting their journey on kubernetes. But anyways, looking forward to trying this out myself soon.

Ah this is nice! I always found Superhuman too expensive.

Try Cidescene.io

So useful. I have been wanting this feature.

Thoughts on Haskell?

Good stuff. We are doing the exact same thing at Grofers (more or less). Our philosophy of our service registry is exactly the same - using services to connect kubernetes objects to AWS resources to monitoring dashboards to github repos.

The place where we differ is: * YAML instead of JSON * A lot of python based tooling to do the plumbing * We don't always rely on terraform for provisioning everything so we have monitoring of new resources in AWS and policies on how those untagged resources will be treated

Good to know that there are more people thinking in a similar way. Validates our approach. :)

Would love to chat in person to learn more about the setup and exchange ideas if you are up for it.

DevOps is about collaboration between devs and ops towards building software and operating it efficiently to meet business needs. Traditionally building and operating were looked very differently but experience has taught us that features and stability cannot be achieved without understanding of how features were built and what needs to be done to run those features in production efficiently. In an ideal world, the same person should be able to build and operate systems in production however we don't live in an ideal world - traditionally there was a big divide between devs and ops, and in complex environments you can't learn to do everything yourself. Hence... DevOps.

There are multiple ways this can be achieved. This article is a good read to understand different models of implementation of DevOps culture - https://web.devopstopologies.com/

"DevOps is Ops with new tools. I went to DevOpsDays thinking DevOps means developers and operations merged into one team. I was wrong." - This is kind of right but not completely. DevOps is about bringing ops closer to dev teams by either merging ops or retraining devs to be able to be better at ops (there are more ways as indicated in the above article about DevOps topologies). The idea of doing ops with new tools is that these new tools help us with doing ops like we are building software. Many software development best practices, abstractions, architectures can be now applied to ops as well. This shift in doing ops with these tools which are a lot like other software development tools enable ops to come closer to devs and vice-verse. Here is a great talk by Mitchell Hashimoto (the creator of Terraform, Packer, Vagrant, Vault, etc.) that got me into DevOps - https://www.youtube.com/watch?v=UTQQggVx4sI. This talk explains the use of tools with the backdrop of DevOps.

Other than these two things, your observation was spot on. I was not at the event but that's the story at most DevOps events.

I think software architecture will soon become an area of focus in DevOps circles as the right architecture also essential for achieving CI/CD, agility and DevOps.

Never the less, welcome to the world of DevOps. :)

Also, what's up with the in-your-face hiring pitch right in the documentation?

https://netflix.github.io/pollyjs/#/README?id=we39re-hiring

I used to use nock which would work very well in node environments. But this works in the browser as well. So I guess this can be fairly helpful while writing tests post development. If you are doing TDD, then recording/replaying doesn't fit anywhere in the development cycle.

I like the API of this library and the browser support that was missing in nock. So thanks Netflix! Although it would have been nice to see nock add this support. Which is what I wonder - why not just contribute to existing libraries.

We have been using Redash at our company for almost a year now. Every single release just proves how promising the project is. You can make useful dashboards in minutes. Support for multiple databases is amazing. We are using it with multiple PostgreSQLs, Redshift, MongoDB and InfluxDB.

The most valuable feature is alerts though. I work at an ecommerce and operations heavy company where we have tons of connected components. Where alerts come really handy for us is that anyone in the organization can add quick alerts for proactive monitoring of events recorded in on-field ops and act when things go bad. This almost like building a feature on one of the internal tools, just doing that yourself without any engineering support. This comes in really handy.

Kudos to the team! Looking forward to some more amazing stuff in Redash!

Well it will soon land in stable as well I am sure. But its amazing to see major browsers moving in this direction and educating users about security.

When we started out, we were short on time and thought of using either whichever covers most of our target user base. Zopfli works everywhere whereas Brotli is not supported everywhere. Also, Nginx does not support Brotli out of the box and had to be compiled. Since there were some complexities as well, we went ahead with Zopfli only.

Now that we have more time, we have the luxury to setup infrastructure for serving both Zopfli and Brotli. Perhaps one of the next steps for us to make our website even faster.

Precisely why you need review processes ;)

Yes you are right. In fact, a simple work around, before Elasticsearch coming out with this feature in their 2.x releases, was to review mappings and what goes in Elasticsearch. And we got careless about that and shot ourselves in the foot. We learned it the hard way.

Yes it would have. But as I said in one of the other comments, they are doing something about this in 2.x releases. And this reference is from 2.x release's documentation.

Wish we had it back then. We are currently on 1.4.

Impatience at times is root of so many things going wrong. The thing I read again and again and again and failed to see.

Thanks :)

And BTW, that is something that Elasticsearch recommends you to do that manually in the current versions as well. Read this: https://www.elastic.co/guide/en/elasticsearch/guide/current/...

I might be missing something. But to my understanding I think it is correct. I didn't quite get what you exactly mean by that? Educate me please.

To explain myself, I meant that tests that were succeeding previously would have failed due to this issue if we had tests written for it. Does my statement not convey this?

Not completely sure about this. But may be we are just not in the same circles of other fields where things like these are shared. I can only speak for myself obviously. But it would be hard to believe that people in the field of medical sciences don't practice this.

Something I wondered too. But I think in the 2.x versions, they are already planning something around it. Honestly, I have not looked at it much yet but even creating another mapping with the same field name but different type should perhaps throw a warning or not be allowed unless overridden as they lead to things like these.

Thanks :)

Correctly pointed out. Perhaps calls for an edit.

Agreed. We don't use it as a primary database as well. In fact, all of our data persists in PostgreSQL. However, a smart thing for us to do would have been using PostgreSQL as a fallback (postgis for spatial queries, something that we heavily do with Elasticsearch).

Obviously incidents like such have made us cautious and we will be working on fixing these architectural issues quickly.

Unverified certificate. Haha. Is this a joke?

Seems like they are back up now. 100% HA is a myth, for even those who can afford it.

https://www.dropbox.com/s/zueam1oq3sdzv36/Screenshot%202015-...

Good. Probably no. But there is Saucelabs.

Congrats Greg for your first product! At least it looks fantastic! I haven't tried it properly yet. But I hope to see many more awesome things like ReadMe in the future.

And I am amazed to see that you guys pulled it off with the living in a different country bit. Amazing! :)

We are using RocksDB as well for something. Although based on LevelDB, but its pretty different now. So can be added as a separate entry.

Just yesterday I was discussing with a friend how we haven't seen anything new in Kippt. I have been one of the first users of Kippt. Somehow the product was becoming slow for me. And I was not sure where the team and the product was headed.

Kippt helped me a lot with organizing things that I share. I hope this was a good journey for the Kippt team and I wish them all the very best for their future endeavor.