What a lame article. I don't find any utility in any of the principles expressed here. Also, in my experience (at AWS 2008-2014, before/after in the same industry), I can't recall instances of companies that either mentioned, or followed, these principles.
Specific critiques:
> #1 Build as if you may sell at any time
> ... it forces you to build with best practices and isolation.
The opposite. It gives you an incentive to postpone technical debt, you want to grow and be acquired at the expense of whoever is going to integrate your startup into $bigco later.
Side note: "AWS Organizations" to me is simply a way for AWS to try to cover for the poor design choices of the organizational structure of an AWS account, and the unnecessary complications related to billing and metering.
Try to understand the AWS bill of a sufficiently large company - you won't. The AWS rep won't. The AWS Solutions Architect won't.
Also, never heard of a company being acquired at a higher price because they had a "proper" AWS setup.
Ah, forgot this: if your acquirer is using MS Azure, good luck telling them that you are using Cloud9 or other AWS-specific stuff.
Let's continue...
> #2 Build as if you may open-source at any time
Yes. In an ideal world. In practice, almost nobody follows best practices. Because there's always some urgency that takes precedence. This is why companies like Accenture, PwC, Deloitte, etc, keep billing monstrous amount of money to help large companies "migrate" or "evolve" or "adapt" or whatever buzzword they use.
> #3 Build with a cloud-native mindset
> ... going outside of the platform should be an exception and something you do only when truly needed
> My thinking on serverless these days in order of consideration.
> - If the platform has it, use it
> - If the market has it, buy it
Serverless, really? A promising, cutting-edge technology, sure. You want to bet your startup on Lambda? Go ahead. Lambda has been around for ~6 years now (I even tried a super early version internally before it was released), and I still haven't seen a large company doing A LOT of development on Lambda. Most project using Lambda are small, confined, isolated projects and/or teams.
Cloud native is great, WHEN it makes sense. I don't like religion too much, and I don't like religious people either; the author seem to have taken his faith in AWS too seriously.
Specific critiques:
> #1 Build as if you may sell at any time
> ... it forces you to build with best practices and isolation.
The opposite. It gives you an incentive to postpone technical debt, you want to grow and be acquired at the expense of whoever is going to integrate your startup into $bigco later.
Side note: "AWS Organizations" to me is simply a way for AWS to try to cover for the poor design choices of the organizational structure of an AWS account, and the unnecessary complications related to billing and metering.
Try to understand the AWS bill of a sufficiently large company - you won't. The AWS rep won't. The AWS Solutions Architect won't.
Also, never heard of a company being acquired at a higher price because they had a "proper" AWS setup.
Ah, forgot this: if your acquirer is using MS Azure, good luck telling them that you are using Cloud9 or other AWS-specific stuff.
Let's continue...
> #2 Build as if you may open-source at any time
Yes. In an ideal world. In practice, almost nobody follows best practices. Because there's always some urgency that takes precedence. This is why companies like Accenture, PwC, Deloitte, etc, keep billing monstrous amount of money to help large companies "migrate" or "evolve" or "adapt" or whatever buzzword they use.
> #3 Build with a cloud-native mindset
> ... going outside of the platform should be an exception and something you do only when truly needed
> My thinking on serverless these days in order of consideration. > - If the platform has it, use it > - If the market has it, buy it
Serverless, really? A promising, cutting-edge technology, sure. You want to bet your startup on Lambda? Go ahead. Lambda has been around for ~6 years now (I even tried a super early version internally before it was released), and I still haven't seen a large company doing A LOT of development on Lambda. Most project using Lambda are small, confined, isolated projects and/or teams.
Cloud native is great, WHEN it makes sense. I don't like religion too much, and I don't like religious people either; the author seem to have taken his faith in AWS too seriously.