'Reactive' Development Turns 2.0 101
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.
Failure tolerance is a mortal sin (Score:1)
Building a safety net into your code is a massive security risk. Programs are supposed to break or we wouldn't know something is wrong with them.
Re:Failure tolerance is a mortal sin (Score:5, Interesting)
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.
This week, it's all loosely coupled (Score:1)
Re: (Score:2)
Re: (Score:1)
All those coders who swore on pain of death that they'd never be over Macho Grande then get together for a bit of Agile Pair Scrum seppuku.
Re: (Score:2)
Also, all programming is now back-ends for web sites. If you write old-timer stuff like desktop applications, mobile apps, system software, embedded software, or front-ends for web sites, please turn in your credentials on your way out.
Re: (Score:2)
As my son would say "Is that a joke?"
Obviously. I'm a little disturbed that apparently at least two people thought otherwise...
Re: (Score:3)
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.
Re:Failure tolerance is a mortal sin (Score:5, Insightful)
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 [agilemanifesto.org] 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 [programmin...fucker.com].
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.
Re: (Score:2)
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.
If you don't have user state or session state, scaling is no problem. You just throw more hardware at it so you can have replicated servers with a simple load balancer in front. Job done.
It's scaling in the presence of (mutable) state that is hard. It's also what a lot of use cases need. Sometimes you even have to give up on scaling (boo!) in order to achieve other objectives, or think very hard to come up with an alternative approach such as spinning out processing to cloud-based slaves, which also doesn't
Re: (Score:3)
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
Re: (Score:2)
"Also people often did not use J2EE session replication, because it was considered a pain."
Yeah, I looked into that once, the tutorials alone made me run screaming.
Re: (Score:1)
STOP ERROR
mouse has moved
Reboot To Continue
Stopped reading right there. (Score:2, Insightful)
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]
Re: (Score:1)
The height of marketing-speak, lots of vague, fact-free statements.
Methodologies are like religion (Score:4, Insightful)
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 [scientology.org].
Re: (Score:2)
On the surface it seems easier, because things happen automatically, without having to be explicitely defined. The part I'm struggling with is how to keep the code clean and readable with all this stuf
Re: (Score:2)
Design your code so that order of execution isn't assumed. This is a functional programming idea, and while functional may not be right for your applications this is an easier concept to see in its native environment. I.E. learn Haskell even if you use something else for your code
Re: (Score:2)
Re: (Score:3)
That's one of the things you get rid of. You don't have variables in a global sense, there is no mutable global data. Functions have arguments and those are local variables but that's more like a definition there are no state changes permitted in the bulk of your code.
If you need to change the variable type you create a monad. The key to a Monad is it lifts a variable. So for example if you want to have error code as a return type on function that before couldn't error you use the Either Monad.
So say fo
Re: (Score:2)
a two-way databinging model like angular's is a specific mvc use case where the good old observer pattern makes a lot of sense. it indeed allows for much cleaner code given that you know the context.
"reactive" is basically the same thing, with a cooler name and applied indiscriminately to everything else. go figure, but it's all the rage.
Re: (Score:2)
databinging
this wasn't intentional but i like it :D
Re: (Score:3)
Yuck - two way databinging sounds like there's a purging phase involved!
Re: (Score:2)
a two-way databinging model like angular's is a specific mvc use case where the good old observer pattern makes a lot of sense.
I'm not sure that's true.....
"reactive" is basically the same thing, with a cooler name and applied indiscriminately to everything else.
That's definitely true
Re:Methodologies are like religion (Score:5, Insightful)
Methodologies are like religion
But this isn't a "methodology" at all. It's a statement of goals.
This isn't an "alternative to Agile", because it isn't a methodology. You can use Agile to achieve this "reactive system".
Frankly, it looks like a bunch of BS buzzwords to me. I write software to meet my customer's needs. "Reactive" attempts to define those needs... but NO, that's what the customer does.
This might be something good to show a client who wants a web site built, which you then proceed to build using Agile or some other methodology. But it isn't a methodology itself, and calling that thing a "Manifesto" is a joke.
"We want a machine that makes things cold. We don't care how it's built. We'll call this... The Refrigerator Manifesto".
Give me a frigging break. In fact I have to think this is actually somebody's idea of a joke.
Re: (Score:2)
For 20-something years, they've been telling me to be "PRO"-active. Because just plain "active" wasn't good enough anymore. Or at least didn't sound pompous enough.
NOW you want RE-active???
Re: (Score:2)
You'd expect being "PRO"-creative would be a goal too.
Re: (Score:3)
For 20-something years, they've been telling me to be "PRO"-active. Because just plain "active" wasn't good enough anymore. Or at least didn't sound pompous enough.
NOW you want RE-active???
Count your blessings. My boss always wants all my fixes to be retroactive.
Re: (Score:2)
Well, software development is about many stakeholders. You, as the developer, are one of those stakeholders. Yes, the customer has a set of requirements, but you have a set of requirements as well. You make technical decisions every day based on those requirements whether you have explicitly enumerated them or not.
My read on this is that it's a set of governing principles for making implementation decisions about how you write code. As such any one of these guiding principles can be set aside to accompl
Re: (Score:2)
you're doing it wrong, you forgot the catchy t-shirt.
Re: (Score:2)
Re: (Score:2)
At the end of the day, these methodologies are only there to give a framework for more predictable results.
As long as they're followed, it doesn't matter (much) which one you pick. The problem is when people deviate from them nilly willy...then their only benefit (predictability) is tossed out of the window.
Can't wait... (Score:5, Funny)
Re:Can't wait... (Score:4, Funny)
I'm in the wrong business!
Okay, staring now, you can get certified in Fad Oriented Programming for just $500! It's always the hottest trend!
Re: (Score:2)
This seems more specialised, so maybe it should be "fanatically loose Internet programming". That would make the abbreviation "FLIP-FLOP", which conveniently also describes the views of anyone who "signed" this "manifesto" when the next buzzword comes along next week.
Re: (Score:2)
I'm in the wrong business!
Okay, staring now, you can get certified in Fad Oriented Programming for just $500! It's always the hottest trend!
FOP isn't something that any dweeb with $500 can get into. First you have to order the FOP toolkit, which is going to cost you at least 10 times that. Then, of course, there's the FOP Official Specifications. Add another zero after that.
Re: (Score:2)
You forgot that they have to take an official class to take the cert exam....
agile != reactive (Score:3, Interesting)
I don't think reactive is the evolution of agile, as the author in the author implies.
Re: (Score:1)
or rather "the author in the article" :)
Re:agile != reactive (Score:4, Insightful)
Re: (Score:2)
Agreed.
Agile manifesto is about organizing work.
Reactive manifesto is about designing the architecture.
With agile, architecture is not the priority since the point of view is from the project manager's side.
By the way, the blog is blocked by NoScript. Does an article needs Javascript to be displayed ? WTF ?
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
Fine, the reactive document is a manifesto describing a set of architectural principles that supposedly has benefits in the current world. The agile document is a manifesto describing a set of project management principles that supposedly has benefit in the current world (although, in reality, it's twenty years old now and the people who are now promoting it are becoming just as rigid and annoying as the UML/SEI/PDP/heavy doc assholes they replaced). Conflating the two as related (other than in name) was i
Re: (Score:2)
Fine, the reactive document is a manifesto describing a set of architectural principles that supposedly has benefits in the current world.
Agreed.
The agile document is a manifesto describing a set of project management principles that supposedly has benefit in the current world
"project management principles" sounds a lot like "organizing work" to me, which is what the ggp said.
Re: (Score:2)
Successor to Agile/Scrum (Score:5, Interesting)
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/ [asyncmanifesto.org]
Re: (Score:1)
Re: (Score:2)
It's a bit of a circular argument to say that sprint planning meetings exist because product owners don't have time to frequently reassess priority on their own. Before Scrum really took off, I recall product owners having no trouble finding the time to own the issue tracker in this manner on a regular or even daily basis.
It seems to me everyone would have significantly more time for such things if there was less process in the way like unnecessarily verbose scrum meetings which can be replaced by less inva
I can see the ads now... (Score:5, Funny)
Re: (Score:1)
Software developers wanted for programming project, must have 10 years experience with Reactive development methodologies.
If you can't figure out how to manipulate space-time, why should I hire you?
Re: (Score:2)
If you could (in the way you wanted), you wouldn't need to hire anybody.
Re: (Score:2)
If you can't figure out how to manipulate space-time, why should I hire you?
Bring your own weapons. Safety not guaranteed. I've only done this once before.
Re: (Score:2, Funny)
Anti-Fragile is the rage now (Score:2)
Re: (Score:2)
Good news, everyone... just like with Agile I have 10 years experience with reactive methodologies.... we just called them something else back then, now that we have a name for reactive methodology, we can claim it :)
Re: (Score:2)
This isn't funny.
It is, nonetheless true.
póngame mil (Score:2)
just had a look at the manifesto: it's about software architecture and design. i can't see how it should compare to agile, which is about software development metodologies. anyway i'm okay with those 4 principles but don't quite understand what's new here (apart from reading "responsive" in its correct meaning for once!)
but one thing i can say for sure: this one aint gonna fix what's broken in software developement industry either, which is: industry! industry! industry!
Reactive will meet its goal. (Score:4, Insightful)
BS Naming (Score:2, Insightful)
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 su
Re: (Score:3)
"Reactive" lends itself well to an async datapipeline message passing design. Highly scalable and relatively easy to understand.
Re: (Score:2)
They were called actor-based programming systems. They came about in the mid-to-late 1960's and incorporated into languages in the early 1970's (look up Hewitt's work on Actors). Pros: Decentralized computational agents connected by message-passing can increase resilience in a system. Cons: Non-local flow of control and unknown state/functionality within remote computational agents (which always inadvertently leaks out) makes understanding what is actually happening in the system overall difficult, leading
Stop with the SLASHVERTISEMENTS! (Score:4, Insightful)
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.
The Twelve Factor App... (Score:3)
The Twelve Factor App [12factor.net] 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.
12 Factor (Score:1)
Let's rewrite history (Score:2)
and give it a new name. That seems to be the pattern these days, isn't it. The techniques and concepts described in this "Manifesto" are really nothing more than the tenet of systems design since the dawn of the computer age. Yet, he touts it like its some sort of new idea. Same goes for programming languages, frameworks and paradigms - most are rehashes of what came before.
I have been a proponent of using message queues to build asynchronous and distributed system that make building such "responsive" s
What About Jobs Developement Style (Score:2)
There's another name for this kind of developmen (Score:2, Interesting)
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.
Reactive is an extension of event driven (Score:4, Informative)
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).
Re: (Score:2)
Certainly cool, but most of the credit goes to C# supporting LINQ & lambda functions.
The point is, that when you view events as
public event EventHandler StockQuote;
you cannot use the LINQ goodness to compose events. Once you make the switch and view events as sequences where the items have not appeared yet, you enable the likes of LINQ and list comprehensions.
Mind you, these IObservable LINQ operators look like the IEnumerable counterparts - but they are all implemented quite differently. There is a beautiful duality between the two which enable us programmers to think about events the same
Re: (Score:2)
Well, that's about par for the course. An oversimplified example that gets the domain knowledge wrong. Almost no one looks for "peaks" like that in finance. They are either looking for mismatches in market prices from multiple sources or for trends.
Your example is stupid. You might want something like that for a domain needing signal detection, though, so good try. You just didn't know enough about anything in the real world to get it RIGHT.
Is this just an astroturf campaign for Scala? (Score:3)
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.