Hacker News new | past | comments | ask | show | jobs | submit login

I'm a little long in the tooth so aren't as up to date with every new fangled technique to land in IT. Some of you may find this anecdote interesting and somewhat pertinent. Many years ago the electric utility I worked at had a home-grown set of batch-run Pro-C and PL/SQL programs that ran various metrology operations on large volumes of meter data. These things were interdependent, ran single-threaded and created a real "peak-CPU-demand" problem for our compute hardware (the irony was not lost). Our industry was facing an explosion in data due to the switch to smart metering. What to do?

Our apps all depended on an Oracle DB. Oracle had recently introduced Advanced Queuing. So I figured I'd de-batch and decouple these things using AQ. Every program (C++) was broken into "atomic", stateless business tasks. Every task was fed by a "task queue". Tasks would take a work-item off a queue, do their thing and depending on the outcome, would look up a destination queue (destinations could only be "business state" queues; task queues could only be subscribed to state queues (topics)), dropping the task outcome onto the state queue. Being stateless and callback driven by AQ, we could run these things together and ramp them up and down as demand required.

The overall structure and dependency of the various tasks was externalised through the data-driven queue network. The resulting solution was far more maintainable, provided "free" user-exits (by virtue of being able to plumb new tasks to existing "business state" queues), and was eminently horizontally scalable. In hindsight this was definitely not state of the art. But we were a pretty conservative business with a bunch of pretty unworldly C and PL/SQL programmers. None of us had used Java at that point. But with this approach were able to cope with a massive increase in data volume and make use of all our expensive Sun cores most of the time.

No Java, no REST, no HTML, no SOAP. But we called these queue micro services :-)




Yes, thank you.

I've done little heavy lifting with Oracle, but the general pattern you describe has been my go-to methodology for north of 20 years now. I've come to call it 'message oriented programming'. But it's just one of many ways to embrace the benefits of loose coupling.


What would happen to the system when Oracle rolled out a new version or patch?


Haha. We wished we got patches. This was back in the day when the prevailing mantra was, "Patches? We don't need no stinking patches!" (Though we did convince the DBAs to apply a necessary AQ related patch. Rare.) Having said that, Oracle were pretty good with backwards compatibility regarding their DBs. There was talk of this thing called RAC in the next version. What a dream! That's what I would have gone with to achieve "zero" downtime upgrades. Never got the chance. We used very small patch windows where all boundary processes would stop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: