3 ms·

I've seen the (broad) architecture of my local government yes (due to keeping tabs on government spending on IT as a personal curiosity). I'm aware of the moras

I've seen the (broad) architecture of my local government yes (due to keeping tabs on government spending on IT as a personal curiosity). I'm aware of the morass you speak off. The reality though is that most tech stacks aren't that complicated. Not every company is a venture capital "go big or go bust, we change the entire industry" darling (nor are they necessarily looking to grow that way, especially outside the SV bubble) or a government with 2000 different contracts and enough yellow tape + bureaucracy around those contracts that signing a new contract is just easier than possibly extending an existing one with new features. For the rest of those tech stacks (which are definitely "enterprise", simply by definition, since they get used in companies and are bespoke enough to be their own tools), it's rare to see a stack more complex than the one I mentioned (backend, cache, db) unless a technical admin decided to play runaway with Azure/Google/Amazon because it's shiny and exciting.

scarface_74 3y ago
When I say “enterprise”, I’m talking about large F500 companies with lots of moving pieces.
- noirscape 3y ago
  Yes, in those cases the tradeoffs of lock-in are worth it. With that in mind though - F500 are the absolute peak of the economic market (since you know, that's how Fortune makes that list). They represent less than 1% of the total market in terms of actual needs. In those cases, the vendor lock-in from using a bespoke AWS or Azure solution are absolutely worth it because if AWS or Azure are an active problem they also will have the manpower to migrate off of AWS/Azure. My suggestion/advice is for the other 99%. You still want AWS/Azure for CYA, the managed part (not having to deal with ops) and backups but you don't need all the extra solutions they offer. It's why "you are not Google" is an advice that exists. Newbies often tend to assume that because [big company/VC startup] is willing to eat the potential risk of a lock-in gone awry that the [smaller company] they work for/founded is able to eat it as well. There's definitely a usecase for all the specific services that GCP/Azure/AWS offer. Chances are though that you're not working for a company where that's the case and the more conventional tools will do just fine. (VC Startups tend to ignore that advice mostly because they have a lot of financial resources to spend upfront, so they think it's worthwhile/that they will hit that point where GCP/Azure/AWS services become a necessity compared to a traditional tech stack.)
  - scarface_74 3y ago
    What other parts? Are you suggesting they shouldn’t use SQS, SNS, DynamoDB, Lambda, etc? Startups should use whatever technology that gets them to market fastest and the last thing they should be worried about is “lock-in”. If they find product market fit and get customers, in normal times the money will come. Why worry about the “undifferentiated heavy lifting”? Sure for Dropbox or BackBlaze, managing storage is their competitive advantage for instance. But creating a AbstractFactoryRepositoryKeyValueFacade to avoid a DynanoDB dependency makes absolutely no sense.

scarface_74 3y ago

When I say “enterprise”, I’m talking about large F500 companies with lots of moving pieces.

noirscape 3y ago
Yes, in those cases the tradeoffs of lock-in are worth it. With that in mind though - F500 are the absolute peak of the economic market (since you know, that's how Fortune makes that list). They represent less than 1% of the total market in terms of actual needs. In those cases, the vendor lock-in from using a bespoke AWS or Azure solution are absolutely worth it because if AWS or Azure are an active problem they also will have the manpower to migrate off of AWS/Azure. My suggestion/advice is for the other 99%. You still want AWS/Azure for CYA, the managed part (not having to deal with ops) and backups but you don't need all the extra solutions they offer. It's why "you are not Google" is an advice that exists. Newbies often tend to assume that because [big company/VC startup] is willing to eat the potential risk of a lock-in gone awry that the [smaller company] they work for/founded is able to eat it as well. There's definitely a usecase for all the specific services that GCP/Azure/AWS offer. Chances are though that you're not working for a company where that's the case and the more conventional tools will do just fine. (VC Startups tend to ignore that advice mostly because they have a lot of financial resources to spend upfront, so they think it's worthwhile/that they will hit that point where GCP/Azure/AWS services become a necessity compared to a traditional tech stack.)
- scarface_74 3y ago
  What other parts? Are you suggesting they shouldn’t use SQS, SNS, DynamoDB, Lambda, etc? Startups should use whatever technology that gets them to market fastest and the last thing they should be worried about is “lock-in”. If they find product market fit and get customers, in normal times the money will come. Why worry about the “undifferentiated heavy lifting”? Sure for Dropbox or BackBlaze, managing storage is their competitive advantage for instance. But creating a AbstractFactoryRepositoryKeyValueFacade to avoid a DynanoDB dependency makes absolutely no sense.