have you thought about abstracting AWS Lambda implementation, so it could potentially support other cloud providers or even be cross-cloud?
Yes, have thought about this. Though trying to avoid absolutisms, maybe one day but don’t think different Cloud Provider support will be part of Jets any time soon. Here are my thoughts:
Different Cloud providers have different features. The clouds rarely work the same. So the abstraction usually ends up resulting to the lowest common denominator interface design. A somewhat crude analogy are iPhone and Andriod app stores when they first came out. An abstracted app interface would have resulted in the lowest common denominator between the 2 of the phone platforms, at least until there is enough parity between the 2 platforms.
Currently, AWS is ahead in breathe and depth. For example, AWS not only has a more mature Lambda offering but they also have API Gateway. Though Google functions look great, they are still in beta. Unsure if something like API Gateway is on the horizon for Google. So the answer is that Jets will be solely focused on only AWS for a while.
More thoughts on Software Philosophy here: BoltOps Tooling and Software Design Philosophy
Making Lots of Pots
Wanted to add another thought that might be valuable here. Been trying to explicitly focus in on concrete implementations and doing abstractions along the way for Jets, instead of the other way around. This might sound counter-intuitive since a great software abstraction can seriously improve the software. However, the Pottery story explains this well:
A pottery teacher split her class into two halves.
To the first half she said, “You will spend the semester studying pottery, planning, designing, and creating your perfect pot. At the end of the semester, there will be a competition to see whose pot is the best”.
To the other half she said, “You will spend your semester making lots of pots. Your grade will be based on the number of completed pots you finish. At the end of the semester, you’ll also have the opportunity to enter your best pot into a competition.”
The first half of the class threw themselves into their research, planning, and design. Then they set about creating their one, perfect pot for the competition.
The second half of the class immediately grabbed fistfuls of clay and started churning out pots. They made big ones, small ones, simple ones, and intricate ones. Their muscles ached for weeks as they gained the strength needed to throw so many pots.
At the end of class, both halves were invited to enter their most perfect pot into the competition. Once the votes were counted, all of the best pots came from the students that were tasked with quantity. The practice they gained made them significantly better potters than the planners on a quest for a single, perfect pot.
The pottery story shows a common issue of engineering: Analysis Paralysis. So right now, making pots with Jets.
Reference: