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.
I’m learning Haskell right now and had the same question until I found Hindley’s Lambda-Calculus and Combinators: an Introduction book. Many here are recommending Julia but I’ve used Julia enough now to conclude that it isn’t as mature as Haskell and can be frustrating at times. Haskell, when it’s foundations and history are well understood not only challenges how you think about programming but also of mathematics.
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.
Hey! I'm always up for chatting about this type of thing. Great to trade ideas and experiences, I find you always come away with something new to think you.
If you want to email me at me@lawrencejones.dev, we can sort a virtual coffee.
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. :)
I assume that devs read the documentation, and they want to hire devs, and it's their tool, so they put their hiring pitch in their documentation for their tool to try and hire devs
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.
It lets you create & configure mock HTTP servers for JS testing, but with one API that works out of the box in Node and in browsers. This avoids the record/replay model too, so you can still take the TDD approach and define your API behaviour in the test itself.
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!
