Monday, November 09, 2015

HPTS 2015

I've been so busy travelling to conferences and customer engagements that I haven't had a chance to write about my trip to HPTS 2015. I've written several times about previous trips to this workshop and how it's my favourite of them all, so won't repeat. The workshop had the usual high standard of presentations and locating it at Asilomar is always a great way to focus the mind and conversations.

Because of its highly technical nature of the workshop I always like to use this event to try out new presentations - I know the feedback I receive will be constructive and worth hearing. This time my submission was essentially about what I'd written earlier this year concerning the evolution of application servers (application containers) driven by immutability and operating system containers, such as Docker. And I threw in a smattering of microservices since the topic is obviously relevant and I figured Adrian would be there! My presentation was well received and the feedback clearly showed that many people at the event agreed with it.

One other positive thing to come from the workshop and my presentation was that my co-traveller and long time friend/colleague, Professor Shrivastava, saw the presentation for the first time at the event. He understood it and whilst much of what was said I and others take for granted, he believes that there are groups of people that would find it interesting enough that we should write a paper. Writing papers with Santosh is something I enjoy and it has been a very fruitful collaboration over the years, so I look forward to this!

I also want to thank James because it was our discussions after I started my initial entries on the evolution of application servers that helped to focus and clarify my thinking.

High Integrity Software 2015 conference

I was asked to give one of the keynotes at this year's High Integrity Software Conference and I have to say that I enjoyed the entire event. It's probably one of the best technical conferences that I've been to for a while and I've been thinking about why that was the case. I think it's partly due to the fact that it was a very focussed themed event with multiple tracks for just a small part (4 talks) of the day so everyone at the event was able to concentrate on that main theme. In many ways it was similar to how conferences and workshops were "back in the day", before many of them seemed to need to try to appeal to everyone with all of the latests hot topics at the time.

The other thing that appealed to me was that I was asked to give a talk I hadn't given before: dependability issues for open source software. The presentation is now available and it was nice to be forced to put into a presentation things I've taken for granted for so many years. The feedback from the audience was very positive and then we were straight into a panel session on open source, which was also well attended with lots of great questions. Definitely a conference I'll remember for a long time and one I hope to go back to at some point.

Finally there was one presentation that stuck in my mind. It was by Professor Philip Koopman and worth reading. There's a video of a similar presentation he did previously and despite the fact it's not great quality, I recommend watching it if you're at all interested in dependable software for mission critical environments.

Tuesday, September 22, 2015

Heisenberg's back!

A long time ago (longer than I care to remember), I made the analogy between Heisenberg's Uncertainty Principle and large-scale data consistency (weak/eventual consistency). It got reported by InfoQ too. Over the weekend I came across a paper from friend/colleague Pat Helland where he made a similar analogy, so I figured I'd mention it here. What's that they say about "great minds" ;) ?

Thursday, September 10, 2015

The modern production stack

Over a year ago I wrote the first of what was supposed to be the start of a series of articles on how research our industry had been doing years (decades) ago was relevant today and even in use today, i.e., had moved from blue-sky research into reality. I never got round to updating it, despite several valiant attempts. However, thanks to James I got to see a nice article called Anatomy of a Modern Production Stack, I probably don't need to, or at least not as much as I'd expected. And before anyone points out, yes this stuff is very similar to what James, Rob and the team have been doing with Fabric8, OpenShift etc.

Sunday, June 28, 2015

Proud ...

I have two sons. They both make me proud on a daily basis. I've been away for a week at Summit and whilst there my youngest son, who's not quite 13, did something brave that made me very proud of him. I can't go into what it was except to say that he did it through the medium of social media - that annoyed me slightly but it seems to be the way of things today for a certain generation. I've told him that what he did was brave and made me proud but I figured I would also put it here so he can refer to it in the future; it's the closest I can get to social media.

Wednesday, May 20, 2015

Kids and asynchronous messaging

We've heard a lot recently about asynchronous frameworks. Typically what these really do is prevent or discourage blocking (synchronous) calls; such calls may be made, e.g., making an RPC to a remote service, but the sender thread/process either doesn't block (so doesn't actually make the call directly), or gets back some kind of token/promise that it can later present (locally or back to the receiver) in order to get the response when it needs it. Of course there's a lot more to this which I'm deliberately glossing over, but the point I'm trying to make it that most of these frameworks don't use the term "asynchronous" in the way we might understand it elsewhere. The FLP problem is a reality yet not one with which they tend to be concerned.

It's strange how the mind wanders when you're doing other things because this was precisely the problem I started to think about whilst cooking dinner the other day. With a lot of people believing that "asynchronous" is the way to go (and in many cases they're not necessarily wrong) I'm more often than not unsure as to whether they really understand the full implications. And whilst cooking I was getting frustrated with my kids, both of whom I'd tried contacting by SMS and neither of whom had responded.

So my mind wandered and I made the not-so-huge leap: I'm trying to communicate with them asynchronously. I sent each of them an SMS and I had no idea of it had arrived. Of course I could have added the SMS-delivery ack request to the messages but that can be disabled by the receiver. Therefore, until and unless they responded, I had absolutely no way to know if they'd got the message and were ignoring me, or if it had gone missing en route (SMS isn't reliable, after all). I sent more SMS messaged but with no responses I was left in the same quandary from before.

Now of course I could ring them but if they don't answer then all that does is mean I've deposited a message (voice) into some semi-persistent queue that they may or may not look at later. Another option would be to find someone who knows them and talk with them, asking for messages to be forwarded. By increasing the number of people I ask I increase the chances that one of them will eventually get through and I may receive a response (gossip protocols). However, ultimately until and unless they or a proxy (friend) for them responded (or came home) I couldn't really know directly whether or not they'd received my messages and acted upon them. Asynchronous is a bitch!

To conclude the story - they came home, had received the messages and didn't believe a response had been needed. Dinner was very tasty though!

Saturday, May 16, 2015

A little more on transactions and microservices

I had some interesting discussions this week which made me want to write something more on transactions (really XA) and microservices.

Sunday, May 10, 2015

Monoliths and a bit of a history lesson

Just another cross-post for those interested.

Update: one thing I forgot to make explicit but hopefully comes through in the above post and the earlier one on web-scale is that to suggest is that to suggest application servers (Java or something else) aren't sufficient for web-scale is difficult to justify since many high profile sites do run today quite well on them.

Web-scale: I do not think it means what you think it means!

When I blogged about transactions recently one of the comments referenced "web-scale" and how application servers aren't well suited for web-scale distributed applications. I'm going to write something specific about this later but it got me to thinking: what does that actually mean? To paraphrase Inigo Montoya "You keep using that term, I do not think it means what you think it means." Many people and groups use the term but there really isn't a common (agreed) definition. It's a cop out to claim that we don't need such a definition because everyone who is sufficiently "in the know" will "know it when they see it".

The web has been around now for a long time. Over the years it has grown considerably and yet many sites back in the late 1990's would not be considered "web-scale" today. But back then they almost certainly were. Despite what many people may suggest today, sites then and now got by well using "traditional" (or dated?) technologies such as relational databases, CORBA, probably even COBOL! Coping will millions of requests, terabytes of data etc.

It's only fair that our definition of "web-scale" should change over time in much the same way as our definition of things like "personal transport" change from "horse" to "car", or even "jet pack". But we don't even have a definition of "web-scale" that we can all get behind and then evolve. It's subjective and therefore fairly useless as a way of signifying whether anything is or is not suitable for the kinds of applications or services people develop for the web. Ideally we'd fix this before anyone (person, group, company) used the term again, but I doubt that'll happen.