tag:blogger.com,1999:blog-92035572017-09-05T14:46:23.355+01:00Mark Little's WebLogI work for Red Hat, where I lead JBoss technical direction and research/development. Prior to this I was SOA Technical Development Manager and Director of Standards. I was Chief Architect and co-founder at Arjuna Technologies, an HP spin-off (where I was a Distinguished Engineer). I've been working in the area of reliable distributed systems since the mid-80's. My PhD was on fault-tolerant distributed systems, replication and transactions. I'm also a Professor at Newcastle University and Lyon.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.comBlogger596125tag:blogger.com,1999:blog-9203557.post-86031869898821143642017-01-06T19:32:00.001+00:002017-01-06T19:32:18.930+00:00PsyncFollowing on from the <a href="http://markclittle.blogspot.co.uk/2017/01/multicasts-and-latency.html">last entry</a>, we shall now consider one implementation of a communication subsystem which provides some of the delivery properties described previously. It is important to understand how these ordering requirements can be met, and the overhead which is involved in guaranteeing them, before we discuss how such communication primitives can be used to provide replicated object groups. Other reliable communication subsystems&nbsp;exist, of which [Chang 84][Cristian 85][Cristian 90][Verissimo 89] are a sample, but we shall consider Psync because it illustrates many points clearly.<br /><h3>Psync</h3><div><div><i>Psync</i> [Peterson 87][Mishra 89] ("pseudosynchronous") is a communication subsystem designed to provide reliable multicast communication between objects, and is based on the message history approach described above. The system assumes that operations on objects which change the state occur atomically and are idempotent. Associated with each object is a manager process. A client process locates a particular manager (perhaps by consulting a naming service) and then invokes operations on the object by sending requests to that manager. When a manager receives a request to invoke a particular operation on an object, it encapsulates the operation in a message and uses the Psync many-to-many communications protocol to forward the message to all of the managers involved (including itself) if the object is a member of a group. Based on the set of received messages, each manager can then decide on an order in which to apply the operations to its</div><div>copy of the object. This protocol can be extended to be used for the interactions of replicated object groups, and the exact details of the replication protocol used in Psync will be described in a later posting.</div></div><h4>Conversations and Context Graphs</h4><div><div><i>Psync</i> explicitly preserves the partial ordering of messages exchanged among a collection of processes in the presence of communication and processor failures (Psync cannot function in the presence of network partitions). A collection of processes exchange messages through a <i>conversation</i> abstraction. This conversation is defined by a directed acyclic graph (a <i>context graph</i>) that preserves the partial order of the exchanged messages. This ordering is made available to all managers involved in a conversation and by using this they can determine when to execute operations on their local objects.</div><div><br /></div><div>When processes communicate they do so by sending messages in the <i>context</i> of those messages they have already received. Participants are able to receive all messages sent by the other participants in the conversation but they do not receive the messages that they themselves send. Each participant in a conversation has a view of the context graph that corresponds to those messages it has sent or received. The semantics of the communications primitives provided by Psync are defined in terms of the context graph and a participant's view.</div><div><br /></div><div>The figure below shows an example of a context graph. This conversation is started with the initial message m1. Messages m2 and m3 were sent by processes that had received m1, but are independent of each other (hence no link between them), and m4 was sent by a process that had received m1 and m3, but not m2. Messages that are not in the context of some other message are said to be concurrent (occur at the same <i>logical time</i>). The relation &lt; is defined to be "in the context of".</div></div><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-g6fC8W8ZQUg/WG_uRcR_adI/AAAAAAAABsA/mwPjvJbpYmgaZF3c_BmW5IY-LLDXgNLUACLcB/s1600/Screen%2BShot%2B2017-01-06%2Bat%2B19.21.16.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="260" src="https://1.bp.blogspot.com/-g6fC8W8ZQUg/WG_uRcR_adI/AAAAAAAABsA/mwPjvJbpYmgaZF3c_BmW5IY-LLDXgNLUACLcB/s320/Screen%2BShot%2B2017-01-06%2Bat%2B19.21.16.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: left;">The context graph contains information about which processes have received what messages. The receipt of a message implies that the sender has seen all of the messages which came before it in the context graph. A message mp sent by process p is said to be <i>stable</i> if for each participant in the conversation q ≠ p, there exists vertex mq in the context graph sent by q, such that m &lt; mq. For a message to be stable means that all participants except the sender have received it, it must follow that all future messages sent to the conversation must be in the context of the stable message.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">In the figure below, we have a context graph which depicts a conversation between three participants, a, b, and c. Messages al, a2, ... denotes the sequence of messages sent by process a, and so on. Message al, b1, and c1 are the only stable messages; messages a2 and a3 are two unstable messages sent by process a.</div><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-URZaXYPq7ZA/WG_uhGVs3xI/AAAAAAAABsE/pglGyCKSNWALpHRAEN3kd4RceakCY-D8wCLcB/s1600/Screen%2BShot%2B2017-01-06%2Bat%2B19.22.26.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="319" src="https://3.bp.blogspot.com/-URZaXYPq7ZA/WG_uhGVs3xI/AAAAAAAABsE/pglGyCKSNWALpHRAEN3kd4RceakCY-D8wCLcB/s320/Screen%2BShot%2B2017-01-06%2Bat%2B19.22.26.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: left;">Psync maintains a copy of a conversation's context graph at each host on which a participant in the conversation resides. Each process in the conversation receives messages from this local copy of the context graph, which is termed the <i>image</i>. Whenever a process at one host sends a message, Psync propagates a copy of the message to each of the hosts in the conversation. This message contains information about all messages upon which the new message depends, so that the receiving hosts can append it to their context graphs in the correct place.</div><h4>Dealing with Network and Host Failures</h4><div>Suppose message m is not delivered to some host because of a network failure. If at some future time a message m' arrives that depends on m then the host will detect that it is missing m and will send a retransmission request form to the host that sent m', (this host is guaranteed to have m as a local participant has just sent a message which is in the context of it).</div><div><br /></div><div>The operations provided to aid applications in recovering from host failures include the ability for a participant to remove a failed participant from its definition of the participant set for a conversation. This is necessary so that messages will eventually stabilize relative to the functioning participants. Once a given participant has been masked out, Psync ignores all further messages from that process.</div><div><br /></div><div>There is also an inverse operation that allows a participant to rejoin a participant set. It would be invoked when a participant becomes aware that another participant which was formally failed has now recovered.</div><div><br /></div><div>When a host recovers, a participant can initiate a recovery action which will inform other participants that the invoking participant has restarted, and to initiate reconstruction of the local image of the context graph. Each member of the conversation will transmit its local copy of the context graph to the recovering participant who can then use this to reconstruct its own local copy.</div><h4>Total Ordering</h4><div>As described, the Psync protocol only gives a partial ordering of messages i.e., only the causal ordering of messages is preserved. To convert a partial order into a total order, whereby messages which are not causally related are ordered identically at all overlapping destinations, requires additional information to be shared amongst the destinations which indicates the order in which to place such messages. In Psync, the context graph which accompanies each message provides this information. The partial order that Psync provides can be used to give a total order if all participants perform the same topological sort of the context graph. This sort must be incremental i.e., each process waits for a portion of its view to be stabilized before allowing the sort to proceed. This is done to ensure that no future messages sent to the conversation will invalidate the total ordering.&nbsp;The replication protocol used in Psync uses just such a scheme and will be described in a later article.</div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-86449458104611960472017-01-03T17:30:00.002+00:002017-01-08T13:33:20.330+00:00Multicasts and LatencyThe next few entries in <a href="http://markclittle.blogspot.co.uk/2016/12/rpcs-groups-and-multicast.html">the series</a> will consider some aspects of multicast protocols.<br /><div><br /></div><div><div>As described in [<a href="http://iopscience.iop.org/article/10.1088/0967-1846/1/6/001/pdf">Shrivastava 90a</a>], the latency of a multicast service is defined to be the time taken for a message, once sent, to reach the destination processes. This latency is particularly important for protocols providing reliability and ordering guarantees. As we shall see, whereas the latency for an unreliable multicast service is bounded (typically of the order of a few milliseconds), the latency for a multicast service which operates in the presence of failures (message losses and node crashes) can be bounded or unbounded depending upon the implementation.</div><div><br /></div><div><div>Existing order preserving protocols can be broadly classified in the following way:</div></div><div><ul><li><i>message history based</i>: the main idea behind such protocols is that when a process sends a message it appends some historical information about the messages it has received in its recent past. This historical information enables the receivers to retrieve any missing messages and to order them properly. This type of protocol ensures that an incomplete multicast is eventually completed, and hence possesses an unbounded latency property.</li><li><i>centralised distributors</i>: here the sender delivers the message to a specific member of the group (the primary) who is then responsible for distributing the message to the fellow members of the group. The primary can assign a total order to the messages it receives. As we have already seen, failure detection mechanisms are necessary to detect failed primaries and to elect new primaries which can take over and complete the multicasts. Such protocols can possess bounded latency, but the necessity to detect asynchronously occurring failures can impose an overhead on performance.</li><li><i>multi-phase commit</i>: these protocols, providing total order, use multiphase algorithms (typically 2 or 3 message rounds) which are similar to the two-phase algorithm described earlier for atomic action commits. The sender delivers the message to the destinations which return sufficient information to the sender about the messages that they have received so that in the subsequent rounds of the protocol the sender can impose an identical order of the message onto the destinations. The message is only considered to have been delivered if all of the phases of the protocol complete. Such protocols provide bounded latency.</li><li><i>clock-based</i>: these protocols are an important class of the multi-phase algorithms, and assume the existence of a global time base. Timestamps derived from such a time base can then be used for imposing a total order on messages. Such protocols can provide constant latency communication, having the attractive property that if a sender multicasts a message at clock time T, then it can be sure that all functioning receivers will have received the message by clock time T + ∆, where ∆ is the constant indicating the protocol latency (∆ must be determined by applying worst case timing and failure assumptions).</li></ul>We shall next examine a system which provides a reliable multicast protocol using a message history based approach.</div><br /></div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-90382023346681159772017-01-02T18:11:00.000+00:002017-01-03T17:17:56.513+00:00A Java EE InterludeI want to take a quick break from the <a href="http://markclittle.blogspot.co.uk/2016/12/some-historical-blogging.html">other series</a> for a moment to do something I've been remiss about for a while: addressing a <a href="https://www.gartner.com/doc/reprints?id=1-3N8E378&amp;ct=161205&amp;st=sb">recent report by Gartner </a>on the state of Java EE. Before doing so I decided the other day to <a href="http://johnclingan.com/2016/12/19/reanalyzing-the-state-of-java-ee/">read the article</a> my friend and colleague John Clingan made a few weeks ago and I realised that John had done a great job already. In fact so good I couldn't see myself adding much to it, but I'll try below. Note, there are <a href="http://www.pscheidl.cz/opinions/Gartner-JavaEE-report/">other responses</a> to this report and I haven't had a chance to read them but they might be just as good.<br /><br />To start with, it's worth noting that I've known Anne for a number of years and we've had one or two disagreements during that time but also some agreements. Her announcements about <a href="http://markclittle.blogspot.co.uk/2009/01/soa-is-dead-again.html">the death of SOA</a> seven years or so ago falls somewhere in between, for example. It's also important to realise, if you don't already, that I do believe everything has a natural cycle ("<a href="https://www.youtube.com/watch?v=GibiNy4d4gc">the circle of life</a>") and nothing lasts forever; whether it's dinosaurs giving way to mammals (with some help from a meteor and/or the <a href="http://www.livescience.com/15249-earths-biggest-eruptions-source.html">Deccan Traps</a>), or CORBA shifting aside for J2EE, evolution is a fact of life. Therefore, whilst I disagree with Anne about the short-to-medium term future of Java EE, longer term it will pass into history. However, before doing so it will evolve and continue to influence the next generation of technologies, just as the dinosaurs became the birds and aspects of CORBA evolved into J2EE. For more details on my thinking on this topic over the years I leave it as an exercise to the reader to check <a href="http://markclittle.blogspot.co.uk/">this blog</a> or my <a href="https://developer.jboss.org/blogs/mark.little">JBoss blog</a>.<br /><br />John covers my next point very well but it's worth stressing: I've mentioned on many occasions that my background is heavily scientific and I continue to try to employ <a href="http://markclittle.blogspot.co.uk/2016/04/poor-scientific-method.html">objective scientific method</a> to everything I do. So when I see blanket statements like "fade in relevance" or "lighter-weight approaches", whether it's in a Gartner report, a paper I'm reviewing as a <a href="https://books.google.co.uk/books?id=X5FqCQAAQBAJ&amp;pg=PR12&amp;lpg=PR12&amp;dq=Mark+Little+Red+Hat+conference+Program+Committee&amp;source=bl&amp;ots=ARp3-hGg_-&amp;sig=L2H74EiBYh1vyGVWparmsTQadyo&amp;hl=en&amp;sa=X&amp;ved=0ahUKEwiYlIyB9KPRAhXLBcAKHaEkBHkQ6AEIGjAA#v=onepage&amp;q=Mark%20Little%20Red%20Hat%20conference%20Program%20Committee&amp;f=false">PC member</a>, or even something one of my team is writing, I immediately push back if there's no supporting evidence. And I read this report several times searching for it but kept coming up empty handed. It was one subjective statement after another, with no real attempt to justify them. That's disappointing because with my scientific hat on I love to see facts backing up theories, especially if those theories contradict my own. That's how we learn.<br /><br />One other thing I did get from the report, and I'm prepared to admit this may be my own subjective reading, was that it seemed like a vague attempt to look into the future for middleware frameworks and stacks without really understanding what has brought us to where we are today. I've written about this many times before but weak assertions by the report that "modern applications" are somehow so different from those we've developed for the last 50 years that existing approaches such as Java EE are not useful really doesn't make any sense if you bother to think about it objectively. Distributed applications, services and components need to communicate with each other, which means some form of messaging (hopefully reliable, scalable and something which performs); there's really no such thing as a stateless application, so you'll need to save data somewhere (again, reliable, scalable and performant); hey, maybe you also want some consistency between applications or copies of data, so transactions of one form or another might be of help. And the list goes on.<br /><br />Of course application requirements change over time (e.g., I recall doing research back in the 1980's where scale was measured in the 10's of machines), but new applications and architectures don't suddenly spring into being and throw away all previous requirements; it's evolution too though. I've presented my thoughts on this over the past couple of years at <a href="http://www.hpts.ws/papers/2015/little.pdf">various conferences</a>. In some ways you can consider Java EE a convenient packaging mechanism for these core services, which are typically deployed in a co-located (single process) manner. Yet if you look beyond the Java EE "veneer" you can still see the influence of enterprise distributed systems that predate it and also the similarities with where some next generation efforts are heading.<br /><br />I suppose another key point which John also made well was that the report fails miserably to differentiate between Java EE as a standard and the various implementations. I'm not going to cover the entire spectrum of problems I have with this particular failure, but of course lightweight is one of them. Well over 5 years ago <a href="https://developer.jboss.org/blogs/mark.little/2011/06">I wrote</a> about the things we'd done years previously to make AS7 run on a plug computer or Android phone and we've kept up that level of <a href="https://developer.jboss.org/blogs/mark.little/2012/10/01/jboss-changing-the-face-of-enterprise-java">innovation</a> up throughout the intervening time. There's nothing in the Java EE standard which says you have to build a bloated, heavyweight application server and we, as well as other implementations, have proven that time and time again. It's disappointing that none of this is reflected in the report. I suppose it's one of those terms the authors hope that if they say it enough, people will attribute their own subjective opinions and assumptions to it.<br /><br />Another one of those throw-away statements the report is good at is that "[...] at this point, Java developers eschew Java EE". I admit not every Java developer wants to use Java EE; not every Java developer wanted to use J2EE either. But you know what? Many Java developers do like Java EE and do want to use it. You only have to go to conferences like JavaOne, Devoxx or other popular Java events to find them in abundance. Or come and talk to some of our customers or those of IBM, Payara, Tomitribe or other members of the MicroProfile effort.<br /><br />I could go on and on with this but the entry has already grown larger than I expected. John did a great job with his response and you should go read that for an objective analysis. Probably the only positive thing I could attribute to the original Gartner report is that its very existence probably proves that time travel is possible! It's a theory which fits the facts: a report which criticises something based on data which is largely a decade old means it was probably written a decade ago.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com2tag:blogger.com,1999:blog-9203557.post-49620527304161174402017-01-01T11:52:00.001+00:002017-01-08T13:34:21.155+00:00Remote Object InvocationThe next in <a href="http://markclittle.blogspot.co.uk/2016/12/rpcs-groups-and-multicast.html">our series</a> ...<br /><br />Invocations on objects which are not replicated are traditionally based on the RPC as this retains the correct semantics of a procedure call i.e., a single flow (thread) of control from caller to callee and back again (as with a traditional procedure call). The previous <a href="http://markclittle.blogspot.co.uk/2016/12/rpcs-groups-and-multicast.html">entry</a> described the concept of the Remote Procedure Call, and the simplified model of client-server interaction shown in the figure below will be assumed for the discussion to follow: a client uses the primitives sendjequest() for sending a call request and receive_result() for receiving the corresponding results. Clients and servers maintain enough state information to recognize and discard duplicate messages (filter requests). The server maintains a queue of messages from possibly multiple clients, and uses the primitive receive_re quest() to pick a message from the queue in a fifo order. After invoking the right method, the result is sent to the client with the send_result() primitive.<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-9duyhER1Hh8/WGjnOLCZTjI/AAAAAAAABrM/PkVlJf3zIoIvkG-NT_CuiSOlaOFKkOkzwCLcB/s1600/Screen%2BShot%2B2017-01-01%2Bat%2B11.25.22.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="179" src="https://1.bp.blogspot.com/-9duyhER1Hh8/WGjnOLCZTjI/AAAAAAAABrM/PkVlJf3zIoIvkG-NT_CuiSOlaOFKkOkzwCLcB/s640/Screen%2BShot%2B2017-01-01%2Bat%2B11.25.22.png" width="640" /></a></div><div class="separator" style="clear: both; text-align: left;">When making replicated invocations (such as when calling a replica group) the semantics of such communication differ considerably from that of the traditional RPC: there is no longer a single thread of control, but rather multiple threads which may all eventually return to the caller. Such invocations are typically referred to as Replicated Procedure Calls [Cooper 84a][Cooper 85], and can be implemented using one—to—many (or multicast) communication facilities. We discuss various aspects of multicast communication below.</div><h3>One-to-Many Communication</h3><div><div>The main services a multicast protocol provides can be categorised into three classes: ordering, reliability and latency. By imposing (increasing) ordering and reliability constraints on the delivery of multicast messages it is possible to define increasingly sophisticated protocols (typically at the expense of the latency). To understand these protocols first assume that a sender S is attempting to multicast to a group G = {P<span style="font-size: x-small;">1</span>,...,Pn}. Following the definitions outlined in [Shrivastava 90b][<a href="http://www.computerconservationsociety.org/ansa/94/Primary/100201.pdf">ANSA 90</a>]:</div></div><h4>Unordered and Unreliable</h4><div>A multicast from S will be received by a subset of functioning nodes Pi ∈ G. Successive multicasts from S will be received in an arbitrary order at the destinations. The next figure shows sender S multicasting messages m1 and m2 to the group G. The first message is received by P2 and Pn in different orders, and message m2 is not received by P1</div><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-IMSnRYmFUJk/WGjowtfdtDI/AAAAAAAABrU/WxOvxumF0VczAmVyDIzkc4N0x3giUN69ACLcB/s1600/Screen%2BShot%2B2017-01-01%2Bat%2B11.31.52.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="202" src="https://3.bp.blogspot.com/-IMSnRYmFUJk/WGjowtfdtDI/AAAAAAAABrU/WxOvxumF0VczAmVyDIzkc4N0x3giUN69ACLcB/s640/Screen%2BShot%2B2017-01-01%2Bat%2B11.31.52.png" width="640" /></a></div><h4>FIFO Multicast</h4><div><div><br /></div><div>Provided the sender does not crash while transmitting the message, all correctly functioning receivers are guaranteed to get the message. Furthermore, the multicasts will be received in the order they were made.</div><div><br /></div><div>The next figure shows two senders (S 1 and S2) multicasting to the group G. All members of G received m1 before m2, but some members may receive m3 before m2. This last ordering is correct given the definition of the protocol: no information about the relative ordering of multicasts between senders is available to the receivers.</div></div><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-URMDPNQ74yg/WGjpG9wZ6PI/AAAAAAAABrY/nlvi0f4_TaoSc8Pi7H_1mCRbpeovSLHVACLcB/s1600/Screen%2BShot%2B2017-01-01%2Bat%2B11.33.28.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="238" src="https://1.bp.blogspot.com/-URMDPNQ74yg/WGjpG9wZ6PI/AAAAAAAABrY/nlvi0f4_TaoSc8Pi7H_1mCRbpeovSLHVACLcB/s640/Screen%2BShot%2B2017-01-01%2Bat%2B11.33.28.png" width="640" /></a></div><h4>Atomic multicast</h4><div><div><br /></div><div>If the sender does not crash before completing a multicast, the message is guaranteed to be received by all functioning members. If, however, the sender crashes during a&nbsp;multicast, then it is guaranteed that the message is received by either all or none of the functioning processes (atomic deliveiy). All multicasts from the same sender are received in the order they were made.</div></div><h4>Causal multicast</h4><div>This multicast extends the ordering property of the Atomic multicast to causally related sends from different senders while still meeting the reliability guarantee. [<a href="http://amturing.acm.org/p558-lamport.pdf">Lamport 78</a>] was the first to introduce the concept of potential causal relationships into computer interactions and showed what effects these relationships can have on the operations of interacting processes. Two events are potentially causally related if information from the first event could have reached the second event before it occurred. The notation used to denote such relationships is typically X → Y, where → means <i>precedes</i> (happened before). Note that if X and Y are events from the same process and Y follows X then Y is necessarily causally related to X. A causal communication system will only preserve an ordering of events if the order is causally related. If two events are not related in this way then there is no guarantee on the delivery order.</div><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-OGN_7PZxe6Y/WGjpzD7Z4SI/AAAAAAAABrg/s4OhSFUR-EMeAbfX-P9oeokV4AHTrkubACLcB/s1600/Screen%2BShot%2B2017-01-01%2Bat%2B11.36.24.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="250" src="https://4.bp.blogspot.com/-OGN_7PZxe6Y/WGjpzD7Z4SI/AAAAAAAABrg/s4OhSFUR-EMeAbfX-P9oeokV4AHTrkubACLcB/s640/Screen%2BShot%2B2017-01-01%2Bat%2B11.36.24.png" width="640" /></a></div><div>In the figure above S1 is multicasting the groups G 1and G2, P1is multicasting to group G1. G1={P2, P3} and G2={P1, P4}.Thereisapotentialflowofinformationfromsend(m1,Gi) to send(m2,G2), and from send(m 2,0 2) to send(m3,G1). This means that the sending of m3 by Pi is potentially causally related to the sending of m1 by S1. Hence the causal multicast&nbsp;protocol must ensure that all functioning members of G 1receive m1 before m3. Events such as m3 and m4 which are not causally related can be received in any order (they are termed <i>concurrent</i>).</div><h4>Totally ordered multicast</h4><div><div>The (partial) causal order can be extended to a total order of messages such that all messages (whether causally related or not) are received by all destinations in the same order (which must also preserve causality).</div></div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-88701580674176596942016-12-31T14:33:00.001+00:002016-12-31T14:33:59.167+00:00RPCs, groups and multicastThis is first entry in the series I <a href="http://markclittle.blogspot.co.uk/2016/12/some-historical-blogging.html">mentioned earlier</a>. I've tried to replace the references with links to the actual papers or PhD theses where possible, but some are not available online.<br /><h4>Remote Procedure Call</h4>The idea behind the Remote Procedure Call (RPC) [<a href="http://www.cs.virginia.edu/~zaher/classes/CS656/birrel.pdf">Birrell 84</a>] is the fact that conventional procedure calls are well known and are a well understood mechanism for the transfer of data and control within a program running on a single processor. When a remote procedure is invoked, the calling process is suspended, any parameters are passed across the network to the node where the server resides, and then the desired procedure is executed. When the procedure finishes, any results are passed back to the calling process, where execution resumes as if returning from a local procedure call. Thus the RPC provides the system or application programmer a level of abstraction above the underlying message stream. Instead of sending and receiving messages, the programmer invokes remote procedures and receives return values.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-_2GcAFbHRmg/WGe7i_kDaZI/AAAAAAAABq0/yQXEbO9TzXc6F6o6zPw2bugxrCPYJWjmQCLcB/s1600/Screen%2BShot%2B2016-12-31%2Bat%2B14.06.34.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="255" src="https://1.bp.blogspot.com/-_2GcAFbHRmg/WGe7i_kDaZI/AAAAAAAABq0/yQXEbO9TzXc6F6o6zPw2bugxrCPYJWjmQCLcB/s320/Screen%2BShot%2B2016-12-31%2Bat%2B14.06.34.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: left;">The figure shows a client and server interacting via a Remote Procedure Call interface. When the client makes the call it is suspended until the server has sent a reply. To prevent the sender being suspended indefinitely the call can have a timeout value associated with it: after this time limit has elapsed the call could be retried or the sender&nbsp;could decide that the receiver has failed. Another method, which does not make use of timeouts in the manner described, instead relies on the sender and receiver transmitting additional probe messages which indicate that they are alive. As long as these messages are acknowledged then the original call can continue to be processed and the sender will continue to wait.</div><h4>Groups</h4><div><div>[<a href="http://www.computerconservationsociety.org/ansa/94/Primary/100201.pdf">ANSA 90</a>][<a href="http://www.computerconservationsociety.org/ansa/92/TR020.pdf">ANSA 91a</a>][<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.469.9670&amp;rep=rep1&amp;type=pdf">Liang 90</a>][<a href="http://ieeexplore.ieee.org/document/145411/">Olsen 91</a>] describe the general role of groups in a distributed system. Groups provide a convenient and natural way to structure applications into a set of members cooperating to provide a service. They can be used as a transparent way of providing fault tolerance using replication, and also as a way of dividing up a task to exploit parallelism.</div><div><br /></div><div>A group is a composite of objects sharing common application semantics as well as the same group identifier (address). Each group is viewed as a single logical entity, without exposing its internal structure and interactions to users. If a user cannot distinguish the interaction with a group from the interaction with a single member of that group, then the group is said to be fully transparent.</div><div><br /></div><div>Objects are generally grouped together for several reasons: abstracting the common characteristics of group members and the services they provide; encapsulating the internal state and hiding interactions among group members from the clients so as to provide a uniform interface (group interface) to the external world; using groups as building blocks to construct larger system objects. A group may be composed of many objects (which may themselves be groups), but users of the group see only the single group interface. [<a href="http://www.computerconservationsociety.org/ansa/94/Primary/100201.pdf">ANSA 90</a>] refers to such a group as an Interface Group.</div><div><br /></div><div>An object group is defined to be a collection of objects which are grouped together to provide a service (the notion of an abstract component) and accessible only through the group interface. An object group is composed of one or more group members whose individual object interfaces must conform to that of the group.</div></div><div><br /></div><div><div>Interfaces are types, so that if an interfacex has typeXand an interfacey has type Y, andX conforms to Y, thenx can be used wherey is used. This type conformance criteria is similar to that in Emerald [<a href="https://pdfs.semanticscholar.org/a1a3/0ab4aa60237af33c917c07ad95efbdabd8c2.pdf">Black 86</a>]. In the rest of this thesis, we shall assume for simplicity that a given object group is composed of objects which possess identical interfaces (although their internal implementations could be different).</div><div><br /></div><div>The object group concept allows a service to be distributed transparently among a set of objects. Such a group could then be used to support replication to improve reliability of service (a replica group), or the objects could exploit parallelism by dividing tasks into parallel activities. Without the notion of the object group and the group interface through which all interactions take place, users of the group would have to implement their own protocols to ensure that interactions with the group members occur consistently e.g., to guarantee that each group member sees the same set of update requests.</div><div><br /></div><div>By examining the different ways in which groups are required by different applications, it is possible to define certain requirements which are imposed on groups and the users of groups (e.g., whether collation of results is necessary from a group used for reliability purposes). [<a href="http://www.computerconservationsociety.org/ansa/92/TR020.pdf">ANSA 9 la</a>] discusses the logical components which constitute a generic group, some of which may not be required by every group for every application. These components are:</div><div><ul><li>an arbiter, which controls the order in which messages are seen by group members.</li><li>a distributor/collator, which collates messages going out of the group, and distributes messages coming into the group.</li><li>member servers, which are the actual group members to which invocations are directed.</li></ul></div><div>For some applications collation may not be necessary e.g., if it can be guaranteed that all members of a group will always respond with the same result. As we shall see later, if the communication primitives can guarantee certain delivery properties for&nbsp;messages, then arbitration may also not be necessary. In general, all of these components constitute a group. In the rest of this thesis the logical components will not be mentioned explicitly, and the term group member will be used to mean a combination of these components.</div></div><h4>Multicast Communication</h4><div><div>Conventional RPC communication is a unicast call since it involves one—to—one interaction between a single client and a single server. However, when considering replication it is more natural to consider interactions with replica groups. Group communication is an access transparent way to communicate with the members of such a group. Such group communication is termed multicasting [<a href="https://infoscience.epfl.ch/record/55808/files/p77-cheriton.pdf?ln%3Denversion%3D1">Cheriton 85</a>][<a href="http://copac.jisc.ac.uk/id/21843529?style=html">Hughes 86</a>].</div><div><br /></div><div>Multicast communication schemes allow a client to send a message to multiple receivers simultaneously. The receivers are members of a group which the sender specifies as the destination of the message. A broadcast is the general case of a multicast whereby instead of speci!ring a subset of the receivers in the system every receiver is sent a copy.</div></div><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-12BY5yiAegA/WGe9DVvMlhI/AAAAAAAABq8/OFiSMA1u_ocFZYc8j4ucHoe-agK4xcymgCLcB/s1600/Screen%2BShot%2B2016-12-31%2Bat%2B14.13.16.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="310" src="https://2.bp.blogspot.com/-12BY5yiAegA/WGe9DVvMlhI/AAAAAAAABq8/OFiSMA1u_ocFZYc8j4ucHoe-agK4xcymgCLcB/s320/Screen%2BShot%2B2016-12-31%2Bat%2B14.13.16.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: left;">Most multicast communication mechanisms are unreliable as they do not guarantee that delivery of a given message will occur even if the receiver is functioning correctly (e.g.,&nbsp;the underlying communication medium could lose a message). When considering the interaction of client and replica group (or even replica group to replica group communication) such unreliable delivery can cause problems in maintaining consistency of state between the individual replicas, complicating the replication control protocol (if one replica fails to receive a given state-modifying request but continues to receive and respond to other requests, this resulting state divergence could result in inconsistencies at the clients). Thus, it is natural to consider such group-to-group communication to be carried out using reliable multicasts, which give certain guarantees about delivery in the presence of failures. These can include the guarantee that if a receiver is operational then the message will be delivered even if the sender fails during transmission, and that the only reason a destination will not receive a message is because that destination has failed. By using a reliable multicast communication protocol many of the problems posed by replicating services can be handled at this low level, simplifying the higher level replica consistency protocol.</div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-39807617783079296222016-12-31T14:02:00.000+00:002016-12-31T14:02:04.367+00:00Some historical bloggingOver Christmas I was doing some cleaning up of my study and came across a copy of my PhD. Any excuse to stop cleaning, so I took some time to skim through it and thought some of the background research I had included might still be useful today for a new audience. Now although the PhD is <a href="https://theses.ncl.ac.uk/">available for download</a>, it's not exactly easily searchable or referenced, so the next few entries will try to rectify some of that.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com2tag:blogger.com,1999:blog-9203557.post-5407157695248153262016-10-15T20:33:00.003+01:002016-10-15T21:41:13.598+01:00Architecture FirstWe've all heard the story of <a href="http://www.pitt.edu/~dash/type0124.html#halliwell">The Three Little Pigs</a>. We all know that building houses from straw isn't a great idea if your use case is to survive a wolf's breath. We all know that sticks aren't that much better either. Of course brick is a far better medium and the pig that built from it survived. Now what the original story doesn't say, probably because it's a little more detail than children really need to understand, is that before building their houses all of the pigs went to architecture school and studied at length about arches, the truss, stylobates and other things necessary to design and then construct buildings from various materials. Now it's likely the pig that used straw didn't listen when they were talking about the tensile strength of straw and the pig that used sticks ignored the warnings that they're really only good for building forest dens (or birds nests). But if they'd been listening as much as their brother then they'd have known to give him a hand with the bricks and not waste their time.<br /><br />Now even the best architects <a href="http://www.cracked.com/article_19682_5-most-embarrassing-architectural-failures.html">make mistakes</a>. It's not possible to suggest a single reason for these though. Sometimes it's because the architect didn't understand the physical properties of the material being used (a bit like the straw and stick pigs). Sometimes it's because they didn't fully understand the environment within which their building would reside. But fortunately for us, the vast majority of buildings are successful and we feel safe to be within them or around them.<br /><br />You may be wondering why I'm talking about architecture here. I think I've mentioned this before but my biggest worry about the rush towards microservices is the lack of focus, or discussions, around architectures. I'm sure many of the established groups that have been building systems with services (micro or not) understand their architectures and the impact service-orientation has on it, or vice versa. But I'm also convinced that many groups and individuals who are enamoured by the lustre of microservices aren't considering architectures or the implications. That worries me because, as I said at the <a href="http://www.munzandmore.com/2016/conference/quote-using-an-app-server-does-not-mean-you-build-a-monolith-mark-little">JavaOne 2016</a> presentation I gave recently, launching into developing with microservices without understanding their implications and the architecture is neither going to solve any architecture problems you may have with your existing application nor will it result in a good/efficient distributed system. In fact it's probably the worst thing you could do!<br /><br />Even if you've got "pizza teams", have a culture that has embraced DevOps, have fantastic tools supporting CI and CD, if you don't understand your current and new architecture none of this is really going to help you. That's not to suggest those things aren't important after you've done your architecture design and reviews because they clearly are. The better they are the quicker and more reliably you can build your new application using microservices and manage it afterwards. But you should never start such an effort just because you've got the right tools, building blocks and support infrastructure. It could be argued that they're necessary, but they most certainly aren't sufficient. It needs to start with architecture.<br /><br />Update: I should also have mentioned that after any architecture review you find that you don't need many, or any, microservices then you shouldn't feel a sense of failure. A good architect (software or not) knows when to use and when not to use things. Remember, it's quite probable the pig who used the bricks considered straw and sticks first but decided they just weren't right this time around.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-53154937966784634272016-09-02T15:57:00.003+01:002016-09-02T15:57:34.588+01:00Microservices and distributionOK so following on from my previous article on inferring the presence of microservices within an architecture, one possibility would be to view the network traffic. Of course it's no guarantee, but if you follow good microservices principles that are defined today, typically your services are distributed and communicating via HTTP (OK, some people say REST but as usual they tend to mean HTTP). Therefore, if you were to look at the network traffic of an "old style" application (let's not assume it has to be a monolith) and compare it with one that has been re-architected around microservices, it wouldn't be unreasonable to assume that if you saw a lot more HTTP requests flowing then microservices are being used. If the microservices are using some other form of communication, such as JMS, then you'd see something equivalent but with a binary protocol.<br /><br />We have to recognise that there are a number of reasons why the amount of network traffic may increase from one version of an application to another, so it could be the case that microservices are not being used. However, just as Rutherford did when searching for the atomic nucleus and which all good scientists follow, you come up with a theory that fits the facts and revise it when the facts change. Therefore, for simplicities sake, we'll assume that this could be a good way to infer microservices are in place if all other things remain the same, e.g., the application is released frequently, doesn't require a complete re-install/re-build of user code etc.<br /><br />Now this leads me to my next question: have you, dear reader, ever bothered to benchmark HTTP or any distributed interaction versus a purely local, IPC, interaction? I think the majority will say Yes and of those who haven't the majority will probably have a gut instinct for the results. Remote invocations are slower, sometimes by several orders of magnitude. Therefore, even ignoring the fault tolerance aspects, remote invocations between microservices are going to have a performance impact on your application. So you've got to ask: why am I doing this? Or maybe: at what point should I stop?<br /><br />Let's pause for a second and look back through the dark depths of history. Back before the later 19th Century/early 20th Century, before electrification of factories really took off, assembling a product from multiple components typically required having those components shipped in from different parts of the country or the world. It was a slow process. If something went wrong and you got a badly built component, it might prevent assembly of the entire product until a new version had been sourced.<br /><br />In the intervening years some factories stayed with this model (to this day), whereas others moved to a production factory process whereby all of the pieces were built on site. Some factories became so large, with their constituent pieces being built in their own neighbouring factories that cities grew up around them. However, the aim was that everything was built in one place so that mistakes could be rectified much more quickly. But are these factories monoliths? I'm not so sure it's clear cut simply because some of the examples I know of factories like this are in the Japanese car industry which has adapted to change and innovation extremely well over the years. I'd say these factories matured.<br /><br />Anyway, let's jump back to the present day but remembering the factory example. You could imagine that factories of the type I mentioned evolved towards their co-located strategy over years from the distributed interaction approach (manufacturers of components at different ends of the planet). They managed to evolve because at some point they had all of the right components being built but the impediment to their sales was time to market or time to react. So bringing everything closer together made sense, Once they'd co-located then maybe every now and then they needed to interact with new providers in other locations and if those became long term dependencies they probably brought them "in house" (or "in factory").<br /><br />How does this relate to microservices and the initial discussion on distributed invocations? Well whilst re-architecting around microservices might help your application evolve and be released more frequently, at some point you'll need to rev the components and application less and less. It becomes more mature and the requirements for change drop off. At that stage you'd better be asking yourself whether the overhead of separate microservices communicating via HTTP or even some binary protocol, is worth it. You'd better be asking yourself whether it's not better to just bring them all "in house" (or in process) to improve performance (and probably reliability and fault tolerance). If you get it wrong then of course you're back to square one. But if you get it right, that shouldn't mean you have built a monolith! You've just built an application which does it's job really well and doesn't need to evolve much more.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-12805996418934983092016-08-29T18:39:00.000+01:002016-08-29T18:40:46.940+01:00Microservices and subatomic particles - an end-user perspective?For a while now we've seen various debates around microservices, such as how they compare to SOA, whether the emphasis should be on size (micro), whether HTTP (and REST) is the preferred communication style, where and why you should adopt them as well as when you shouldn't? The list goes on and on and I've participated in a few of them.<br /><br />Recently at work we've been focusing on how best to consider microservices within an existing architecture, i.e., how, why and when to breakdown so-called monoliths into microservices. We've had a number of our teams involved in these discussions, including Vert.x, WildFly Swarm and OpenShift. We've made great progress and this article isn't about that work - I'll leave it to the various teams and others to report once it's ready.<br /><br />However, during this work I also went on vacation and that gave me time to ponder on life, the universe and everything microservices related! During the time away I kept coming back to two fundamental questions. The first: why use microservices? The second: how can end-users tell if they're being used to (re-) construct (distributed) applications? Much of what we've heard about microservices has been from the perspective of developers who will use microservices, not necessarily the end-user of (re-)architected applications. And of course you're probably asking a third: how does all of this relate to subatomic particles? Patience and all will be revealed.<br /><br />To answer the first question, there are a lot of reasons why people, vendors, analysts etc. suggest you should consider microservices, either as a building block for new applications or, as seems more common at the moment, as a way of refactoring your existing application or service(s) which may be monolithic in nature. At the core though is the requirement to have an architecture which allows for constituent components to be developed, revised and released independently of the entire application. The so-called "Pizza Team" approach, for instance.<br /><br />This then leads us nicely to the second question: how can you tell an application has been developed, or re-architected, using microservices? If you're a user of a service or application, chances are that unless the source code is available to review and you've got that inclination, "microservices enabled" isn't necessarily going to be one of the slogans used to market it. And in fact should you care? Ultimately what you're probably more interested in is a mixture of things such as cost, reliability, performance and suitability for purpose. But let's assume you do want to know. How can you tell?<br /><br />Well this is where the subatomic particles come in. Given my university degree majored in physics and computing I share an equal love for both and at times when my mind wanders I like to try to see similarities between the two areas. In the past, for instance, I've used Heisenberg's Uncertainty Principle to describe weak consistency transactions protocols. This time around I was again recalling Heisenberg; those of you who have also studied physics or have a passing interest will know that the wave-particle duality of subatomic particles cannot be view directly but can be inferred, for instance using Young's Slit experiment and firing a single "particle" at two slits to observe an interference pattern which is reminiscent of those produced by wave interference. This is a pretty extreme example of how we can infer the properties of particles we cannot view directly. Others exist, including Rutherford's original experiment to infer the existence of the atomic nucleus; I'll leave that as an exercise to the interested reader, but will say it's a fascinating area of science.<br /><br />Now where all of this comes full circle is that if you're an end-user of some piece of software that has been well architected and does its job, is released frequently enough for you to do your work efficiently and basically doesn't get in the way, could you tell if it was architected or re-architected using microservices? The answer in this case is most probably no. But on the flip side, suppose you've been using an application or service which is released too slowly for you (e.g., bug fixes take months to arrive), and maybe requires a rebuild of your code each time it is released. Then let's assume things change and not only do you get updates on a daily basis but they often fit seamlessly in to your own application usage. Does this mean that the developers have switched to microservices? Unfortunately the answer is no less definitive than previously because whilst a correct use of microservices would be an answer, there are other approaches which could give the same results - despite what you may have read, good software development has existed for decades.<br /><br />Therefore, without looking at the code how can an end-user know whether or not microservices are being used and why is that important? It's important because there's a lot of hype around microservices at the moment and some people are making purchasing decisions based on whether or not they are present, so you probably do need some way to confirm. Architecture diagrams are great but they're no substitute for code. But if you can't see the code, it's tricky to infer one way or the other. However, on the flip side maybe as an end-user you really shouldn't care as long as you get what you want from the application/service? Good architectures and good software architects win out in the end using a variety of techniques.<br /><br />Note: yeah, the other obvious analogy between microservices and subatomic particles could be that maybe microservices are the smallest divisible aspects of your application that make sense; you can't really re-factor your code smaller than a microservice in just the same way that you can't go beyond sub-atomic particles. However, since there are things smaller than subatomic I didn't want to go there.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-21392033407454225302016-05-21T21:22:00.002+01:002016-05-21T21:22:58.548+01:00Fault tolerance and microservices<div>A while ago I wrote about microservices and the unit of failure. At the heart of that was a premise that failures happen (yes, I know, it's a surprise!) and in some ways&nbsp;distributed systems are defined by their ability to tolerate such failures. From the moment our industry decided to venture into the area of distributed computing there has been a need to tackle the issue of what to do when failures happen. At some point I'll complete the presentation I've been working on for a while on the topic, but suffice it to say that various approaches including transactions and replication have been utilised over the years to enable systems to continue to operate in the presence of (a finite number of) failures. One aspect of the move towards more centralised (monolithic?) systems that is often overlooked, if it is even acknowledged in the first place, is the much more simplified failure model: with correct architectural consideration, related services or components fail as a unit, removing some of the "what if?" scenarios we'd have to consider otherwise.</div><div><br /></div><div>But what more has this got to do with microservices? Hopefully that's obvious: with any service-oriented approach to software development we are inherently moving further into a distributed system. We often hear about the added complexity that comes with microservices that is offset by the flexibility and agility they bring. When people discuss complexity they tend to focus on the obvious: the more component services that you have within your application the more difficult it can be to manage and evolve, without appropriate changes to the development culture. However, the distributed nature of microservices is fundamental and therefore so too is the fact that the failure models will be inherently more complex and must be considered from the start and not as some afterthought.</div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-55879439334392085612016-05-19T19:45:00.000+01:002016-05-19T19:45:01.753+01:00Serverless? Really?<div>Our industry appears to be going through a phase of giving new or not so new approaches short names which though catchy are so inaccurate as to be meaningless and possibly dangerous. These include "containerless", when containers of one sort or another are clearly present. Now we have "serverless ".</div><div><br /></div><div>Look, I absolutely get what's behind the term: cloud has made it so that developers don't need to worry about deploying databases, web severs or whatever is needed to run their application and also takes care of scaling and fault tolerance. But servers and databases and other infrastructure are still there because your application still needs them; just because you don't see them doesn't mean they're not there.</div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com1tag:blogger.com,1999:blog-9203557.post-55522298748502942832016-04-27T15:05:00.002+01:002016-04-27T15:06:10.776+01:00An update to my microservices rant ...I spent some time writing <a href="http://developers.redhat.com/blog/2016/04/27/rest-and-microservices-breaking-down-the-monolith-step-by-asynchronous-step/">something more positive</a> than my previous rant. I hope.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-39901313588708780172016-04-23T16:31:00.004+01:002016-04-23T16:31:55.368+01:00Types of microservicesI've started to post a few things over on the new Red Hat Developer Blog. My first entry was about <a href="http://developers.redhat.com/blog/2016/04/19/different-types-of-microservices/">microservices</a>.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-57662312613716755182016-04-21T15:11:00.000+01:002016-05-05T16:46:09.112+01:00You keep using that word (REST) and I don't think it means what you think it does<div style="background-color: white;"><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">A long time ago in a galaxy far, far away ... OK, not quite. But some time ago our industry spent a lot of time and effort on discussion the pros and cons of REST, SOA, SOAP (!) etc. I even had a few things to say on the subject myself. To misquote Jeff Wayne, "minds immeasurably superior to my own" on the topic of REST and HTTP at the time had a lot more to say and do in this area. It's something which is easily Googled these days. Covered in books too. Probably even several video master classes on the topic of REST and HTTP, let alone their relevance to SOA. And yet it seems that some people either have a very short memory, didn't understand what was said, or perhaps didn't do their homework?</span><br /><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;"><br /></span><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">I'm specifically talking about how REST plays into the recent microservices wave. Yes, I think there are some problem areas with microservices and yes, one of them is the dogmatic assertion by some that REST (they tend to really mean HTTP) is mandatory. I don't believe that. I do believe that different message exchange patterns may be suitable for a range of microservices and to limit ourselves to just one (HTTP) does not make sense.</span><br /><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;"><br /></span><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">Oh and yes, it still frustrates me to this day when people talk about REST and they're really talking about HTTP - my only consolation here is that if I find it frustrating it must really annoy the h*ll out of the RESTafarians! Not all REST is HTTP and likewise not everything which uses HTTP is necessarily REST. Simple, huh? Well you'd think ...</span><br /><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;"><br /></span><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">Anyway, putting that aside, what's got me more frustrated recently is that some people are suggesting that REST (really HTTP) can't do async for microservices and therefore can prevent you breaking apart your monolith. I'm not even going to attempt to explain in detail here how that is wrong except to suggest that a) those people should go and read some InfoQ articles from the early 2000's (yes, even theserverside had things to say on the topic), b) do a Google search, c) read something from my friend/colleague <a href="https://www.amazon.co.uk/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829?ie=UTF8&amp;*Version*=1&amp;*entries*=0">Jim Webber</a>,&nbsp;<a href="http://savas.me/">Savas</a> and others on the topic of REST (and maybe Restbucks - hint, hint), d) in case they're confused between REST and HTTP, maybe go and read the HTTP response codes and look at those in the early 200's range (again, another hint). As I said above, I'm not suggesting there aren't some issues with REST/HTTP for microservices. And as I've also said over the last decade or so, maybe there are some issues with building some types of distributed systems with REST/HTTP. But this isn't one of them!</span><br /><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;"><br /></span><a data-mce-href="https://rhdevelopers.files.wordpress.com/2016/04/unknown.jpeg" href="https://rhdevelopers.files.wordpress.com/2016/04/unknown.jpeg" style="font-family: Georgia, 'Times New Roman', 'Bitstream Charter', Times, serif; font-size: 16px;"><img alt="Unknown" class="size-medium wp-image-421396 aligncenter" data-mce-selected="1" data-mce-src="https://rhdevelopers.files.wordpress.com/2016/04/unknown.jpeg?w=300" src="https://rhdevelopers.files.wordpress.com/2016/04/unknown.jpeg?w=300" style="display: block; height: auto; margin-left: auto; margin-right: auto; max-width: 100%; outline: rgb(114, 119, 124) solid 1px; resize: none;" /></a><br /><div><br /></div><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">And this then brings me to a related topic. And if he hadn't been saying it around REST, I'm pretty sure <a href="http://www.imdb.com/title/tt0093779/">Inigo Montoya</a> would've been saying "You keep using that word. I do not think it means what you think it means" about "asynchronous". Yes, some of the authors try to make the distinction between a blocking call within a single address space and a one way interaction with a service across the network, but that really doesn't instil me with confidence that they know what they're talking about. If they threw in a bit of Fischer, Lynch and Patterson, rather than the oft overused reference to CAP, then maybe I'd be slightly less concerned. But that'd require some homework again, which they don't appear to want to do! Oh well, good luck to those who follow them!</span><br /><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;"><br /></span><span style="color: #333333; font-family: &quot;georgia&quot; , &quot;times new roman&quot; , &quot;bitstream charter&quot; , &quot;times&quot; , serif;">Note, I have deliberately not included many links to things in the post in the hopes it will encourage the reader to follow up.</span></div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com6tag:blogger.com,1999:blog-9203557.post-71037267441642622852016-04-06T20:57:00.002+01:002016-04-06T20:57:33.167+01:00Micromonoliths?I'm not even sure it's a word, but I wrote something on <a href="https://developer.jboss.org/blogs/mark.little/2016/04/06/monoliths-and-micromonoliths">micromonoliths</a> elsewhere - basically just some words on architecture.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-78168688765369095462016-04-06T19:38:00.002+01:002016-04-06T19:38:56.267+01:00Some cross postings on microservicesAs I mentioned earlier, I've had some time on holiday recently and spent some time musing on microservices amongst other things. I've written a couple of articles over on my <a href="https://developer.jboss.org/blogs/mark.little">JBoss.org blog</a>, one on <a href="https://developer.jboss.org/blogs/mark.little/2016/04/04/when-is-a-microservice-not-a-microservice">microservices and co-location</a>, and one about the <a href="https://developer.jboss.org/blogs/mark.little/2016/04/04/microservices-and-distributed-systems">mad rush to make everything a microservice</a>. As <a href="http://www.imdb.com/title/tt0297727/">Rod Serling</a> often said: submitted for your approval. Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-9930859607263149352016-04-04T15:50:00.000+01:002016-04-04T15:50:26.487+01:00Poor scientific methodOne of the nice things about being on holiday is that the mind can wander down paths that might otherwise not be trodden, particularly because to do so typically needs more available time. This holiday I spent some of that time pondering microservices, amongst other things. As I've mentioned and been quoted elsewhere, I'm not against the fundamental concepts behind microservices architectures (MSA) - I see them as embodying an evolution of services-based architectures which we've seen happening over several decades. And yet I have a few concerns or niggles about the way in which some groups are positioning it as so significantly different that it represents a fundamental new approach or wave.<br /><br />It wasn't until I read the recent <a href="http://csrc.nist.gov/publications/drafts/800-180/sp800-180_draft.pdf">NIST document</a> that I managed to put my finger on at least one of these concerns: they're making data fit their own definitions of SOA and MSA, whilst conveniently ignoring those facts which don't fit. Any good scientist knows that goes against scientific method, whereby we come up with a theory based upon all of the available data and that theory lasts until some new data appears which blows a hole in it (yes, I'm paraphrasing). The NIST document is particularly guilty of this by choosing a definition of SOA which is conveniently at odds with their definition of MSA - it's not even the one that the standards, such as the <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm">OASIS SOA Reference Model</a>, define! The table they have to compare and contrast is so badly flawed - go read the SOA-RM and look at the NIST MSA definition to see how close SOA and MSA are!<br /><br />Look, I'm not suggesting there's nothing different in MSA than what we've been doing in the past with service oriented architectures. But let's please be objective, stick to the facts and define theories or models based upon all of the available data. Then also be prepared to change if new data appears. But please don't select data to match your own preconceived notions. In our more fully connected world there's really no excuse for being selective of the available data or ignorant of what is available!Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-25486508783284055332016-04-03T15:49:00.001+01:002016-04-03T15:49:19.550+01:00Holiday thoughts ...I just got back from a week of holidaying with family in Tenerife. We did lots of great things together, such as whale watching, snorkeling, visiting the local volcano (great mountain roads with barely enough space for one car let alone two lanes!) and generally soaking up the sunshine! It also gave me an opportunity to catch up on some articles and work related videos I'd been saving up on for a while, which resulted in me also being able to write down some of my own thoughts on a few related areas. I'm taking a bit of a down-day today before back to work tomorrow so it may take me a few days to upload the entries here or to my JBoss.org account.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-35472474178625285972016-01-26T16:57:00.000+00:002016-01-26T16:57:01.095+00:00Frameworks versus stacks - cross postingWasn't really sure if I should put this on my JBoss.org blog or here, so <a href="https://developer.jboss.org/blogs/mark.little/2016/01/26/frameworks-versus-stacks">cross posting</a>.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-55317358642698617432016-01-24T15:03:00.003+00:002016-01-24T15:03:53.148+00:00SRC-IoT 2016I have had the honour of working with <a href="http://www.ncl.ac.uk/computing/people/profile/paul.watson">Professor Paul Watson</a> to create the System Research Challenges Workshop. For the first year we focussed on IoT and it's possible we may keep that high-level theme next time. But it really great to see and hear the attendees embrace the underlying issues which are presented by large-scale distributed systems, which IoT embodies: reliability, fault tolerance, security, trustworthiness, data management etc. Of course all of the presentations had an IoT focus, but even there we had a wide range of examples, from field devices through gateways and including wearables (yes, there were a lot of side discussions about whether some of these IoT devices would ever really take off.)<br /><div><br /></div><div>We had attendees from industry (e.g., Red Hat, IBM and ARM) as well as SMEs and arcademia (e.g., Newcastle University, Lyon and Cambridge). It was a great mix of practical and theoretical, highlighting some of the challenges we have ahead of us in research and development. And as with many of these kinds of events, it was the discussions around the sessions that generated as much interesting conversation as during the presentations.</div><div><br /></div><div>As well as 2 days of 30 minute presentations (maybe we'll try and get the agenda published somewhere), we also held a 2 hour lightning talk session on the first evening. Here anyone attending, whether they had a formal presentation or not during the event, was encouraged to present on a topic for 5 minutes. There hadn't been much preparation for this beforehand, so there was a little concern about whether we'd be able to fill the time. We needn't have worried - we could have gone much longer than the allotted 2 hours. It was a lot of fun. In fact my favourite talk of the entire event was probably here when Jonathan Halliday gave a presentation onf Big Data over the centuries, going back hundreds of years and managing to also touch on open source 400 years ago!</div><div><br /></div><div>In conclusion, I thought the event went well. I'm hoping we can do it again next year, perhaps with the same theme or maybe we need to change it. We'll know closer to the time.</div>Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-69899017186571178462016-01-01T09:23:00.002+00:002016-01-01T09:23:21.365+00:00EliteBack when I was just starting at university <a href="https://en.wikipedia.org/wiki/Elite_(video_game)">Elite</a> came out for the Beeb. I remember going into my local town and walking to the computer shop to buy the game, then getting the slow bus home, waiting with apprehension for the time when I could put the tape into the cassette drive and slowly load up the game! By today's standards the graphics were basic, but in 1984 they were ground breaking. And I spent the next couple of years playing Elite at every opportunity. Even when I upgraded to the <a href="https://en.wikipedia.org/wiki/Atari_ST">Atari 520 STM</a> I longed for Elite on it but it never arrived.<br /><br />I learned about <a href="https://www.elitedangerous.com/">Elite Dangerous</a> back in 2012 and that it was available on Steam earlier this year. I wasn't a Steam player at the time, preferring to do my gaming on a PlayStation 3 or 4, or perhaps an XBox 360. However, I made the plunge this morning and for my first game purchase of 2016 I decided to install Steam on my laptop and buy Elite. I'm sure I'll have hours of fun ahead if it's anything like the original game!Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-81571854094025309442015-11-09T21:10:00.002+00:002015-11-09T21:19:28.448+00:00HPTS 2015I've been so busy travelling to conferences and customer engagements that I haven't had a chance to write about my trip to <a href="http://www.hpts.ws/">HPTS 2015</a>. I've written <a href="http://markclittle.blogspot.co.uk/2013/10/hpts-2013.html">several times</a> about <a href="http://markclittle.blogspot.co.uk/2011/01/hpts-2011.html">previous trips</a> to this workshop and how it's <a href="http://markclittle.blogspot.co.uk/2005/09/on-road-to-hpts.html">my favourite</a> of them all, so won't repeat. The workshop had the usual <a href="http://www.hpts.ws/agenda.html">high standard</a> of presentations and locating it at <a href="http://www.visitasilomar.com/">Asilomar</a> is always a great way to focus the mind and conversations.<br /><br />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 <a href="http://markclittle.blogspot.co.uk/2015/02/container-less-development.html">evolution of application servers</a> (application containers) <a href="http://markclittle.blogspot.co.uk/2015/03/more-thoughts-on-container-less.html">driven by immutability and operating system containers</a>, such as Docker. And I threw in a smattering of <a href="http://markclittle.blogspot.co.uk/2015/02/microservices.html">microservices</a> since the topic is obviously <a href="http://markclittle.blogspot.co.uk/2015/04/containerless-microservices.html">relevant</a> and I figured <a href="http://www.hpts.ws/pc.html">Adrian</a> would be there! My <a href="http://www.hpts.ws/papers/2015/little.pdf">presentation</a> was well received and the feedback clearly showed that many people at the event agreed with it.<br /><br />One other positive thing to come from the workshop and my presentation was that my co-traveller and long time friend/colleague, <a href="http://www.ncl.ac.uk/computing/people/profile/santosh.shrivastava">Professor Shrivastava</a>, 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 <a href="http://www.ncl.ac.uk/computing/people/profile/mark.little#tab_publications">very fruitful collaboration</a> over the years, so I look forward to this!<br /><br />I also want to thank <a href="https://medium.com/fabric8-io/the-decline-of-java-application-servers-when-using-docker-containers-edbe032e1f30">James</a> 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.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-4414553585639782482015-11-09T20:47:00.000+00:002015-11-09T20:47:17.081+00:00High Integrity Software 2015 conferenceI was asked to give one of the keynotes at this year's <a href="http://his-2015.co.uk/">High Integrity Software Conference</a> 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.<br /><br />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 <a href="http://his-2015.co.uk/session/mark-little">presentation is now available</a> 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.<br /><br />Finally there was one presentation that stuck in my mind. It was by Professor Philip Koopman and <a href="http://his-2015.co.uk/session/study-of-toyota-unintended-acceleration-and-software-safety">worth reading</a>. There's a <a href="https://mediatech-stream.andrew.cmu.edu/Mediasite/Play/7c2451b6ec764be4bee295095a642c691d?catalog=35969fb7-4f63-4ebb-85d2-5b5a17a3b979">video</a> 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.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-40975097837192680982015-09-22T09:04:00.002+01:002015-09-22T09:04:40.850+01:00Heisenberg's back!A long time ago (longer than I care to remember), <a href="http://www.jboss.org/dms/jbosstm/resources/presentations/DOA2007KeyNote.pdf">I made the analogy</a> between Heisenberg's Uncertainty Principle and large-scale data consistency (weak/eventual consistency). It got <a href="http://www.infoq.com/news/2008/01/dev-tx-coordination-logic">reported by InfoQ</a> too. Over the weekend <a href="http://www.cidrdb.org/cidr2015/Papers/18_Abstract73HP.pdf">I came across a paper</a> 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" ;) ?Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0tag:blogger.com,1999:blog-9203557.post-21438482290867423582015-09-10T04:26:00.000+01:002015-09-10T04:26:38.697+01:00The modern production stackOver a year ago <a href="http://markclittle.blogspot.com/2014/04/the-future-adaptive-middleware-platform.html">I wrote the first</a> 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, <a href="https://twitter.com/jstrachan">thanks to James</a> I got to see a nice article called <a href="http://www.eightypercent.net/post/layers-in-the-stack.html">Anatomy of a Modern Production Stack</a>, 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 <a href="http://fabric8.io/">Fabric8</a>, OpenShift etc.Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.com0