If you’d ask me today about a future service whose responsibility would have something to do with food shopping, would it run in a Container or a Lambda, I would definitely answer “I don’t know”. I would say that the service may run on one or the other. But the same answer would be for its dependent database. It may run on a Container or directly on a virtual server, or maybe it would be a managed database. I don’t know.
If you’d ask me today, after we’ve done coding our Alexa Skill, would it forever run on Lambda, I would say definitely not. I already know from the product roadmap and the required technical solutions that a known expected future change would require it to be moved into a Container.
If you’d ask me today, after we’ve finished the Food Management Service, would it forever run on Lambda, I would say – I don’t know. It could technically withstand any kind of throughput, but the concurrency is unknown but will only grow larger as we’d sell more devices. There may be a tipping point that would be cost/effective to move it to a Container [see Serverless Development series].
Even if I know something now, it doesn’t mean anything about the future, as requirements change through time. The uncertainty can be so high that is completely unpredictable, or predictable and you’ve got it wrong. You could have gotten it right for year one, but year two was so good for business that the assumptions you made no longer hold. As an architect, I’ve considered to have as many applications as possible coded in the first place to be compute agnostic:
- An application should not be limited to run on any kind of compute
- An application should require a minimal change on compute change
- An application may be agnostic to which compute they run on, depends on how hard it is and the chance of change
- An application should be stateless, but not limited to as some would be beyond our control
- The “system” should be agnostic to which compute an application would run on
The actual applicative implications of compute agnostic had a lot to do with the design of the Event Handler framework and the design of the server-to-server communication, both of which will be later reviewed in future sections.