lmickh

Interesting test, but I find some of these benchmarks kind of miss the point. Even Grafana's.

The appeal of Thanos/Cortex/Mimir is the long term object storage. The value isn't that it is simpler or cheaper to run. The value is that I can compare data to months if not years ago. It can cost much more than the price of the instances to store good metrics over time even when the data is rolled up.

Scaling the read/write path separately has a lot of benefits as well too, but I would guess that doesn't come up often for most folks.

How much telemetry you can get in/out of your system over a day is important, but how much you can get in/out of it over years is overlooked.

I wouldn't go so far as to say there wasn't much purpose for the ground troops in the context of the goal of eliminating Iraqi military capabilities. It involved some of the largest tank battles in US history such as the Battle of Norfolk and the Battle of the 73 Easting. While we look back at some of these as a steam roll in hindsight, the truth is the engagements were larger than most of the armor battles in WW2 involving the US.

The marine advancement in to Kuwait that was part of a larger multi-national push that much of the Iraqi forces were running from. The push by 1st Inf Div, 2nd ACR, and others on the west was to cut off that retreat.

Combat theaters are large and it is never a good idea to take a narrow view of them and generalize it to the whole. The father of my childhood friend used to tell us how his deployment in Vietnam as an MP was some of the best time in his life. He spent his entire time on a post relatively far from the fighting largely killing his time trying to surf and eat BBQ.

Casualties in warfare is typically used to measure the lose of the fighting force. Not only does it include killed and wounded, it typically also includes troops lost to disease and starvation.

It is pretty common for people to misinterpret casualties as deaths. Especially when people who are not familiar with the terms try to repeat the information to others.

There is also the common practice of not including discounts in revenue. There is a reason companies talk about revenue instead of net sales or net income.

I've never seen AWS give discounts comparable to what Azure provided. Especially to larger companies they want the brand recognition from.

Hundreds of developers were moved from Azure teams to the GitHub org about a year or so ago. Several new features they have added are effectively rebranding/built on top of other Azure projects.

GitHub is hardly at arms length from MS.

If you think the game was a disappointment, doesn't that imply you already gave them the money? It is not a service. If you bought it 5 years ago, you don't have to pay more to play it.

CNN and 24hr cable news has not been good for journalism. Opinion pundits responding to events before the facts can even be collected along with daily shows interweaving narratives pre-dates Fox News. Fox News played their game more blatantly ruthless than the others and beat them at their own game.

Burke Libbey has a few talks that are available on YouTube including a presentation at NixCon about the work he is doing at Shopify. I would highly recommend checking them out if you are interested in Nix.

You use the language to define the configuration, packages, and etc. NixOS isn't so much an OS configured by a package manager as much as it is an OS + package manager that you can configure with the Nix language.

Then there is also lot of tooling to hid all of the symlink magic. It is very deep rabbit hole. Most of the quick touch examples will basically look like magic.

It is pretty easy to be confused. Especially since it is also a language yet all the other replies at the time have writing have failed to mention that.

While I like the project as a whole, their naming is horrible. Just wait until you get into `nix-env` vs `nix-shell` etc...

I like how it pretty much just glosses over decades of familiarity. If there is anything the last 20 years prove, it is that the majority of developers will stick with what they know over what might be a good fit for the job. It goes even deeper in the SQL world down to the specific database flavor.

From the ops side I actually find RDBMS more difficult to deal with cause the power of relationships is easy to abuse and they are not anti-fragile. Instead of smartly reasoning about the data, it is all to easy to just "JOIN ALL THE THINGS WITH MEGA TEMP TABLES!". I've taken more database outages from bad queries then anything else.

There are bad implementations on both sides. There are reasons to pick both sides over the other given a set a circumstances. At the end of the day, the technical facts don't matter to most people's decision making though.

IIRC, it was on the order of $100k+ per cluster for the Premium offering. Has been several months so I would suggest contacting them to see what it currently is.

For some projects I've been on, that wouldn't be a big deal. For smaller projects it can easily be several times your opex though.

You can run an open source cluster in HA without it though. The big draw for Enterprise is the multi-cluster and HSM support. Anything HSM is typically quite expensive so their pricing really isn't out of line.

Maybe that was poor wording on my part, but ease of use in combination with the features are important.

Take the database secret backend for example. Getting that same feature out of other simple systems, would be a lot of work. Audit trails are another low effort high reward feature. When you start to get into combining those features, it is an even greater pay off. When you start to take into consideration HA clusters...well if you want to put that together on your own have at it.

Much of "easiest" has to do with familiarity as well. I've seen new users get Vault up in minutes that still don't have GPG setup "cause it is hard". If you are already working with DynamoDB or Consul, you already know how to setup the storage. Those are common skills. I'm sure there are folks that fall on the other side of that use GPG often, but it doesn't make either side more objectively easy.

If you only have the need for a simple system, then Vault may be overkill. I would say Vault is comparable to Kubernetes. Does everyone need it: No. Simpler stuff can be done with config management or tools like Nomad. Does it have features that most people will eventually want to use: Absolutely.

Secret management is one of those things were simple solutions end up easily becoming more and more involved just like container orchestration. Especially when you get into chicken/egg scenarios regarding stuff like some of the tools you mentioned.

Side note: I've tried at least 12 other tools for this purpose , and I would recommend Vault over all of them for most every scenario that is more involved then "Use 1Password".

Yes. I use Terraform to pull secrets from Vault and insert them into Kubernetes secrets so that there is a single source of truth.

You can use json as well, but it is pretty unfriendly for the human users and you lose some of the interpolation.

Can't recommend Vault enough. By far the easiest and most capable solution to work with. The only downside I can point out is that the multi-cluster/region HA requires expensive enterprise licensing, but that is something most user cases don't require.

The Hashicorp stack is pretty widely used in part for its open source cross-platform capabilities. This seems more along the lines of "Hey! You already use Terraform/Vault for provider X. Now GCP works even better with the tools you already use!"

You concern is probably worthwhile, but I think this is not an example of it.

Curious if any provider has given you similar contract terms?

According to the interview with the author linked in comments above, he published it internally a month ago. The fact that it only got linked and went viral weeks later would indicate it was originally limited.

Yes, it appears to affirm that law enforcement is not the best bang for the buck. There has been plenty of work indicating that like you mentioned. That wasn't a "bold risk".

That is separate from saying that changing the legality of it impacts the usage though. There is not reason to take the result beyond what it indicates.

Find it misleading that almost all of the recent articles on this subject talk about decriminalization as the cause for the drop in drug related health issues.

They shifted a significant chunk of money to health services. If it proves anything, it is only that health services can reduce drug related health issues. Without a control, there is nothing to point to regarding criminalization vs decriminalization. People are now paid to go out to drug dens and offer medical help. You can't simply say "people were scared to get help before" when instead you start sending help straight to their location.

Even when an article mentions the change in spending/focus, it is framed in the context of legalizing drugs. No one is making articles titled "After years of improving health services, Portugal's drug policy paid off".

I get that some folks want to legalize drugs, but make an argument for it that doesn't involve this twisting of results to match the desired outcome.

I think the DevOps is a culture statement is just as misleading to folks as the DevOps is automation/tooling.

If you look at the early conversations, it was a discussion that outlined a management paradigm that borrowed heavily from Theory of Constraints in the manufacturing world. The discussion lead to a consensus among those involved that defined core values of culture, automation, measuring, and sharing (CAMS).

To many people, DevOps means that paradigm. The examples you list (security, marketing, etc) are not paradigms composed of several values. They are business functions as infrastructure automation might be. We don't call the accounting team the "cash-flow" team cause it is a paradigm. Not a function.

While I don't think it is worth falling on your sword over, the fact that folks care about the wording is good. It means they are thinking about more then just the function, but also the underlying paradigms.

Would argue that you have a tools/service team. The fact that you failed to mention changing what devs and sysadmins consider when "focusing 100%" on their role indicates that what you are talking about isn't the concept of DevOps in the article.

Saying you have a DevOps team is like saying you have Lean team, a Theory of Constraints team, or a Just-in-time manufacturing team. DevOps doesn't say that devs shouldn't write code any more then Theory of Constraints says a guy that paints car hoods should be building brake pads. It is about the fact that they should work together to ensure the organization as a whole meets the goals. Not as isolated units that only prioritize their own goals.

I've seen the same flak about Agile and scrum roles for the same reason. People think they can buy the DevOps/Agile/whatever. Only difference with DevOps is rest is that it is getting more noise.

Thanks. Apparently I completely missed that in the FAQ.

So is a "compute unit" the same as the "Azure Compute Units" that are used to measure VMs? 800 ACU roughly comes out to 4 cores. At $0.78/hr, that is hardly comparable to the RDS offerings. Didn't see an indication of memory.

Much like SQL Server DTUs and DWUs, the spacebucks measurements only seem to useful for hiding the actual price comparisons.

At least they stopped the DTU/DWU non-sense for these services.

Ask not what your country can do for you. Ask what your country can do for them.

Why worry about precedence? When I'm in power I'll just change the rules!

This is a common mistake when reading about military history. Casualties are not deaths. It is the lose of fighters for a wide range of reasons (death, injury, illness, catpure, and etc).

Roughly 650k people were killed during the American Civil War, but the casualties were closer to 1.8mil.

Much of the casualty count of the Franco-Prussian War is related to the fact that France lost entire forces in engagements. Mass routes nearly always lead to inflated injury and captured counts which in turn leads to high casualties.

By comparison, few of the engagements were as one-sided in the American Civil War. The combat death rates were actually fairly close to each other over time (~160k/yr).

Would add that MS is the new IBM when it comes to the old saying "No one ever got fired for buying IBM".

Cost and performance simply don't matter in many folks business decision methods when something is compared to a MS product.

I see. You are just commenting on the mainframe portion of the prior response.

The efforts to revamp .Net CLR to run on non-Windows systems is of little value to shops that are not already running .Net CLR. At best it is removing a negative for running .Net CLR. There is no net gain for a Rails or JVM shop for example.

The gain is only for shops that already paying the Windows tax to get .Net.

Curious to hear about these .Net Enterprise devs that are not using RDBMS. It is still very much the status quo even with services like Azure DocumentDB around.

When you get a list of solid points about why Java won't be displaced and the response is watch this space, it reminds me of the folks saying "this is the year of the Linux desktop" without pointing to actual improvements coming to life.

The "new" .Net CLR really only has a compelling story if you are already a .Net shop. Nothing in the new Core and Standard implementations gives you something new if you are outside of it.