Microservices

Are microservices another fad or a serious architectural approach? As is frequently the case, it depends where you are starting from. I am reminded of the American driving through the lanes in Dorset (high hedges and few road signs) meeting a local and asking for directions to Dorchester. “Ooh arrr sir, if I were you I wouldn’t  want to be starting from ere”.

Microservices are essentially a fine grain SOA model, the perceived benefit being that they are self-contained and can be deployed independently. Or, from an object oriented perspective they are encapsulation taken to an extreme where all the code needed to deploy (DevOps) and monitor them are included in the microservice. So, are they just another fad or a serious architectural approach? The answer in short is – approach microservices with extreme caution.

My blogs are written from the perspective of a Chief Architect/CTO who has to take a wide view not only of the software development process but of the software development and support operation. This has got me into arguments with people who claim that Agile development does not need either an architectural approach or any form of pre-analysis. I reject that view, certainly for anything that is more than a mickey-mouse scale.

In most software development organisations you have a range of technologies and people skills. My preferred development approach has always been Agile – I first became aware of it with Lisp Machines (see footnote) but I am pragmatic and some software is best developed with a Waterfall approach. Not essential, but highly recommended as part of an Agile development is the use of continuous integration/continuous development – or DevOps as it has become known. Lots of organisations are struggling to adopt Agile, the three main reasons being process, skills and organisation.

Process because (certainly in the UK) project management systems that have been adopted – PRINCE2 are essentially waterfall. Waterfall and Agile can be married but organisations need re-orientation to understand how. Many organisations are looking to move to Agile but they don’t really know how to do it and in particular how to scale it and integrate it with their existing development process.

Skills, because most of the software that has been (is being) adopted by the Agile community are also new. That is not strictly true, they may be perceived to be new skills but the reality is that they are derivations/updates of existing skills. This is especially true of computer languages – Scala is a derivation of Java (a 20 years old object oriented language) – although I see the main advantage of using it is that it marries OO and functional programming (e.g. Lisp) well. Lisp dates from the 1960s.

As an aside, I really like Scala and it is suitable for programming the “difficult bits” (Slartibartfast code). Much of this type of code is not really suitable for Agile development as it involves complex algorithms that have to be re-implemented from legacy applications. Identifying what is best done “not Agile” is part of Analysis and Chunking

Organisation is problematical because microservices  don’t just impact process, there are organisation implications, many support organisations are built around the concept of development delivering an application and, once it has gone through a “acceptance test”, handing it over to a support team who then take it on and maintain it.

It should not be too difficult to update development skills to utilise microservices, provided that the development team already has a strong technical base. The problem lies when an organisation is still struggling to adopt Agile and DevOps. Both of these skills are in short supply and the support tools are still maturing. That in turn means that adopting micro services at scale is difficult and is dependent on first getting proficient at Agile and DevOps.

That doesn’t mean that microservices should not be trialled, just that in most cases a measured approach is required – you probably won’t have the resources to build significant applications using them, the most sensible approach is to pick a service that is used a lot (since microservices are the ultimate re-usable code) and experiment with that, paying particular attention to code quality. What is your starting point?

Carnegie-Mellon held up Level 5 CMMi software development maturity as a good thing. It is pretty essential if you are developing mission-critical code e.g.for space craft or fly-by-wire aircraft but less important in commercial organisations where without taking some risk, competitors will outpace you.

Few organisations have the luxury of having a team of talented developers spending time researching new techniques and building development teams skills is a two-edged sword, there is always the risk that having learnt new skills they will move on. In my experience this is the wrong approach; invest in your best people to get a low staff turnover which is a good thing.

The organisational problem requires a re-think about how operational support is undertaken. The best people to maintain code are usually the people who developed it. However, they are not always keen to support their code, their mindset is often a bit prima donna-ish “we want to be developing new applications”. Again this is where a pragmatic architectural view is needed. One of the trumpeted advantages of microservices is that they are self-contained (which they should be) and that they are independent of their technological implementation.

Whilst, this could be called “a good thing”, in reality, running a software development operation is much more difficult if there are a multiplicity of technologies used. Developers skilled in .NET and C# do not easily convert to Scala and JVM, and vice-versa. The more technologies that you have in your software development operation the more difficult it is to move people around and have a flexible team. This is a strong argument for architectural coherence – choose a core technology and sticking to it.

As the computer industry matures, this has become easier. Oracle acquired Sun (Java), BEA  (WebLogic J2EE) and Microsoft has stuck with .NET. IBM is also in the Java/ J2EE camp with WebSphere and SAP – well if anyone ever tells me they are doing an Agile SAP project they will see me rolling on the floor with laughter.

For an excellent exposition on Microservices see Freiheit’s Stefan Richter’s talk

______________________

Footnote – In 1984 I met Richard Stallman who was helping build a Lisp Machine at Racal-Norsk in England. Lisp Machines such as the LMI and Symbolics had come out of MIT, essentially single user computers (US$100k each) and were mainly being used for AI work. They had a code-edit-run-test-debug cycle that was easily 25-50 times more productive than conventional development at the time (the metric software houses then used was 2k LOC p.a per developer). Richard (without knowing it) inspired me found The Vanilla Flavor Company.

 

Advertisements

3 Comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s