Great writing Jesse! >From my experience in the last year, working on a stream processing (and generally data processing) platform at PayPal, Beam could also offer a great approach for large projects - up until now (and in my case as well), the process was:
1. Research and paper analysis of existing frameworks. 2. Understand your needs. 3. Choose (and commit to) a specific technology - example: Spark. 4. Get to work.. I believe Beam could change this into something better, such as: 1. Understand your needs, and start working on them. 2. Combine your research with actually running (your) same code on different frameworks - probably better then "WordCount" benchmarks. 3. Choose the best framework for you, or choose more than one if the benefit is worth the overhead. 4. While working on 2 & 3, you keep going forward with your project! I talked about Beam in Barclays-Techstars Accelerator in Israel last month because I totally agree that it's a great starting point for startups, but I think this is an example why not just startups :) Thanks, Amit On Wed, Jun 15, 2016 at 9:58 AM Jesse Anderson <je...@smokinghand.com> wrote: > I wrote a piece published on O'Reilly about Beam > > https://www.oreilly.com/ideas/future-proof-and-scale-proof-your-code?utm_medium=social&utm_source=twitter.com&utm_campaign=lgen&utm_content=data+article+ki&cmp=tw-data-na-article-lgen_tw_article > . > It gives some of the thoughts and ideas that will help Beam adoption. I > suggest reading it to get some ideas for how to talk about Beam at talks > and conferences. > > Before writing the piece, I tested how it resonates with people. These > really help people understand why Beam is used and how it solves the future > proofing and scale proofing problems small companies face. > > Thanks, > > Jesse >
