Readit News logoReadit News
_5yoy commented on Parler drops offline after Amazon pulls support   bbc.co.uk/news/technology... · Posted by u/brobdingnagians
Nuzzerino · 5 years ago
> Businesses that are not terror cells have nothing to worry about.

What is your definition of a terror cell? Do Amazon, Microsoft, and Google qualify as terror cells for competing for billion dollar contracts with the DoD? This is an absurd benchmark with no basis in reality.

https://cnbc.com/2019/10/25/microsoft-wins-major-defense-clo...

_5yoy · 5 years ago
It's really not, and has never been. A group of people literally organized on Facebook and brought guns to overtake the capitol. It's pretty cut and dry. Again, nobody would've expected Microsoft to support ISIS' tech. Businesses have always pulled away from extremist groups like this, as is their right to do.

The "whataboutism" on DoD contracts isn't relevant. If your stance is "Our own government is a terror cell", well obviously then our entire society is gone anyway, so why even bother discussing the ethics of tech in america at all? But obviously this stance is just hyperbole in an attempt to dismiss the validity of claiming the rioters as legitimate terrorists.

And even by your own example, when has the DoD ever stormed the capitol? Or attempted to overthrow the US government? Spoiler: they haven't. And these insanely silly attempts at implying that legitimate businesses are under the same category as fascist extremists is a joke. This tech precedent pearl clutching is such an insanely bad look it's difficult to even fathom. My assertion is simple: when you try to overthrow a country's government, companies in that country don't want to work with you. The waters are muddier with respect to overthrowing other people's governments, but the DoD has never once attempted to overthrow the US government. There has never been an AWS-supported US coup (before last week). SO the "whatabouts" aren't even relevant.

bird_monster commented on Parler drops offline after Amazon pulls support   bbc.co.uk/news/technology... · Posted by u/brobdingnagians
zmb_ · 5 years ago
I'm struggling to try to understand what this means for the risks of running a business in the cloud going forward. It was not just AWS dropping them, but many of their other vendors dropped them too, essentially killing their business overnight.

Granted, for this first case the bar was extremely high. You needed literal storming of the Capitol and a platform seemingly specifically targeted at those people for this to happen. However, now that the precedent is set, I would expect the bar to be lowered going forward. That creates risks that need to somehow be mitigated (and reflected in valuations).

Even for businesses that are not in such politically charged areas, I can easily imagine getting inadvertently tangled up in some popular issue and having vendors become targets of online activist (whether it's your own vendors, or whether you are a vendor to a target).

What are the best mitigations here, both technical and social? Vocally side with the popular issues, or try to stay completely out of them, to try to avoid becoming a target (e.g., social media presence)? Try to reduce dependence on cloud providers and vendors by building more in-house? How far would you have to go, since a colo or an ISP can drop you just as AWS can?

bird_monster · 5 years ago
> I'm struggling to try to understand what this means for the risks of running a business in the cloud going forward. It was not just AWS dropping them, but many of their other vendors dropped them too, essentially killing their business overnight.

Businesses that are not terror cells have nothing to worry about. Companies have always pulled away from extremist groups. You wouldn't expect Microsoft to accept a contract with ISIS, would you?

This is really not that complicated. Once you attempt to overthrow a country's government, businesses in that country don't want to work with you. This has always been true.

bird_monster commented on  Haskell is our first choice for building production software systems   foxhound.systems/blog/why... · Posted by u/charukiewicz
avl999 · 5 years ago
> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1!

Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

bird_monster · 5 years ago
> Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

You cannot get mad at errors you don't know about.

Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
Silhouette · 5 years ago
The thing is, I don't think the complexity is even close to the same in the two cases.

AWS and similar services are an abstraction over hardware, software and networking all at once. There are well over 100 different services available on AWS alone. Just to get a basic configuration up and running, someone new to the system has to figure out which of those services they actually need, which is a barrier in itself given the obfuscated names they have.

Then you have much the same network and security details to set up as you would have for on-prem or colo infrastructure, but now with lots of non-standard terminology and proprietary UIs, which are so cumbersome at times that an entire generation of overcomplicated "orchestration" tools has been developed, each of which typically adds yet another layer of leaky abstraction.

Hopefully some time before this all happened you tried to work out what it was going to cost, and maybe you were close or maybe you are in for a nasty surprise because those handy managed services cost several times what the equivalent server + software would have cost either running on real servers or just on cloud VMs.

And if you fall back to that latter case as your safe default, you still get all the same issues to deal with as you would have had on your own servers and network, except that now you need to figure out what is really going on behind all those virtualised systems and quasi-geographical organisation layers before you can tell whether one unfortunate event could take down all the instances of any vital services you need.

In comparison, literally every small business I have ever worked in as a tech worker has had several people at the office who were perfectly capable of buying a switch or firewall or router and spending the few minutes required to configure it or buying a server and installing Linux/Windows and then whatever server software it needed again very quickly. Cloud systems can make it faster to deploy new hardware and connectivity, because you save the time required for all the physical steps, but after that the time and knowledge required to get a small network's worth of equipment up and running really isn't that great. After all, we used to do that all the time until the cloud hype to hold, and it's not as if that has suddenly stopped working or all the people with that knowledge suddenly left the industry in the past 5 years.

bird_monster · 5 years ago
> The thing is, I don't think the complexity is even close to the same in the two cases.

Agreed (but probably on the opposite end as you)

It seems a lot like you've been scorned in the past and that's driving a lot of your statements now (which is totally fine and fair). I'm trying to bring up that, for every problem you've just defined, the literal exact same problem exists for colo/managed servers, except it is now also your problem to keep the lights on and the machine running.

> literally every small business I have ever worked in as a tech worker has had several people at the office who were perfectly capable of buying a switch or firewall or router and spending the few minutes required to configure it or buying a server and installing Linux/Windows and then whatever server software it needed again very quickly.

I'm sorry, if you believe that building and deploying production-ready server infrastructure is as easy as "Just going out and buying a switch and spending a few MINUTES installing linux" (emphasis mine) - I feel like we aren't talking about the same thing at all. Not even close.

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
Silhouette · 5 years ago
All I can say is that this hasn't been my experience. Setting up a single server is much the same whether it's on-prem or at a colo facility or some VM in the cloud, but the amount of added complexity to set up non-trivial networking and security and redundancy/failover and backups and all that stuff in the cloud is far more complicated -- if you don't already know how to do it -- than just setting up a few servers directly. The only exceptions IME tend to be the most basic and essential services, like effectively infinitely scalable storage and managed databases. Not coincidentally, I suspect, these are the kinds of cloud services that almost everyone uses, and often (as this very HN discussion demonstrates) the only ones.

There is still considerable value in the on-demand nature of cloud hardware, instead of waiting for stuff like physically assembling new servers and then shipping them and then installing them in the rack all before you can even start setting up the software, but IME the simplicity emperor has no clothes. Just look at the number of anecdotes about even quite large and well-established businesses that have had systems go down because they didn't fully understand AZs and failover arrangements, or have been landed with some crazy high bill because they didn't fully understand all the different things they were going to be charged for, or have been breached because they left some S3 bucket open.

bird_monster · 5 years ago
> but the amount of added complexity to set up non-trivial networking and security and redundancy/failover and backups and all that stuff in the cloud is far more complicated

This complexity exists either way, is my point. Whether you're managing your own servers, or using barebones cloud VMs, or using a bunch of cloud fanciness, the complexity you just defined still exists. And if that complexity is a constant, why is it only being used as a negative against cloud services?

> Just look at the number of anecdotes about even quite large and well-established businesses that have had systems go down because they didn't fully understand AZs and failover arrangements, or have been landed with some crazy high bill because they didn't fully understand all the different things they were going to be charged for, or have been breached because they left some S3 bucket open.

If your argument is "It's not better when done badly", definitely, I agree, because what is?

I guess, my overall point is that cloud-based infrastructure shifts your focus. Yes, you have to know how to configure cloud resources, but in 2021, do you think it's easier to find people with AWS experience, or people with custom in-house or colo server management experience?

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
tpxl · 5 years ago
We used to have on-prem redis and a devops engineer to manage it, then we moved to redis in the cloud and had a devops engineer to manage it.

Saying that in the cloud you don't need engineers to manage "operational support" is the biggest lie the cloud managed to sell.

bird_monster · 5 years ago
You've just wrapped a very specific definition of "Operational support" into a very vague term.

From another post in this thread: If you want to deploy distributed stream processing like Apache Kafka, but do not want to roll it yourself, you can use a tool like AWS Kinesis or Azure Event Hubs.

You still need "Operational Support" to manage EH/Kinesis, but generally it's closer to the type of "Operational Support" that can be provided by a general backend software engineer, as opposed to a DevOps/Infrastructure-specific dev. By using a Cloud (Managed) service, you're removing the need to manage:

* Uptime management * Scaling * Custom-multi-AZ

And probably a lot more. Sure, you've still have to actually handle events appropriately, but you have to do that either way.

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
Silhouette · 5 years ago
Especially if you're a small company, engineering time (really any employee time) is _insanely valuable_.

This is true, but it is balanced by the fact that uncertainty can be insanely expensive. And diving into complicated cloud infrastructure with a small business, if you're not already an expert on it, is a very uncertain endeavour in terms of whether you'll get everything set up right (and not find out otherwise at 3am when it turns out your redundancy wasn't, for example) and what everything will cost. By the time you have either become an expert yourself or hired someone who already is, your costs have already increased significantly too, for exactly the reason you've just stated yourself.

bird_monster · 5 years ago
> And diving into complicated cloud infrastructure with a small business, if you're not already an expert on it, is a very uncertain endeavour in terms of whether you'll get everything set up right

I do not agree. The entire point of using cloud offerings as opposed to rolling your own, is cloud offerings are usually several orders of magnitude easier to configure. Using Event Hub, as an example, means that you're getting a similar experience to Apache Kafka, but without having to scale/configure everything yourself.

Sure, you have to become proficient with Event Hub, but becoming proficient with EH is probably 1/100th of the difficulty as becoming proficient enough in Kafka to support the same scalability/workload.

bird_monster commented on Vuejs rejects close to 75% of outside contributions   merge-chance.info/target?... · Posted by u/gieksosz
that_guy_iain · 5 years ago
The org has 49 people on it. And every project that has one people who leads it can surive without that person, it's called they fork the project.
bird_monster · 5 years ago
https://github.com/vuejs/vue/graphs/contributors?from=2016-0...

Here you can find the code additions Github Insight.

The org can have 49 people in it, but 48 of them are not writing code for Vue.js.

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
glogla · 5 years ago
For example:

Managed Airflow Scheduler on AWS with "large" size costs $0.99/hour, or $8,672/year per instance. That's ~ $17,500 considering Airflow for at least non-prod and prod instances.

Building it on your own on same size EC2 instance would cost $3,363/year for the EC2. Times two for two environments, let's say $6,700. $4,000 if you prepay the instance.

That looks way cheaper, but then you have to do the engineering and the operational support yourself.

If you consider just the engineering and assume engineer costs $50/hour and estimate this to initial three weeks of work and then 2.5 days / month for support (upgrades, tuning, ...) that's extra $4,000 upfront and $1,000/month.

So on AWS you're at $17,500/year and on-prem you're at best $20,000 first year and $16,000 next years.

So the AWS only comes a bit more expensive - but the math is tricky on several parts:

- maybe you need 4 environments deployed instead of 2, which is more for AWS but not much more for engineering?

- maybe there's less sustaining cost because you're ok with upgrading Airflow only once a quarter?

- you probably already pay the engineers, so it's not an extra money cost, it's extra cost of them not working on other stuff - different boxes and budgets

- maybe you're in part of a world where good devops engineer doesn't cost $50/hour but $15 hour

- I'm ignoring cost of operational support, which can be a lot for on-prem if you need 24/7

- maybe you need 12+ Airflow instances thanks to your fragmented / federated IT and can share the engineering cost

- etc, etc.

So I think what OP was saying is that if AWS priced Managed Airflow at $0.5 per hour, it would be no brainer to use instead of build your own. The way it is, some customers will surely for their own Airflow instead, because the math favors it.

Does that make sense?

bird_monster · 5 years ago
> That looks way cheaper, but then you have to do the engineering and the operational support yourself.

In my experience, this is the piece that engineers rarely realize and that is actually one of the biggest factors in evaluating cloud providers vs. home-rolled. Especially if you're a small company, engineering time (really any employee time) is _insanely valuable_. Valuable such that even if Airflow is cash-expensive, if using it allows your engineers to focus on building whatever makes _your business successful_, it is usually a much better idea to just use Airflow and keep moving. Clients usually will not care about whether you implemented your own version of an AWS product (unless that's your company's specific business). Clients will care about the features you ship. If you spent a ton of time re-inventing Airflow to save some cost, but then go bankrupt before you ever ship, rolling your own Airflow implementation clearly didn't save you anything.

bird_monster commented on The many lies about reducing complexity part 2: Cloud   ea.rna.nl/2021/01/10/the-... · Posted by u/rapnie
bane · 5 years ago
I've worked with a number of teams over the last few years who use AWS and I'd say from top to bottom they all build their strategy more or less the same way:

0. Whatever is the minimum needed to get a VPC stood up.

1. EC2 as 90%+ of whatever they're doing

2. S3 for storing lots of stuff and/or crossing VPC boundaries for data ingress/egress (like seriously, S3 seems to be used more as an alternative to SFTP than for anything else). This makes up usually the rest of the thinking.

3. Maybe one other technology that's usually from the set of {Lambda, Batch, Redshift, SQS} but rarely any combination of two or more of those.

And that's it. I know there are teams that go all in. But for the dozen or teams I've personally interacted with this is it. The rest of the stack is usually something stuffed into an EC2 instance instead of using an AWS version and it comes down to one thing: the difficulties in estimating pricing for those pieces. EC2 instances are drop-dead simple to price estimate forward 6 months, 12 months or longer.

Amazon is probably leaving billions on the table every year because nobody can figure out how to price things so their department can make their yearly budget requests. The one time somebody tries to use some managed service that goes overbudget by 3000%, and the after action figures out that it would have been within the budget by using <open source technology> in EC2, they just do that instead -- even though it increases the staff cost and maintenance complexity.

In fact just this past week a team was looking at using SageMaker in an effort to go all "cloud native", took one look at the pricing sheet and noped right back to Jupyter and scikit_learn in a few EC2 instances.

An entire different group I'm working with is evaluating cloud management tools and most of them just simplify provisioning EC2 instances and tracking instance costs. They really don't do much for tracking costs from almost any of the other services.

bird_monster · 5 years ago
+1, but with a container tool (Fargate/ECS, Azure Container Instances) instead of EC2.

u/_5yoy

KarmaCake day239September 15, 2020View Original