bird_monster

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.

> 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.

> 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.

> 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.

> 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?

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.

> 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.

> 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.

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

> There is no value to our customers in us stringing together a pile of someone else's products

Maybe not your business, but there are many businesses in which this is exactly what happens. Any managed-service is just combining other people's work into a "product" that gets sold to customers. And that's great! AWS has a staggering amount of products, and lots of business don't even want to have to care about AWS.

> Who out there is using 20+ AWS/Azure/GCP products to back a single business app and is having a fantastic time of it?

Several times. I think cloud products are just tools to get you further along in your business. Most of the tools I use are distributed systems tools, because I don't want to have to own them, and container runtimes/datastores. Every single thing I've ever deployed across AWS/Azure is used as a generic interface that could be replaced relatively easily if necessary, and I've used Terraform to manage my infrastructure creation/deployment process, so that I can swap resources in and out without having to change tech.

If, for some reason, Azure Event Hub stopped providing what we needed it for, we could certainly deploy a customized Kafka implementation and have the rest of our code not really know or care, but from when we set out to build our products, that has always been a "If we need to" problem, and we've never needed to.

> I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts.

Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).

Simple is without a doubt, not even close, the best bank app I have ever used. Simple as a bank is probably one of the worst banks I have ever tried to deal with. I very regularly wish that their app was a layer on top of other bank accounts, such that I could view my Chase account but from the Simple app.

Unfortunately, their banking business (not the app) was their core business, and they were absolutely awful at banking.

Seems like you want vim or emacs?

Why is more tools a problem?

That's fair for you individually. For a lot of people, "I'd rather try to live than die" is a much more realistic viewpoint.