Stay Updated!



This site uses cookies to improve your user experience. By using this site you agree to these cookies being set.


If it ain’t broken it probably doesn’t work anyway

“If it ain’t broken don’t fix" it is a saying that is not only past its sell-by date but 100 percent obsolete - finito benito. Why? Because even if it’s not broken now, pretty much any system, will not be fit for purpose within a few years. There are two major drivers for this new reality: the size of the Internet and number of users has grown exponentially, and will continue to do so, and developments in hardware with faster data transfer over multiple devices in disparate locations.

Old-school systems are straining under the pressure, like an old bridge being constantly bolstered up to cope with a weight and volume of traffic it was never designed for. Luckily, or rather by design, there’s an alternative akin to the floating pontoon bridge, which is moveable and can adapt to changes in water level, distance between banks, volume of water and speed of flow.

The Reactive Manifesto provides the latest paradigm for architecting software solutions and realistically, it’s the only way to go. To understand why, let’s review what a web application or web system really is.

Crumbling bridges and dropped bricks

What you see in a browser is an HTML page rendered by your local system with data processed by a remote system. The network functions asynchronously, sending pieces of data as data packets. What appears on your screen is a stream of information from the servers processed by your local computer. To use an app, you have to interact with the browser, click and move the mouse and so forth. These interactions send messages to the server to process. You don’t need to wait for each packet to be processed. You expect it to be processed by the backend as a stream. It is this asynchronicity that makes the system reactive, but therein lies the problem.

Like the old bridge, most conventional systems, even relatively recent ones, were not designed to manage the sheer volume of traffic generated on a current website. As information packets are whizzed to and fro, asynchronous transfers can lead to buffering problems and backend log jams where the ball gets dropped. Imagine a line of builders on a rooftop throwing bricks to each other, if the guy stacking them up at the end of the line has to take an urgent phone call from the boss, he’s likely to get whacked on the head - and still the bricks keep coming. Likewise, large, heavy centralised systems are slow to react and difficult and expensive to change. What if we could isolate the problem of the guy taking the call, immediately without everyone having to down tools? We can, through reactive programming.

From the bridge to the forest

Have you ever seen a bridge in the middle of nowhere, a Roman one perhaps? When built it spanned two sides of a great river and linked the people of a thronging city. But the river dried up, the people moved away and the bridge is now just a tourist attraction. Throughout the last couple of decades, we’ve been preoccupied with building bigger and better bridges but slowly, it’s beginning to dawn on people that the engineering properties of a bridge have built-in constraints, and that its load-bearing capacity will always be finite and insufficient.

Reactive systems are not just about programming or even architecture, but a paradigm for reframing the task at hand. The challenge changes from “how to build a better bridge” to “how to get from A to B and back again, then to C should B become irrelevant or disabled, or how the same system might cope with getting from X to infinity.” Like the ecosystem of the Amazon jungle, the antidote to the plant that poised you, is always close at hand. Step into the verdant forest of reactive systems, teeming with life and infinitely self-sustaining.

The five reasons

So now we’ve set the scene and explained why the old way is broken and wouldn’t work even if we taped it back together, let’s talk turkey and examine five solid reasons to invest in reactive systems.

1. You need to take out insurance against the future

Five years from now there will be no big app servers, no big SQL servers, but billions of connected devices constantly communicating with each other - hang on a minute, isn’t this already the case?

There is no better architecture for big solutions, which should consist of many small systems that communicate with messages.

We need to build for the web, multiple nodes and concurrent processes.

People will use that which is simpler, faster and cheaper - always.

Reactive systems are cheaper because you don’t need to constantly rebuild things and even if you do, you can do it faster - back to the pontoon bridge, we can take it down and put up another one overnight.

2. Backing the future is the only worthwhile strategy

In Britain, there used to be a betting tax of 10 percent on bets. Gamblers could pay the tax when they placed the bet or when they collected their winnings. In a prisoner’s dilemma decision, they had to decide whether to pay the lower amount on the stake, which would be less than if they won but wasted if they lost; or they could choose not pay when placing the bet but instead pay the higher sum of 10 percent of the winnings if the bet proved successful. Most chose to pay the tax on the winnings, assuming they would lose the bet and not have to pay the tax at all. In so doing, they chose not to back themselves.

But you are in it to win it and have to assume that your business will continue to prosper and expand - one day, you may have millions of users. Could your current system scale up to meet significant load increase? Could it run on any number of devices without modification?

3. You need to be faster than your competitors

Faster fish eat big fish. CPU cores will not get any faster while reactive systems use all processor cores of the machine and can run on a cluster of machines. Asynchronicity means no waiting - results become available as they appear.

Reactive systems can be developed faster (because of Scala language, Akka framework or Lagom framework)

The quicker you can implement changes, the faster you can bring your products and services to market, giving you a clear advantage.

4. There is life after death as the gecko knows well

In the reactive programming world, the system will recover from apparently fatal failures. These will limit functionality, (temporarily) but will not bring down the whole system, in the same way the gecko can detach its tail when attacked, allowing it to escape and grow a new one.

5. Immortality is a reality

Our systems need not be slowed by cell degeneration and ageing or perish through mortality. Reactive systems allow for unlimited upgrades with zero downtime, ensuring constant service delivery - as if performing a transplant while remaining fully functional, the body rebuilding itself as it goes.

And, if you should wake up one day to find all the rules have suddenly changed and you need to sell umbrellas instead of sunglasses, or that you’ve got 600,000 customers instead of 60,000, reactive systems will be the first to perform the metamorphosis for your business.

The arguments for switching to reactive systems are irrefutable; they are faster, cheaper, more elastic and resilient and can respond instantly to the changing dynamics of both the business world and evolving technologies.

There’s only one step for you to take and that’s to contact JAVEO now to discuss your needs. We are ready to react!

comments powered by Disqus

We are hiring!

We are looking for You! Join a vibrant, growing business offering training, career development opportunities and personal freedom.

Join Us