TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Principles for Building New SaaS Products on AWS

212 pointsby jackgillabout 5 years ago

13 comments

ComodoHackerabout 5 years ago
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 未加载
taylorwcabout 5 years ago
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 未加载
wiradikusumaabout 5 years ago
&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 未加载
jcimsabout 5 years ago
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.
indymikeabout 5 years ago
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;.
peterwwillisabout 5 years ago
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.
jackgillabout 5 years ago
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_resistenceabout 5 years ago
Thanks for this perspective. It really helps the noobs trying to build more than single user stuff.
gfodorabout 5 years ago
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 未加载
ignoramousabout 5 years ago
&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 未加载
eugenekoloabout 5 years ago
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.
simonebrunozziabout 5 years ago
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 未加载
Mizzaabout 5 years ago
This is blogspam.
评论 #23085906 未加载