Wow. This was a really great read on many levels. I think the message is fantastic, and you also highlighted a few new tools I haven't had exposure to.
What's your go-to source when you need to compare and contrast different tools that could be suitable for part of your solution? Working at a smaller company, I find that there aren't necessarily colleagues who have enough breadth to be able to jump in and say "Oh, but wait, you DynamoDB won't scale, you should use SQS!" (Borrowing from your example).
And then, to play devil's advocate, what would be your reason for not making this a traditional self-contained service that handles this problem?
Even something VERY classical:
User: unsubscribe me -> Api Gateway -> Service -> RDB
CRON <- RDB: get list of events with an expired timestamp
CRON -> Service: mail these users, unsubscribe these other users
Sure, you're running this service all the time, but it's fairly small and keeps everything logically encapsulated. The RDB isn't fancy and doesn't have built-in TTLs, but since you're dealing with things that are all on the same timespan, a daily cron isn't a big deal. The RDB scales well, and can be sharded trivially, if you really need to.
Is it the costs for when the service is idle that you're trying to avoid? Is it the idea of trying to define what this service's responsibilities are, versus not?
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
thank you for your comment!
i must say that i consume a lot of content, i have some AWS Heroes ( and Community Builders ) that I follow regularly and many others great bloggers that are a great source of inspiration.
I find CDK patterns and serverlessland great resources to getting to know new approaches and services - but already from the names you might realise there is a bit of bias there ;-)
you are perfectly right, and you got the point of this post: there is nothing inherently wrong with a selfcontained service with a cron schedule: everything is there, everybody knows and changes are easy.
Until it has to scale, or the team grows, or you have to add some more functionalities, adding more dependencies from other services or what else, there is absolutely no problem in that approach.
I personally prefer to keep things decoupled, so that they have a very limited responsibility, and thus they remain small, simple and easy to implement, test and change. then once you have all these small components, you can combine them as you like - but that is true, there is a bit of overhead in overall integration and understanding the global picture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow. This was a really great read on many levels. I think the message is fantastic, and you also highlighted a few new tools I haven't had exposure to.
What's your go-to source when you need to compare and contrast different tools that could be suitable for part of your solution? Working at a smaller company, I find that there aren't necessarily colleagues who have enough breadth to be able to jump in and say "Oh, but wait, you DynamoDB won't scale, you should use SQS!" (Borrowing from your example).
And then, to play devil's advocate, what would be your reason for not making this a traditional self-contained service that handles this problem?
Even something VERY classical:
User: unsubscribe me -> Api Gateway -> Service -> RDB
CRON <- RDB: get list of events with an expired timestamp
CRON -> Service: mail these users, unsubscribe these other users
Sure, you're running this service all the time, but it's fairly small and keeps everything logically encapsulated. The RDB isn't fancy and doesn't have built-in TTLs, but since you're dealing with things that are all on the same timespan, a daily cron isn't a big deal. The RDB scales well, and can be sharded trivially, if you really need to.
Is it the costs for when the service is idle that you're trying to avoid? Is it the idea of trying to define what this service's responsibilities are, versus not?
thank you for your comment!
i must say that i consume a lot of content, i have some AWS Heroes ( and Community Builders ) that I follow regularly and many others great bloggers that are a great source of inspiration.
I find CDK patterns and serverlessland great resources to getting to know new approaches and services - but already from the names you might realise there is a bit of bias there ;-)
you are perfectly right, and you got the point of this post: there is nothing inherently wrong with a selfcontained service with a cron schedule: everything is there, everybody knows and changes are easy.
Until it has to scale, or the team grows, or you have to add some more functionalities, adding more dependencies from other services or what else, there is absolutely no problem in that approach.
I personally prefer to keep things decoupled, so that they have a very limited responsibility, and thus they remain small, simple and easy to implement, test and change. then once you have all these small components, you can combine them as you like - but that is true, there is a bit of overhead in overall integration and understanding the global picture.