> 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.
> 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.
- Identify and document possible solutions. Think hard about why each solution is good and each decision is bad.
- Within each solution, attempt to find common patterns in that problemspace (when working with Sharded databases, this approach brings these results, etc)
- Try to match your personal and organization requirements against the various patterns you find and the pros/cons you defined previously
During implementation
- Keep a running list of things that seem weird, or things that seem great, or things that turned out to be untrue
- Don't stop implementing, but for each thing you found that wasn't great in step 1, try to find a better way to approach that thing (while moving forward)
Post implementation
- Compile all the notes you made in pre/during into a manageable list of goods/bads.
- Use this to drive A.) iterations of your solution, and B.) future solutions
If you do this enough times, you'll have a pretty decent list of your experiences in a space, and you'll start to notice patterns as you try different things and become exposed to problems, their solutions and their tradeoffs. Eventually you won't even have to look at your previous notes very often, as you'll have built up a pretty decent amount of experience in various problemspaces such that you can predict what goes well/doesn't go well.
Also worth noting, this type of behavior doesn't really have to be applied to software, but will also gain you big points with future employers when interviewing. You'd be surprised to find how many candidates never stopped to reflect on the work they'd done, why it was sub-optimal, or how it could be corrected moving forward. Response like "We did it ____ way because that's how we always did it." Which, from a progress standpoint, is basically a none-answer.
Note: this is obviously just my opinion, and I'm no expert in "Becoming a Master of Stuff", but these are the methods that I have used and seen my peers use (in one form or another) over quite a long time. Sometimes not as obvious (doing these things in your head vs. writing them down), but the shape is always pretty similar. Ultimately I think being reflective is one of the best skills a person can possess (with respect to employment and I guess also relationships). Acting without thinking is reckless, I think.
It kinda depends on your goals I think. The T shaped developer skillset is extremely, extremely valuable and will only probably continue. Sure, you could get deeper in a language you already have experience with, but do you think that will better prepare you for future experiences in different languages? Do you want to stick with the tech you're currently using for the rest of your career? If you do, that's great! Don't even worry about the other stuff. But I can say, any time I've spent in my career learning something new has never been wasted time, even if I never used the tool again.
Sometimes it's also fun to just see something different. There is value in "Play". You might find you actually really love the new thing, or you might find the new thing just totally reaffirmed your love for your current tools. Either is great! But finding out is probably more valuable.
For what it's worth, to your question directly, I found using Prolog to be a pretty profound experience with respect to how I thought about programming. I haven't touched it in ~12 years, but while I was using it I thought it was incredible. One of the "funnest" learning experiences of my career was building sudoku solvers in Prolog.
It sounds like you've made up your mind, but I might suggest reading less overwhelmingly biased critiques. That post makes incorrect assumptions about go, and then exhibits the result of their incorrect assumptions, and then brings up how, when making the correct assumptions in Rust, the outcome is different. Can you see how this is a flawed strategy?
Go isn't for everyone, and that's okay, but it seems kind of silly to make a judgement based off of a negative review hinging on a pretty poor understanding of a language.
> An internal team change is often a lot less stressful and less risky than going to a different company.
This statement really nails it. If you change teams and are still unhappy you can always quit. If you quit without having changed teams and then hate your new job, you might not be able to go back to your previous company (but new team). I think it's general good practice to give another team a change before you leave the company if you're on the fence. If you know it's a company problem, bail, but if you think it could just be your team, give it a shot.
Maybe it's just me, but I like to minimize the amount of decisions I make that I cannot undo.
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.