TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Principles for Building New SaaS Products on AWS

212 点作者 jackgill大约 5 年前

13 条评论

ComodoHacker大约 5 年前
This sounds like an excellent guide to a perfect vendor lock-in. It&#x27;s just missing the final principle:<p>#4 Operate as if you may be bought or cloned by Amazon at any time.
评论 #23085845 未加载
评论 #23086121 未加载
评论 #23087261 未加载
评论 #23086741 未加载
taylorwc大约 5 年前
I found myself nodding agreement until I reached the Cloud9 part... I think I can count on one hand the number of professional devs I know that use Cloud9 as their primary editor&#x2F;IDE. Curious if I&#x27;m in a bubble on that front?
评论 #23086163 未加载
评论 #23085337 未加载
评论 #23085677 未加载
评论 #23087506 未加载
评论 #23085280 未加载
评论 #23085263 未加载
评论 #23085711 未加载
评论 #23085941 未加载
评论 #23086060 未加载
评论 #23087935 未加载
wiradikusuma大约 5 年前
&quot;I&#x27;d ask most developers to start their day in Cloud9&quot; -- hmm, no. Most developers I know have powerful computers (many of them are gamers), so it&#x27;s wasteful not to maximize the ROI.<p>Also, not everyone has fast&#x2F;reliable internet all the time :)
评论 #23086195 未加载
jcims大约 5 年前
These get a little boutique, but if you want to attract and close large enterprise&#x2F;regulated customers, I&#x27;d extend a few of yours:<p>- Build your application to suit many customers or one. Large customers love to have their instance run in a dedicated account.<p>- Open source your operations. Large customers love to see logs&#x2F;operational activity from their environments (e.g. cc: cloudtrail&#x2F;config&#x2F;cloudwatch logs to customer, this assumes dedicated account)<p>- Open source your security. Be prepared to ship guardduty, config rules, etc to your customer (this assumes dedicated account).<p>Also, since we&#x27;re focusing on AWS here<p>- Build your application to support hybrid cloud customers. Expose it through private link, VPC connections, transit gw, firehose, api gateways, VPC lambdas, whatever is appropriate for your architecture.<p>- Leverage IAM as much as possible for authentication&#x2F;authorization. Not AWS-specific but implement SSO and assume customers will require numerous instances of your service when developing your user account model.<p>- Leverage KMS as much as possible to protect data at rest, and support customer CMKs.<p>There are more but I&#x27;ll stop here.
indymike大约 5 年前
Some really good advice here. Especially the &quot;build as if you are going to sell at any moment&quot; and &quot;build as if you are going to open source at any moment&quot;.
peterwwillis大约 5 年前
Immutable Infrastructure is more important than Infrastructure as Code, fwiw.<p>The latter just means &quot;it&#x27;s in [version controlled] code&quot;. This has a variety of use cases, and it might mean you end up in a quagmire of complexity. It&#x27;s become a cargo cult thing where I&#x27;ve seen people adopt horribly complex, fragile solutions over practical ones &quot;because IaC&quot;.<p>The former is a principle that basically has no downside, and only improves operational integrity. Even if you&#x27;re literally deploying everything by clicking in the Console, it&#x27;s still massively more reliable, repeatable, and recoverable as immutable artifacts.<p>The next thing I&#x27;d recommend before investing heavily in IaC is auto-recovery. The most obvious example is Autoscaling Groups, but any health check combined with an automatic action such as restart or re-deploy can work. This works best with Immutable Infrastructure, and typically does not require IaC.
jackgill大约 5 年前
I&#x27;m interested in hearing opinions about this principle in the context of data engineering:<p>&gt; This also means leaning heavily into all the service offerings and orchestration tooling that is afforded to you by your platform.<p>I&#x27;ve built a data lake and several ETL pipelines using AWS native services (Kinesis, Lambda, Athena). It works but it&#x27;s a bit...fiddly. I spend a lot of time configuring these services and handling various failure modes. I&#x27;ve been wondering if I should be looking at third party vendors like Fivetran or Matillion for ETL.<p>Does anyone who&#x27;s worked with AWS data engineering services have thoughts on the trade-off between AWS native services and third party vendors in this area?
评论 #23085558 未加载
评论 #23086714 未加载
the_resistence大约 5 年前
Thanks for this perspective. It really helps the noobs trying to build more than single user stuff.
gfodor大约 5 年前
What’s the right granularity to shard aws accounts? I haven’t gone down this road. Is it madness to consider this as a multi tenant mechanism vs the usual foreign keys in the database approach? Is applying cloudformation across thousands of accounts feasible?
评论 #23086447 未加载
评论 #23086046 未加载
评论 #23087807 未加载
评论 #23087419 未加载
ignoramous大约 5 年前
&gt; <i>For instance, AWS doesn&#x27;t have anything quite as tuned to fast frontend search experiences like Algolia.</i><p><a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;kendra&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;kendra&#x2F;</a> ?
评论 #23086418 未加载
eugenekolo大约 5 年前
Not sure how much I can trust &quot;AWS Gurus&quot; about actually building SaaS products in a real world at a real company.<p>It&#x27;s all good advice, but please provide me with the money, and resources necessary to do it all.
simonebrunozzi大约 5 年前
What a lame article. I don&#x27;t find any utility in any of the principles expressed here. Also, in my experience (at AWS 2008-2014, before&#x2F;after in the same industry), I can&#x27;t recall instances of companies that either mentioned, or followed, these principles.<p>Specific critiques:<p>&gt; #1 Build as if you may sell at any time<p>&gt; ... it forces you to build with best practices and isolation.<p>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.<p>Side note: &quot;AWS Organizations&quot; 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.<p>Try to understand the AWS bill of a sufficiently large company - you won&#x27;t. The AWS rep won&#x27;t. The AWS Solutions Architect won&#x27;t.<p>Also, never heard of a company being acquired at a higher price because they had a &quot;proper&quot; AWS setup.<p>Ah, forgot this: if your acquirer is using MS Azure, good luck telling them that you are using Cloud9 or other AWS-specific stuff.<p>Let&#x27;s continue...<p>&gt; #2 Build as if you may open-source at any time<p>Yes. In an ideal world. In practice, almost nobody follows best practices. Because there&#x27;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 &quot;migrate&quot; or &quot;evolve&quot; or &quot;adapt&quot; or whatever buzzword they use.<p>&gt; #3 Build with a cloud-native mindset<p>&gt; ... going outside of the platform should be an exception and something you do only when truly needed<p>&gt; My thinking on serverless these days in order of consideration. &gt; - If the platform has it, use it &gt; - If the market has it, buy it<p>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&#x27;t seen a large company doing A LOT of development on Lambda. Most project using Lambda are small, confined, isolated projects and&#x2F;or teams.<p>Cloud native is great, WHEN it makes sense. I don&#x27;t like religion too much, and I don&#x27;t like religious people either; the author seem to have taken his faith in AWS too seriously.
评论 #23099202 未加载
Mizza大约 5 年前
This is blogspam.
评论 #23085906 未加载