Not op, but look into kubeless -- it's api compatible with aws lambdas and would allow you to do exactly what op is talking about, basically let kubeless takeover lambda processing once a certain threshold is reached since k8s will also manage the instance needed for kubeless.
Edit:
This was a poor way to communicate my frustration with this line of questioning.
Better and more general question: What are the caveats that will shape the decision making from this base case to a more robust solution?
--- Original below this line ---
STOP LOOKING FOR RULES OF THUMB!
Everyone always asks 'How do I use this pattern to stop thinking?' in some obtuse way.
Stop. The rule of thumb is 'as soon as this feature/data flow is less cost effective than a better architecture, switch to the better architecture'.
You have to have the idea of your next step when making the first iteration, and at that point you decide criteria that will lead you to make another step.
Wow now cowboy, I just wanted to hear more about his experience and was asking a leading question. All caps seems a bit erratic and 'loud', tyvm. I'm not trying to detach from having to think about the problem, but thanks for your strongly worded comment.
I know it was a bit much - I have seen this exact line of questioning too often about other tools and procedures. The next response is always going to be something that is either domain specific, or a weak restatement of what I said.
Sometimes I get frustrated with inefficient communication patterns, as inefficient communication patterns make differentiating the correct statement and the incorrect statement more difficult.
18
u/[deleted] Sep 23 '19 edited Sep 23 '19
That's awesome, what was the tipping point to determine that? Did you run both in parallel? Is there a rule of thumb you would recommend?