Category Archives: Architecture

Are Microservices Just SOA Done Right?

Architecture, Microservices, SOA

Having based previous solution designs on SOA what will Architects need to do differently when adopting the Microservices approach? I thought I would look how the definitions of the two approaches match up. The first problem was there are plenty of definitions of each, so I have chosen to the definitions from a couple of the most well regarded publications: SOA Design Patterns (Erl 2008) and Building Microservices (Newman 2015). The following diagram illustrates how they align:

I looked at each of the Microservice principles to see if I could trace them back to a characteristic of SOA

Model Around Business Concepts is a straightforward match to the SOA characteristic of being Business Driven.

Independently Deployable services are a practical requirement for having an Enterprise Centric services architecture. If services were not independently deployable then service consumers would soon become frustrated at the need to co-ordinate changes. This is also true for services which depend on one another, the need to coordinate changes soon brings back the problems of monolithic designs, for example the scope of testing.

Hide Internal Implementation Details is not explicitly stated in Erl’s SOA characteristics but is a very central concept in many other definitions. If implementation details are not hidden consumers may be tempted to go directly to source, which defeats the value of having explicit service interfaces and, at its most extreme, would start coupling consumers to a specific vendor implementation, therefore no longer being Vendor Neutral.

Isolate Failure is a key requirement for a Composition Centric architecture because as more independent services are involved it becomes harder to guarantee they will all be available and operating correctly.

That leaves three Microservices principles that don’t, at least in some way, obviously tie back to Erl’s SOA characteristics.

Decentralise All Things, in its architectural meaning, suggests avoiding ESB and Orchestrations that may place too much business logic centrally. The need for such mechanisms is not a requirement of SOA but they are often discussed in SOA books and have, in my opinion, become associated with SOA architectures.

Adopt A Culture Of Automation although a good objective for an organisation wanting to be agile is, I would argue, not an architectural matter.

Again being Highly Observable is more of a feature related to implementation than it is an architectural design. That being said messages flows are highly observable and, whilst messaging is not required to be Service Oriented, this is how most services are consumed.

In conclusion I do think Microservices are a good extension of SOA but that the extension is more about the ecosystem around building and deploying services, rather than the resulting architecture. The most fundamental takeaway, for me, is the argument, or caution, against over-using ESBs or Orchestrations.

As always a good view from Martin Fowler.

Email, RSS Follow

Dilemma of Choice

Architecture

2013.12.29 [IMG_1129]

One reason I’m a fan of cloud computing, and in particular Platform as a Service (Paas), is that it restricts the design choices available when creating or integrating solutions. Of course choice is great but it can become a problem when there are too many options and no clear way to choose between them. How many times have you seen a project stuck in analysis paralysis? Enter the Architect…

Firstly, at the Enterprise level (and enterprise could refer to an entire organisation or an organisational division depending on structure and business model), there need to be some clear guidelines and technology selections. Exactly what these are will depend on what’s important to the organisation. Architecture principles translate what’s important to the organisation into guidance that can be applied to technology selection and solution designs. They will have the effect of restricting the number of choices available. Examples of restrictions include:

  • High-level architectures: Monolithic, Layered, Service Oriented, Event Driven, etc.
  • Data that must be common/shared (master data)
  • Integration patterns (point-to-point, brokered, pub-sub, etc.)
  • Availability targets, disaster recovery
  • Security standards
  • Data protection (e.g. how does the Patriot act impact ability to use cloud providers)
  • Technology vendors
  • Consultancies
  • Individual technology components like OS, Database, Middleware, Web
  • Hosting: internal, virtualised, external
  • Existing solutions/applications that will not be replaced
  • Upgrade frequency (incremental or wait until support is ending)

I’d like to re-emphasis that, at the enterprise level, principles should only reflect the most important guidance and will lead to some restrictions in the list above. There will also be commercial considerations that bring restrictions, most probably due to enterprise-wide deals with vendors like Microsoft, Oracle and IBM to volume licence a range of products.

If the Enterprise Architecture job has been done well a reasonable number of choices will already have been made but there will usually be some still to make, for example:

  • Do we make use of new features in the framework, database, server, etc.?
  • Which library do we use for feature x? This is more of an issue for open source where multiple implementations are available as opposed to frameworks like .NET
  • We could do this in compliance with the Enterprise Architecture but don’t have time and there is a non-compliant alternative
  • This is a completely new requirement, where do we start?

I would suggest that if it’s taking a long time to choose between alternatives it is either because:

  • The Enterprise-level guidance is not clear in this respect, in which case the Enterprise architect needs to be involved in order to clarify and update the existing guidanceor
  • There isn’t a great deal to choose between the alternatives and there is deliberately no directive from the Enterprise level in this area (the project team is free to choose). My suggestion is to pick one or two, and try to develop a part of the most complex or disputed functionality (a spike test). The spike test needs to be quick, no more than a day or two: if it works stick with it and resist trying every alternative. In my experience it’s better to move a project forward even if some of the choices are later found to be suboptimal.
Email, RSS Follow

Architects Don’t Code?

Architecture

2013.12.29 [IMG_1121]

A while ago I went for to a job interview and was somewhat surprised by the interviewer getting rather over-excited about architects writing code, “I don’t EVER want to see an architect coding” was their view. “Not even to better understand a problem?” I asked, “No, NEVER”. I’m not entirely sure what the issue at that organisation was but it has made me consider what the difference between the architecture and development roles is.

Starting at the beginning (Frederick P. Brooks Jr.’s Mythical Man Month): the Architect is concerned with the Conceptual Integrity of a system/solution, i.e. that it makes sense overall regardless of how each part is implemented. The architect must also be able to suggest a way of implementing anything they specify but be able to accept any other way that meets the objective (otherwise how do you know if you’re being fleeced?).

When Brooks was writing there were far fewer layers of abstraction in IT. Today there are many more: from Conceptual Designs, Functional Specifications, High-level Languages to Machine Code, Microcode and CPU logic gates. Each of these has their own ‘Architect’ who leaves most of the implementation to the specialists at the next lower abstraction layer until you get to the transistors. For my purpose I’m considering the roles of Enterprise, Solution and Data architects who tend to be found in medium to large organisations.

So what differentiates Enterprise, Solution and Data Architects from Developers? In my opinion its ambiguity: the input and output of the architects is ambiguous. The outputs from Developers (code) are definitely not ambiguous. I have bored many mangers by repeatedly explaining that any specification written in prose (English) is going to be ambiguous (so deal with it and stop wasting time); if it were not ambiguous it could be compiled. I’ve not seen any commercially available compilers that take in a word document and output a fully functional system. The input to a developer could be unambiguous if an awful lot of time has been put into the specification but generally some degree of ambiguity remains.

In my view what makes an Architect is the ability to deal with a great deal of ambiguity, both in their inputs and their outputs (not knowing exactly how a feature is to be implemented). Developers also have to deal with ambiguity but at least one side of their work (code) is unambiguous. Should Architects code? Yes, but not production code, developers are the coding experts.

For some other views…

http://c2.com/cgi/wiki?ArchitectsDontCode

http://opensourcecto.blogspot.co.uk/2007/05/should-architects-code.html

http://softwarearchitecturezen.blogspot.co.uk/2012/11/architects-dont-code.html

http://it.toolbox.com/blogs/madgreek/should-enterprise-architects-code-16783

http://www.infoq.com/news/Should-Architects-Code

Email, RSS Follow