[HN Gopher] Principles for Building New SaaS Products on AWS
___________________________________________________________________
Principles for Building New SaaS Products on AWS
Author : jackgill
Score : 64 points
Date : 2020-05-05 18:39 UTC (4 hours ago)
(HTM) web link (www.trek10.com)
(TXT) w3m dump (www.trek10.com)
| wiradikusuma wrote:
| "I'd ask most developers to start their day in Cloud9" -- hmm,
| no. Most developers I know have powerful computers (many of them
| are gamers), so it's wasteful not to maximize the ROI.
|
| Also, not everyone has fast/reliable internet all the time :)
| jackgill wrote:
| I'm interested in hearing opinions about this principle in the
| context of data engineering:
|
| > This also means leaning heavily into all the service offerings
| and orchestration tooling that is afforded to you by your
| platform.
|
| I've built a data lake and several ETL pipelines using AWS native
| services (Kinesis, Lambda, Athena). It works but it's a
| bit...fiddly. I spend a lot of time configuring these services
| and handling various failure modes. I've been wondering if I
| should be looking at third party vendors like Fivetran or
| Matillion for ETL.
|
| Does anyone who's worked with AWS data engineering services have
| thoughts on the trade-off between AWS native services and third
| party vendors in this area?
| ElFitz wrote:
| Regarding the configuration and failure modes, I think
| something like CDK could be a great way to set all this up in a
| more familiar and readable way
|
| https://aws.amazon.com/cdk/
| taylorwc wrote:
| 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/IDE. Curious if I'm in a bubble on that front?
| indymike wrote:
| You probably aren't in a bubble, but the whole edit through the
| browser, cloud-native editors are really becoming interesting.
| The interesting part is more the integration of dev, testing
| and deployment into the editor in a way you just can't do
| without a lot of devops work with a traditional IDE.
| Icer5k wrote:
| I don't think you're in a bubble, but we've recently started
| evaluating Coder and have found the switch to a cloud-based IDE
| (especially when you add Progressive Web Apps to the mix for
| native keyboard shortcuts) has been extremely attractive. I'm
| finding myself more and more drawn to hosted IDEs where I don't
| need to worry about network performance or how the Docker VM on
| my Mac is eating up my battery life...
| sturgill wrote:
| I don't use it as my primary editor/IDE, but it is convenient
| if I'm on my iPad. Setting up the environment and connecting it
| to your Git repo makes it very easy to debug in a pinch.
|
| I wouldn't be opposed to a cloud-based primary IDE (as long as
| it functioned offline), but I don't think we're there quite
| yet.
|
| So it's not my primary IDE, but it's a solid backup.
| fenwick67 wrote:
| IME Cloud 9 is helpful for building applications where you need
| public endpoints (like if you're using OAuth) or in cases where
| you want a Linux environment but are on windows/OSX/chromeOS.
| But I would pass for everyday use.
| k__ wrote:
| I use it quite often, but as a tech-blogger, I'm an outlier.
|
| I write about AWS products and it's quite nice to get an IDE
| preinstalled with AWS CLI tools with the push of a button.
|
| For JS it's mostly an okay-ish IDE, not as good as VSCode, but
| okay.
|
| For things like Rust or Reason it sucks quite much.
| underbluewaters wrote:
| Yes! Slowing down all software development seems like an
| overreaction to the risk of dev/prod environment differences.
| Good architecture design, modular components, and isolated unit
| tests should really minimize the number of times this will
| become a problem. I can't imagine giving up the productivity
| improvements of insert-fav-ide-here to address unforeseen or
| even hypothetical bugs.
| solidasparagus wrote:
| I used it as my full-time IDE for a while when I only had a
| chromebook. I like what it offers but it just wasn't performant
| and responsive enough to live in it all day IMO.
| ComodoHacker wrote:
| This sounds like an excellent guide to a perfect vendor lock-in.
| It's just missing the final principle:
|
| #4 Operate as if you may be bought or cloned by Amazon at any
| time.
| sl1ck731 wrote:
| Unless your entirely Kubernetes (and even then there are some
| sticky points), using a cloud of any kind already has you
| "locked in" with some of the most basic things like IAM. If you
| are going into a cloud you may as well reap the benefits of the
| premium you're paying.
| mrkurt wrote:
| That's true to varying degrees. Sure you're locked in when
| you use ALB, but it's not too hard to replace that with
| HAProxy. Same with RDS -> Postgres or Fargate to just running
| an app on your own server.
|
| In general, if you build apps with open source runtimes, use
| open source dbs, and avoid the proprietary data services
| cloud providers really stick you to, you can move around
| pretty easily. And you still reap most of the benefits.
|
| The real problem with the special AWS services is you end up
| having to hire AWS ops people or expensive consultants to
| architect around them and run them for you. So it's
| proprietary AND eating up salaries.
| scarface74 wrote:
| What benefit do you get out of going to a cloud provider
| instead of a cheap VPS solution or a colo if you're not
| using any of their managed services?
| mrkurt wrote:
| They have managed services that are relatively easy to
| replace and managed services that are entirely
| proprietary. Many of them map to reasonable OSS tools.
| ALB/RDS/Fargate and even just ec2 + vpcs are super
| powerful, and replacing them is a known quantity.
|
| But stuff like SQS and (to a lesser extent) Lambda is
| really hard to replace because it's thoroughly baked into
| an application architecture.
|
| As an example, we (fly.io) have a tool that'll hoist a
| Fargate app into our infrastructure and let you run it
| all over the world. We even have people tunneling back
| into their VPCs to access other AWS services. But that
| only works because we're both somewhat standard, Fargate
| takes a Docker image and runs it, Fly takes a Docker
| image and runs it, the app inside doesn't care about
| either of us.
| scarface74 wrote:
| So now what happens when you need to migrate a massive
| amount of data while keeping everything online? Let's say
| you want to trigger some code to run when a file gets
| dropped on S3. Are you going to spend Developer time
| trying to come up with a bespoke solution or are you just
| going to trigger a lambda on S3? Are you going to host
| your own highly available queueing and messaging system
| and have to run them on EC2? Sure it's "easy" to replace
| your entire networking infrastructure and run it on
| another provider, but how many man hours is that going to
| take?
|
| Have you actually costed out how much a large migration
| would take?
|
| As far as using Lambda for an API, you can literally add
| three or four lines of code and use "proxy integration"
| to deploy your entire Node/Express, Python/Flask/Django,
| C#/WebAPI app on lambda and without changing any code,
| deploy it anywhere else as you would any other API.
|
| Here is a Node Express example.
|
| https://github.com/awslabs/aws-serverless-express
| scarface74 wrote:
| I wonder has anyone who actually goes through all of the
| lengths trying to "avoid vendor lock-in" actually sat down
| and done a realistic project plan of how much it would cost
| as far as man hours and the amount of regression tests that
| would be required.
|
| Once you have any type of meaningful infrastructure you're
| already not going to migrate without major pain between data
| migrations, networking, security and compliance audits,
| retraining, etc.
|
| And if you are only using one of the major cloud providers as
| a glorified colo, you have the worse of both worlds - you're
| paying more for infrastructure and your TCO is no lower
| because you're still babysitting infrastructure.
| underbluewaters wrote:
| Avoiding lock-in leads to a least-common-denominator approach
| to using the cloud where you will miss out on the advantages of
| managed services. There can be good reasons to buy into a
| particular cloud vendor and there are ways to be modular at the
| software level without wasting cycles making it compatible with
| multiple clouds.
| Mizza wrote:
| This is blogspam.
| unethical_ban wrote:
| It isn't blogspam just because it doesn't interest you.
| indymike wrote:
| Some really good advice here. Especially the "build as if you are
| going to sell at any moment" and "build as if you are going to
| open source at any moment".
| gfodor wrote:
| 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?
| mrkurt wrote:
| I feel like the harder part of that would be migrations on
| databases and application code deploys. CloudFormation to
| configure VPCs would probably work fine.
|
| If you're going to do that, though, you may as well do
| CloudFormation into customer VPCs and let them do all the
| "paying Amazon".
| eugenekolo wrote:
| Not sure how much I can trust "AWS Gurus" about actually building
| SaaS products in a real world at a real company.
|
| It's all good advice, but please provide me with the money, and
| resources necessary to do it all.
___________________________________________________________________
(page generated 2020-05-05 23:00 UTC)