3 ms·
No idea about payments, as that can heavily depend on locality (Stripe might be an option as they expand to more countries, though). For Authentication, I'd sa
by p_l 5y ago
No idea about payments, as that can heavily depend on locality (Stripe might be an option as they expand to more countries, though).
For Authentication, I'd say go with Keycloak. Yes, it's a reasonably big java program. But it also covers a lot of authentication stuff transparently for you - your application can just use whatever OIDC client library you have, and you can centralize everything in keycloak server, including integrations with external authentication providers (Google, FB, random OIDC, client's internal systems for B2B SaaS, etc.) and you have low chances of waking up and finding out you're going to rebuild your authentication stack because you coded yourself into a corner.
Authorization is a trickier case, but so long as you make it so that you can get "role" or similar attribute out of keycloak into your applications, you can start with hardcoded role names (possibly with extra attribute describing organization etc.) all the way to something complex like Open Policy Agent or even Zanzibar.
I'd probably stick to reasonable written docker containers and vendor-provided SQL database as backing store + graphql interface (I do not use GraphQL myself, but I recall that at least for postgres there appear to be reasonable options?). Use what you know to reduce rewrites.
With docker container, you can go from crappy VPS with docker compose (not recommended, but it does work, it's just crap - been there done that), through ECS (personally I dislike it, but you're already working with it, maybe AWS tax won't hurt you too much?) to kubernetes deployment (most complex to begin with, but scales developer resources well thanks to good abstractions, might be of interest if you find a need for deployment flexibility or find yourself in need of extreme cost efficiencies in hosting). If your code runs well with such setup you can probably also just run on Heroku if the economics fit.
Standardize on observability stack, whether paying for hosted one like honeycomb, to setting up prometheus+loki+grafana.
You're already reasonably successful under my metrics ;) but remember that while setting up some of it might take more time than just hacking it up, handling it well has compounding interest result on later development.
Check carefully what will be your budgetary effect for "buy vs. build", both in terms of coding from scratch vs. deploying existing OSS product, and in terms of hosted vs. self-deployed. I have no idea about your budgets, but I do not joke about AWS tax lightly :)
- Nerks234 5y agoWell we went with AWS for this current project because they offered good/free ‘first year pricing, and now we are being bitten by them a little, our workload is not huge but when you’re bootstrapped these kinds of costs add up, and they’re especially pernicious because it hasn’t made sense financially for us to pay someone to optimize them lower. Hence my concern to make good decisions early on this new project. We use Stripe and it has also served us well so far. The development team is mostly FE focussed and we have limited access to a dedicated DevOps engineer which is why I’m keen to keep that aspect of the stack as ‘standard’ as possible
- p_l 5y agoWell, I'd look into ways to get off the AWS train then. You're already in better starting position given the use of ECS, so you have some preparation for running containers. Since AWS is too expensive, I figure Heroku is right out, and it pushes towards cost optimization a lot. Personally I'd go with some low-cost hosted kubernetes so long as the provider also includes database hosting and integrates logging and such - this means avoiding some of the most complex for starters tasks of handling it - but I also already have k8s experience. Despite what some people say it doesn't have to be complex, but I'd consult with whoever you have available regarding operations - who knows, they might offer some services you didn't know about before. Keeping to something like "twelve factor app" will help to keep your stack simple to deploy no matter which way you go, IMO.