Could you elaborate a bit? Do you think it's because of copyright issues, or because labels don't want Spotify to become a popular distributor that publishes exclusively to itself?
I doubt copyright issues had an impact here. There is always a much larger perspective the labels have over the industry than what we can talk about here.
Ultimately, it is about control. Every decision from the ads you hear to the choice of music you get in your Discover Weekly playlists (or any made by Spotify) come from the influence of label control over the company (and industry). Songs that appear or can be heard near or in sequence of each other to an end user are not really that random.
We as consumers forget that the entirety of Spotify is a heavily curated experience. This includes the features available to us on various devices which directly impact how and what (pod casts) we can listen to and when (free tier on mobile)
I've always thought Spotify could be the Steam of music: To bring artists and listeners together, but I now believe Bandcamps done more in that regard and Spotify might end up being a data harvesting tool for the labels.
I think the people from serverless (and apex) are doing an amazing job evangelizing about the benefits of server-less infrastructures and they have amazing projects they should be quite proud of.
Than been said, I think both projects walk different paths in order to achieve similar goals.
What is different with other approaches?
* Isolation is one of the most important things for us. Each of the stages of your application are deployed into independent Cloudformation stacks.
* We don't stream commands to the AWS api. Every single of your resources are created using CF.
* We respect the tooling of each of the runtimes so javascript, java or python developers should not get exposed to software they are not use to.
* Convention over configuration. Perhaps this is because my background is the Python/Django ecosystem, but writing 200 lines configuration files in JSON feels completely wrong to me.
* Documentation documentation documentation: Again, perhaps I've been badly educated by the Django community, but documentation and examples are (for me) the most important thing a project like this should have. That's why gordon's documentation is quite complete (I would say) and we have more than 20 example project including integrations with Slack, Telegram, Twilio... and AWS services such as Kinesis, Dynamodb, Apigateway, S3, Cloudwatch Events, Cloudwatch Scheduled Events, etc...
I think is an amazing moment to be involved in the server-less community and we'll all benefit from a thriving ecosystem like this :D
Great work on this. We're actually moving in a similar direction at Serverless with full Cloudformation support in our current development branch for all the reasons you listed. Would love to chat sometime, email is in my account page.
FWIW, I've been using serverless the last couple of weeks and I find the request-response parameter mapping absolutely maddening.
Most of us have become used to frameworks like express for specifying our routes and manually specifying API gateway rules feels like a huge step backwards.
Messing with Gordon now, but I've messed with nearly every other serverless framework. If you're looking for something express-y then you might like claudia.js's ApiBuilder, but the underlying API Gateway is always the lowest common denominator so this just adds some prettiness on top. https://github.com/claudiajs/claudia
