Slashdot Mirror
'Reactive' Development Turns 2.0
electronic convict writes First there was "agile" development. Now there's a new software movement—called 'reactive' development—that sets out principles for building resilient and failure-tolerant applications for cloud, mobile, multicore and Web-scale systems. ReadWrite's Matt Asay sat down with Jonas Bonér, the author of the Reactive Manifesto (just released in version 2.0), for a discussion of what, exactly, the reactive movement aims to fix in software development and how we get there from here.
Organisations working in disparate domains are independently discovering patterns for building software that look the same.[citation needed]
These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.[citation needed]
I don't think it means what you think it means. Obviously the manifesto is so short on details that it can be interpreted in many ways. I think the failure tolerance is more about e.g. tolerance of losing machines or tolerance of overloading - and that seems to be working.
I have previous experience about J2EE/JEE application servers and they always seemed to have the problem that when overloaded with traffic they might do anything. And after being severely overloaded they often do not recover back to normal. Also people often did not use J2EE session replication, because it was considered a pain.
Now I'm building an app with Scala/Play framework and we don't have user sesssions or the web servers so scaling and server failures are not a problem. Also we just ran some performance / load tests and the servers work fine up to 100% load and then just start to lose some requests. This is much preferrable to the "all bets are off" that I have seen on Tomcat or other servlet containers. Another reactive benefit from the Play server is that it is super easy to use many threads for building a single http reply and this really helps in giving users timely replys.
So while the manifesto is of course marketing, there are some good things in the new ways of doing things.
You have some core principles which make sense in a specific context. You have a book based on these principles but with a good dose of word salad to make it look more powerful. You have preachers hammering it into your head. And you have common people getting brainwashed by something that originally was a good idea, but has been perverted into something that hopefully doesn't damage more than it does good.
Oh, and then there's the Enterprise.
...to get certified!
I don't think reactive is the evolution of agile, as the author in the author implies.
If anyone's really looking for a 21st century successor to Agile/Scrum, I would recommend checking out the "async" manifesto which was written in a manner deliberately parodying the agile manifesto: http://asyncmanifesto.org/
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
Take a look at Jetty. Running out of memory is still a problem where "all bets are off" [1] but being overloaded is not. Incoming requests are queued. If there are too many requests, they are rejected (HTTP 503). The server is very solid and much lighter than other JavaEE implementations (runs like a library instead of a container).
[1] But this is mostly under your control. You shouldn't allow unbounded allocations or unvalidated user requests.
Software developers wanted for programming project, must have 10 years experience with Reactive development methodologies.
Obviously the manifesto is so short on details that it can be interpreted in many ways.
Short on detail but long on words. Compare it to the Agile manifesto which has few words, but communicates the ideas very clearly. When you read that, you understand the underlying principles of agile. This manifesto has more words, but still manages to clearly get its idea across.
When it comes to the manifesto linked in the article, as you mention it is short on detail. Specifically, who doesn't want to have a responsive system? Have you ever met anyone who said, "I think I will build a website. I want it to take 15 seconds for the pages to load." Saying you want your site to be responsive is so generic as to be meaningless.
The part that really makes me laugh is the part where they say it will have no bottlenecks. That has been the goal of designers since the day of Von Neumann. He was certain he would design his computer without bottlenecks. Once again, it's something that everyone wants.
The biggest thing they have that isn't generic there is that they require message passing. That seems like a weird requirement to me, but I'm sure they have a reason.
"First they came for the slanderers and i said nothing."
The goal is to promise heaven and earth to the management. Sell bunch of tools to the management, collect handsome consulting fees sell some books etc. By the timethecon job is realized, these guys would be on to their next scam, clueless management would have awarded itself another round of boni, (because everything done by the management deserves a bonus).
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Reactive programing already exists. Think of it as observer patterns for every variable and operation or as cell programming like you do with spreadsheets. When you update a spreadsheet cell all the formulas that rely on that cell have their values recalculated.
What they describe is more cell processing where each operation has it's own mini CPU and they all send messages to each other. There were theoretical papers about this structure of design long, long ago during the early days of computers. I'm sure it already has a name and was considerably more thought out than what these guys are saying. Actually, scratch that. I finished reading the article and they at least reference some early designs. I'll give them a point for that.
Please stop picking names that already mean something in the same field.
Please stop picking names that already mean something in the same field.
And don't pick names that can't be searched for online.
I've been following this reactive programming "movement" and it's all traced back to one guy who has a consultancy in "reactive programming" This is the 4th such reactive programming post that I am aware of on /.. No where else have I seen "reactive programming" and this is the only guy I know of who is pushing it.
In addition, the /. comments are highly ciritical of this "movement"
I call on slashdot to identify what articles are slashvertisements and or are carried on special grounds.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
The Twelve Factor App provides a more thorough treatment of elastic systems design, but generally agrees with the thesis of this document. Perhaps if that document were interactive in some way (open to signature, modification, comment, DVCS citation, etc.), we might have a better measure of its influence in the real world.
On the Play webserver the user "session" is a signed cookie. So if you have very little data, you can store it there and you always have it regardless of the server rendering the response. If you need more user specific data you can store keys in the cookie and get the session from a backend mongodb or memcached or akka cluster or something else that scales easier then an RDBMS. With the Plays ability to easily fetch data concurrently from multiple backend systems, this is actually a good way to go. Or you can just have all the user specific stuff fetched with ajax from some other servers to distribute the load.
Maybe I'm missing something here, but this "reactive" nonsense keeps popping up every few months and I still don't see what's new.
As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.
As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.
What Erik Meijer discovered was that an event can be viewed as a sequence. Each occurrence of the event is an "item" of the sequence. What's why he wrote an article called "Your mouse is a database": The mouse is a sequence of multiple event types such as moves, buttons etc.
Once you start to view (and represent) events as "push" sequences interesting things start to happen: Suddenly you can *compose* events in the same way you compose collections/sequences.
Erik Meijer wrote the Active Extensions for .NET which does exactly that. Using LINQ you can transform, aggregate, group, partition, project/map, filter etc events.
Consider, for instance, stock market ticker values: Clearly you can see those as events: When a deal/offer it is an event. Multiple events is a stream/sequence. Now imagine you want to know each time a symbol has "peaked" - i.e. each time 3 consecutive values for any symbol has the maximum as the middle value. With Reactive Extensions and LINQ you would write:
var peaks = stockQuotes.GroupBy(sq => sq.Symbol).SelectMany(g => g.Buffer(3, 1).Where(IsPeak));
where IsPeak is defined as:
bool IsPeak(IList<Quote> b) {
b[0].Rate < b[1].Rate && b[1].Rate > b[2].Rate;
}
Explanation:
1. stockQuotes is the IObservable stream of quotes.
2. GroupBy created a new stream of multiple streams. Each time a new symbol is encountered, a new group will be added (appear in the stream); if the symbol has already been encountered the quote is added to the end of the stream for the symbol.
3. Buffer creates a "sliding" buffers (increments of 1), each with 3 items.
4. Where filters the IObservable so that only "peaks" are let through.
5. SelectMany "flattens" multiple streams into a single stream again, i.e. creates a single stream of quotes regardless of their symbol (group)
Now, this is an IObservable stream with no subscribers (observers) yet. This also means that there is no subscription at stockQuotes. But as soon as you register a subscription like this:
peaks.Subscribe(Peaked)
It starts to invoke the Peaked method with peaks consisting of lists with exactly 3 items each. And this will go on and one.
Now imagine how you would write something like that using events and event handlers? It will probably take 10 times more code and be less readable than the above. (Yes, I know that it is not entirely straightforward if you are not used to RX and LINQ).
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
My understanding is that the authors of the "Reactive Manifesto" are all Typesafe guys (i.e. the commercial entity behind the Scala programming language, and the Akka framework that drives Scala's concurrency model). The only people who I ever see tweeting about this are Typesafe guys. The only people who I ever see blogging about it are Typesafe guys. The interview here is with a Typesafe guy. The Coursera class on "Reactive Programming" is taught by a Typesafe guy, using Scala. The only time I've ever heard anything about this mentioned in person was by someone at a Scala meetup.
I'm not trying to bash Scala. I was really excited when it first came out, and tried to introduce it at my last job. The combination of its learning curve, its breaking changes between versions, and the upcoming Java 8 all pretty much doomed its adoption at that shop... but it's still a neat language nevertheless.
However, the "Reactive" thing just seems like the guys behind a particular programming language publishing a "manifesto" of best practices, which exactly fits the way their particular programming language is designed. I don't know... that just seems to me like an astroturf effort to coin a new buzzword, so that your vested interest can be a leader in the space of that new buzzword. Is there any real energy around this which ISN'T coming from the professional Scala community? Do we really need a new buzzword (or "manifesto"!) to describe the longstanding concept of "message-based and event-driven"?
It seems like most of the comments here are from people who haven't connected the dots between this "manifesto" and Typesafe. A lot of people haven't read any of this stuff at all, and think that it's meant to be a methodology , as with the "Agile Manifesto" (no doubt the marketing inspiration for the name). Others have at least skimmed it, and don't see anything new with "message-based and event-driven". I believe that what's new is an effort to replace "message-based and event-driven" with a different buzzword, for which Typesafe's website already has great SEO.