Thursday, 21 April 2016

Reuse

I remember when code reuse first became a buzzword, back in the day.  "Code duplication is bad!" they cried. "A maintenance burden! Error prone!  Write code once, reuse, and everybody wins!"

But imagine you embraced this mantra.  You have a number of clients reusing your very useful code, some in your team, some not in your team, and perhaps some you don't even know about… You want to make a change.  How do you not break client code?

You turn your very useful code into a library or perhaps even a service (*waves dusty SOA banner), with well-defined interface contracts, usage guides and a versioning policy. And you start to keep track of your clients.  And of course, you want to write tests.  But since clients will reuse your code in surprising ways, you write more tests, for scenarios you haven't imagined (with your crystal ball).

And all is good for a while.

Then client N+1 comes along and wants to change the common interface for legitimate reasons – change is to be expected and even embraced, right?  Luckily we used XML or JSON (or both), so we have some extensibility.  But no, the client is not satisfied.  The change is more significant. The business is moving. We are agile. We need to change the interface fundamentally.

So we do, and we version it.  We notify all our clients that there is a new version, and that version 1 is deprecated. They have 6 months to upgrade.

But some are too busy to do that, and we end up with two versions.

Or perhaps we decided the client's requirement is unique, so we write a special purpose adapter.  We end up with two interfaces. Somewhere, a developer's soul dies.

Unless very carefully managed, shared code quickly becomes code nobody wants to touch.  This is a very bad smell. Changes will be made around the edges, and a monster will be created. Nobody will want to own this code.

The reuse of code may ironically become its own demise.



Tuesday, 24 March 2015

Microservices: New spin, old hat?


This year's QCon 2015 conference in London was abuzz with talk of microservices, and if you, like me, have seen protocols and standards like CORBA, RMI, J(2)EE and SOAP come (and go), you would be forgiven for sighing and thinking "what's new"?  However, it seems that Google, Amazon, eBay and others would beg to differ.

In a nutshell, microservices:
  • Are small (they fit in your head)
  • Run in their own process
  • Are independently replaceable, upgradeable and deployable via automated/test deployment mechanisms
  • Are backwardly (and forwardly) compatible
  • Communicate with each other via lightweight mechanisms, typically an HTTP resource API
  • Are organised around business capabilities.  "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvyn Conway, 1967
  • Involve products, not projects
  • Require decentralised governance
  • Require decentralised data management (independent persistence)
  • Automate their infrastructure (e.g. AWS)
  • Are designed for failure of dependent services
  • Prefer asynchronous calls to synchronous ones
  • Involve evolutionary design
  • Are fully developed, owned and supported by single teams
  • Compete with each other in a market-place
Much of this will be familiar, but what is new and very interesting is the degree to which microservices apply the familiar principles of loosely-coupled, encapsulated software components to the organisation developing and managing those components.

Traditionally structured companies will balk at all of this, and perhaps dismiss this as yet another architectural fad, but I'm not so sure.  Check out these two excellent videos on Spotify's Engineering Culture.








Further reading: