Apparently there’s this new distributed architecture thing called microservices out and about – so last week I went ahead and read Martin Fowler’s & James Lewis’s extensive article on the subject . and my reaction to this was basically:
I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant – re http://t.co/gvhxDfDWLG
— Arnon Rotem-Gal-Oz (@arnonrgo) March 16, 2014
Similar arguments (nothing new here) were also expressed after Martin’s tweet of his article e.g. Clemens Vasters’ comment:
@martinfowler @boicy but these are the very principles of SOA before vendors does pushed the hub in the middle, i.e. ESB — Clemens Vasters (@clemensv) March 16, 2014
Or Steve Jones’ post “Microservices is SOA, for those who know what SOA is.”
Autonomy, smart endpoints, events etc. that the article talks about are all SOA concepts – If … Read More »
It has been few months since SOA Patterns was published and so far the book sold somewhere between 2K-3K copies which I guess is not bad for an unknown author – so first off, thanks to all of you who bought a copy (by the way, if you found the book useful I’d be grateful if you could also rate it on Amazon so that others would know about it too)
I know at least a few of you actually read the book as from time to time I get questions about it :). Not all the questions are interesting to “the general public” but some are. One interesting question I got is about the so called “Canonical schema pattern“. I have a post in the making (for too long now,sorry about that Bill) that explains why I don’t consider it … Read More »
I was poking around my old blog (rgoarchitects.com) and I found this post from 2007 which I think is worth re-iterating:
In a post called “Ignorance vs. Negligence“, Ayende blows some steam off on some of the so called “professionals” that he met along the way. You know …those with a fancy title that don’t know jack and design some of the nightmares we see from time to time. I’ve seen this phenomena in a lot of projects I consulted/reviewed:
The senior security expert who recommended something which isn’t supported by the platform
The senior architect who throw the system down to hell by basing all the system on a clunky asynchronous solutions that should only be used by a tiny portion of the application.
The geniuses that built this wonderful code generator that generated code with so many dependencies and singletons that made … Read More »
I recently answered this question in Stackoverflow :
What is an utility tree and what is it’s purpose in case of Architecture tradeoff analysis method(ATAM)?
I did answer the question there but here’s a better explanation with lots of examples base on the initial version for chapter 1 of SOA Patterns (which didn’t make it into the final version of the book).
There are two types of requirements for software projects: functional and non-functional requirements. Functional requirements are the requirements for what the solution must do (which are usually expressed as use cases or stories). The functional requirements are what the users (or systems) that interact with the system do with the system (fill in an order, update customer details, authorize a loan etc.).
Non-Functional requirements are attributes the system is expected to have or manifest. These usually include requirements in areas such as performance, … Read More »
I got a few request for a PDF version of the pattern so here it is : Composite Frontend Pattern
(This is part seven of a series. You might want to check the previous parts first)
Parallel and Simplification are the yin and yang of architecture evolution. Simplification, as mentioned previously, is about having foresight and thus provides for,relatively, easy evolution (i.e. architectural additions and not changes). Parallel is about reacting to changes in requirements as they come (no foresight) and making architectural changes.
But wait, architectural changes are hard by definition* – if we make a change to the architecture a lot of things are going to break – starting with the build (or the continuous deployment if you have one) and things will just deteriorate from there. An architectural change will take, relatively, a lot of time and there are a lot of risks in trying to put everything back together. Which is exactly why we need “parallel”.
As the name … Read More »
“Liskov Substitution Principle” or LSP is one of the basic principles for proper object orientation. LSP definition is:
“Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.”
In plain english that means that if CloudPageBlob inherits from CloudBlob and CloudBlob.UpdateText(someText) works CloudPageBlob.UpdateText(someText) should also work and not throw and exception… (or alternatively CloudPageBlob shouldn’t inherit from CloudBlob)
Hear that Microsoft?
Illustration by Benjipie
Mixins are a good way to weave functionality into a class. Wikipedia defines Mixin as follows
“In object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited by a subclass, while not meant for instantiation (the generation of objects of that class). Inheriting from a mixin is not a form of specialization but is rather a means of collecting functionality. A class may inherit most or all of its functionality from one or more mixins through multiple inheritance.”
Nice languages have mixins as part of the language spec. Ruby, for example, supports mixins through the notion of Modules , a way to group in related methods (and classes and constants) which is not a class in itself . You can program a bit of logic that interacts with the class it is hosted in, effectively letting … Read More »
[Edited: added explanation of the difference between upfront design with iterative implementation and Simplification]
The previous installment in the series talked about leaps as a technique to change the architecture. Leaps are more of a revolution than an evolution and even though they are sometimes needed evolving an architecture is the more interesting topic. This and the next post deal with the two types of evolution strategies Simplification and Parallel. In Part IV I provided the following definition for Simplification (where the base definition is Kent Beck’s and the projection on software architecture is mine):
Simplification – is when you don’t know what you want to do and it is too expansive to directly get to an end result. This is the basis of the iterative system. start small and gradually add features as you go. From an architecture perspective it is … Read More »
It all starts with a business requirement – as it always should. We have an ordering system (say the same one from the Knot anti-pattern) and the business says they only want to confirm an order to the user if the item is already secured for that order in the stock. From the technical point of view we have 2 separate services – one handles orders the other handles the stock – now what?
Figure 10.1 A vanilla ordering scenario. An Ordering service needs to confirm item in stock before confirming order for customer.
This sounds like a text book case for using transactions but in reality it isn’t. I am going to explain why in a short while but before we go there let’s do a (very) short recap on transactions and distributed transactions.
Transactions basically build on four basic tenets: … Read More »