Mention cloud, mention DevOps and it won’t be long before microservices enters the discussion.
But what is, or are, microservices? The name implies something small – but what? Is it a part of a bigger thing or a piece of discrete functionality? And how are microservices different to application components? And why should we care?
An application component is a small part of an application, obviously. It is a function, a sub-element, sometimes an extension or a plug-in extra, but sometimes a more fundamental core "thing" that exists as a feature of what a bigger application does.
In Microsoft Word, a component might be the spellchecker. In Adobe InDesign, a component might be the section of code that looks after colour controls.
When we look at how components fit into the total realm of software application programming and engineering – a software "system" is divided into components ... and these are then in turn made up of modules. So a module is smaller than a component, but not the same as a microservice. Stay with me please.
In object-oriented programming (and methodologies reflected in distributed object technology), a component is a reusable software program building block. In this context, a single component can be combined with other components in the same single computer (or components found in several computers in the case of a distributed network) to form an application.
So at this higher level, in component-based software engineering, we could say that a hotel room reservation system is a component of a wider, higher, larger application system.
Again at a lower level, a component could be a calculator, a currency converter or perhaps an interface to a database management system inside our hotel reservation systems. So, you see, it’s tough to pin down definitive definitions here, sometimes.
Dan Scholnick is general partner at Trinity Ventures. Scholnick’s investments include Docker, CodeClimate and New Relic – the performance management specialist founded by Lew Cirne who founded Wily Technology, bought by CA in 2006.
Scholnick, who also worked with Cirne at Wiley, is a passionate talker on how and why microservices have become so disruptive to infrastructure vendors and why they are such a big deal to tech companies.
He insists he has been tracking this area since its infancy and in particular points to the huge difference containerisation has made in terms of the scale and adoption of microservices. So what IS the difference then Mr Scholnick?
“[When we look at components and what they are] I think it's just a general term for a single microservice within a microservices architecture,” he told me.
“Microservices refers to the shape of an architecture where an application is broken into many smaller, independently maintained and narrowly focused apps which communicate with each other over extremely consistent and well-documented interfaces like an API," said Scholnick.
"Some of those applications may not even be yours ... they could be third-party services such as Twilio that handle the SMS/phone call part of your application, also communicating over a standardised API,” details Scholnick. Hmm, that almost makes microservices still sound like components doesn’t it?
“You could call each one of those smaller apps components and then bucket them into categories based on where in the architecture of the application they sit. Database components, application logic components, display or presentation components. I think it's safe to say that a microservices architecture is built with a variety of individual microservices OR components,” said Scholnick.
So have we drawn a level of distinction and clarity out of this discussion yet?
One school of thought stipulates that a microservice should be able to run independently, whereas a component is supposed to be used inside a bigger software system structure. This is true. But SOME components ALSO run independently and are transferrable, that’s what makes it tough.
Microservices could very typically be written in different programming languages and employ different data storage technologies, especially when it comes to the new world of cloud where storage and memory access is a different shaped beast.
Components on the other hand (and let’s use our Microsoft Word spellchecker example) would not be well suited inside their mother application if they came with different programming languages and data storage technologies. This one difference at least may help provide some peculiarity between the two.
The truth appears to be in the need to appreciate microservices not as a distinctly different "thing" in relation to components, but as an architectural style in its own right.
As an architectural approach and style, microservices are distributed across servers with many processes, and exhibit some of the behaviours found in SOA (service-oriented architecture) but minus the typical reliance on Enterprise Service Bus and controls provided by centralised governance.
Mark Davis is chief executive of container data management company ClusterHQ. Davis argues that a microservice is a ‘specific style’ of component and so comparing microservices with components is like comparing an electric four-wheeled automobile with a mode of transportation. “The former is a refined type of the latter that has very specific motivations and goals,” he explains.
“A huge motivator for (and driver of the design of) a microservices architecture is the ability to continuously develop and deploy, through an automated pipeline, including new features and services in such a way that speeds the rapidity of business value delivery, while simultaneously raising the quality of software,” Davis told me.
Davis reminds us that microservices are very much about being able to very rapidly iterate. He concludes: “In the olden days (way back in 2013!) we spent a lot of time designing, building and testing software because we knew we couldn't deploy updates very often. With microservices, updating an application many times a day is not unusual.”
Is the difference clear yet ... almost right? The two technologies are obviously very closely matched in terms of the way they "break up" application structures, but the finer nuances of the way the two behave have not been subject to intensely strict segregation-driven nomenclature.
Not as yet anyway. Hopefully this is a start. ®