The first two paragraphs of this post come across as unnecessarily defensive and combative. Amazon released a product and then released an open source preview project to make that product easier to use. They even mention other similar projects (including Zappa) in the project README.
To hint at malice "...it felt like their interface and even their presentation of the product was a direct rip-off of our efforts" and then say "I don't want to attribute any direct malice" seems disingenuous. I feel like those fist two paragraphs could just be cut.
Even AWS themselves have multiple preview projects in the same vein. There is another one just for Node.js that is designed to work with existing apps that were built for the Express framework
https://github.com/awslabs/aws-serverless-express, so less lock-in there I guess?
It fine to promote the benefits of Zappa vs Chalice, including the fact that it avoids lock-in, but honestly the way the author approaches the comparison leaves a bit of a bad taste in my mouth.
I can empathize with the author and am familiar with the history of his project. In my case, I created a Python framework for the Alexa Skills Kit https://github.com/johnwheeler/flask-ask and worked on a blog post with Amazon. My hope was they'd appreciate my energy and passion for the Echo and work with me, but I feel like I've been largely ignored by them aside from being labeled an "Alexa Champion" which is meaningless to me.
As my framework is becoming more popular, I wouldn't be surprised at all if they released a competing framework locked-in to their infrastructure (after seeing how they did Chalice), and it's their prerogative to do that. But as a developer who made a high quality product people want, of course I'd rather they recognized the value I've created and worked with me instead of against.
They have zero obligation to, but if you're going to build on open standards and encourage community involvement, provide incentives for the community's hardwork aside from labels. Definitely don't disincentivize by doing wait-and-copy.
Just want to say, I ran across your framework very quickly after getting an echo dot. I am looking forward to using your much-easier-to-use-and-not-tied-to-aws framework for quick skill development.
Thank you for providing such a useful library! It is better than the amazon version!
I applaud your hard work. It's only natural that we seek reward.
However, from Amazon's point of view, they did not ask you to build it or have obligations to reward you. They did give you a good social credit but it seems you are interested in more that is not entitled to you.
Like you said they have zero obligations and that's where the conversation stops unless you actively ask to be rewarded. Talk to their community make a thread on their forums, make it known and carefully explain your vision and how they are falling short.
They wouldn't just start throwing money at every project that has reached 1000 stars on github.
Open source projects are always about social credits or doing something for the fun of doing it. In rare cases when they aren't it's always responsibility of the author to find funding or come up with a business model.
Adopt my framework and put me on the same playing field as their engineers in terms of information and resources. Flask-Ask is just way better than anything they have for Python. Even their Python related tutorials are terrible. Also, they're so focused on JavaScript they neglect a lot of important languages like Python and Ruby.
I could see them building their own Flask-Ask on top of Chalice, but I think it's counterproductive they push Lambda so hard for Alexa. Cross pollination I guess. Lamdba doesn't support WSGI (which Flask relies on and Lambda doesn't do unless you use Zappa). Personally, I don't think serverless is a panacea. It's good for some use cases, but nothing beats a VPS with a database on it for the wide majority of things including Alexa.
Did you ask them or do you expect Amazon to read your mind?
Where do you get such sense of entitlement? Amazon didn't ask you to write it you volunteer your own time and resources and now you are telling Amazon what they should do.
No, no entitlement here. I hoped things would work out one way, but they worked out another. From looking at your comments, you have a history of putting words in peoples mouths. You're doing the same thing here.
I also am using your framework and I really like it. The quick video and dead-simple implementation made it a no brainer as a weekend project that can actually be published. Thank you.
I don't have any grudges against Amazon for doing this, but it's kind of a shitty feeling to work on something for free for a long time and then see a corporate giant widely publicize an inferior product without even acknowledging your efforts.
Imagine how the guys (I don't remember their name now) who sold hosted MySQL instances on EC2 felt when RDS came out!
That paragraph was just to get that off my chest, I guess. Now that I've written this to clear up the confusion (people were constantly me asking about the differences), I think I can move on.
I get where you are coming from, but things are often less Machiavellian than they seem, even if they feel that way. The Chalice team seems to have their own ideas about how to approach the project, some may overlap with yours and some may differ, from the conversation in the issue you mentioned (https://github.com/awslabs/chalice/issues/27) it seems like they were open to discussing ideas, but they wanted the freedom and control to experiment in their own project.
As with most ideas there is room for different projects and approaches and the landscape is constantly changing so it will be hard to tell which will survive. Even API Gateway's recent addition of the proxy integration feature makes things a lot simpler and probably made some code from all these frameworks less relevant.
So yes the internal AWS "team" has advantages in terms of being able to post to their blog and perhaps being privy to internal developments before you are, but that is just the way it is. Looking at GitHub the team appears to really just be one person https://github.com/awslabs/chalice/graphs/contributors. I just think we should have an open mind and allow for the possibility that they are trying to explore their own ideas and address what they perceive as their customers' needs rather than assume they are trying to crush all similar projects in the name of corporate greed.
You gotta remember they're just a very large corporation who doesn't care about you. It's business for them not personal.
I've partnered with Amazon on development projects before and it was really great for a while and then not great at all when no longer suited their needs.
It's not always fun but comes with the territory when you're a small team or company playing on the same field with giants.
I'm the primary contributor to one of the tools you mentioned (claudiajs), and I fully expect them to at some point offer something that replaces it. the september 20th release of API Gateway was a huge step towards simplifying APIG + Lambda integration, and we were able to drop a huge amount of code from Claudia as a result. The Serverless Application Model released a few days ago takes care of coordinated deployment of API Gateway, Lambda and DynamoDB resources through CloudFormation, which I assume is the most common case for people using the Serverless Framework (another tool you mentioned).
I think this is perfectly normal and expected. When the platform is immature, small teams especially with opensource tools can move faster than the platform and plug holes in it, but then the platform can catch up and offer a systematic solution to a wider number of customers.
For us, Claudia was a way to get our primary app running in Lambda faster and easier. If they replace our needs with a systematic tool, I can spend more time maintaining my primary product and not patching up the platform. Although it's fun to do opensource tools and get some community support and feedback, the money comes from other places.
For people building startups to patch up platforms, the situation is obviously completely different.
The attitude displayed in the opening of the blog post is unproductive. Chalice is deliberately minimalistic, opinionated, and tightly integrated with botocore on Python. It's also licensed under the Apache license. Zappa is a more general purpose framework, fulfilling a more general set of needs. When Lambda-API Gateway first came out, I spent a long time figuring out how to make things work, and I ended up with many of the same patterns that the author accuses Chalice of stealing - before looking at Zappa, and long before Chalice came out. If anything, both Zappa and Chalice are imitating (not "ripping off") Flask.
The rest of the post contains an informative technical comparison, and I appreciate Zappa for pioneering the integration of some very useful features, so it's too bad that the opening really discredits it.
I've had my fair share of PRs ignored by Amazon teams, so I can relate to the feeling that they're not engaged with the community, but it's better to respond with a constructive attitude.
In addition to this comparison, I'd like to add that Rich Jones (@miserlou) is one of the most helpful maintainers I've ever come across on an open source project.
He's available virtually everyday on Slack https://slack.zappa.io/ and has cultivated an impressive community for Zappa.
The biggest advantage that Chalice has over Zappa is related to IAM roles. Chalice has a very cool feature where it will actually inspect your Chalice application for AWS service calls and generate an IAM policy based only upon what the application needs.
I do agree that is a huge win for chalice. I still don't have a clear understanding and rather not fiddle with the IAM stuff if possible.
I just want to go from zero-to-scalable-rest-api with minimal cognitive load from having to switch back and forth different AWS products in the web console.
I am really curious about Serverless. The entire thing feels like J2EE all over again. I am curious to see whether the feature creep will take over in these implementations, so that we end up in the same dead ends we were before. But that's probably just the cycle of our industry. Well, right now it is fun. Lets embrace it.
It doesn't inspire too much confidence when their homepage starts with:
"Never Worry About Web Hosting Again
With Zappa, horizontal scaling is handled automatically."
Granted the auto-discovery of IAM roles selling point Serverless doesn't do. And Serverless is Javascript centric but can still be used with Python and many people do.
We initially wanted to deploy simple scala services to lambda, but the ramp up time is just too slow. This is an issue when you have very few requests (your container is stopped and started) or many requests (more containers have to be started) We now only deploy js and go to lambda and both work great. Curious to to learn how the c# runtime behave in these scenarios.
Seriously, this is not how I want to be building software! I'm completely sold on the value of lambda functions, but it's viciously complex to actually deploy something simple.
Sure, this is why Zappa and Chalice exist... but I feel like AWS could address these needs by making the default lambda deploy process less byzantine.
> Zappa does not lock you in to the AWS ecosystem.
That is a big deal to me. I use AWS but have steered clear of any features that would be difficult to replicate if I moved off aws.
If you make it too hard to migrate to another cloud platform you become completely dependent on Amazon, their pricing, and the choices they make. The advantages would have to be pretty compelling to make that worthwhile. Otherwise, it isn't actually that difficult to set some of this stuff up yourself.
To hint at malice "...it felt like their interface and even their presentation of the product was a direct rip-off of our efforts" and then say "I don't want to attribute any direct malice" seems disingenuous. I feel like those fist two paragraphs could just be cut.
Many people have found the Lambda + API Gateway combo useful, but cumbersome which is why so many different projects have sprouted up to fill that gap e.g. https://github.com/serverless/serverless and https://github.com/claudiajs/claudia
Even AWS themselves have multiple preview projects in the same vein. There is another one just for Node.js that is designed to work with existing apps that were built for the Express framework https://github.com/awslabs/aws-serverless-express, so less lock-in there I guess?
It fine to promote the benefits of Zappa vs Chalice, including the fact that it avoids lock-in, but honestly the way the author approaches the comparison leaves a bit of a bad taste in my mouth.