On to our bi-weekly Tech Talk #4 where our technical team get together and geek out over tech themes, in the interests of learning from each other – this week the topic was Microservices delivered by Integrella’s senior infrastructure architecture David Queeney.
With everyone’s head’s still buzzing with ideas from the afternoon API Management session with Apigee, the group settled down to learn more over a good selection of snacks and fine craft beers while getting in to it. David leapt right into his topic to address the ‘why Microservices’ question.
“Its all about scalability”
David said in his American accent, which is annoyingly difficult to place in a particular State.
“Microservices are built in such a way as to guarantee the same level of performance even when demand increases exponentially”
How on earth can it do that? Was the thought that sprang to the mind of an old hacker of traditional architectures, which are always constrained by the so called “non-functional requirements”. David then explained that this was not about a slightly different approach to organising the traditional stuff, but a radically different “soup to nuts” way of doing code .
Microservices teams operate with complete autonomy in terms of implementation detail, so that even the programming language, OS and cloud platform for the microservice could change and this should not effect other Microservices teams building other functions within the same application architecture. David then described how this could be achieved in terms of achieving the right bounded context for each Microservices application – ok so he lost me a bit here, but the diagrams were nice.
“But isn’t this similar to SOA?”
David answered his own rhetoric and reminded us how the SOA, ESB and API concepts had emerged from the need to develop new functionality alongside, and to interface with, ‘monolithic’ applications. Microservices was therefore not a simple evolution of SOA, as the services developing within a SOA architecture were intimately related to monolithic applications and therefore, although still incredible useful, were limited when it came to scalability. He explained that monolithic applications provide a lot of functionality out of the box but they don’t scale well – and the cost and timescale of new features, enhancements, customisations and integrations to these applications can be too high. My own experience of this is that companies stand a better chance of getting enhancements into product if they spend time escalating to the highest level in the organisations – but this takes time and energy. David also mentioned that monolithic apps can’t easily render the same functionality to the new range of devices which are springing up from the mobile and IoT worlds.
Nice beer this Lagunitas 🙂
So come on – what are these monolithic applications? Well of course its anything written for J2EE or .NET including the big standard enterprise SAP and Oracle applications. But it also covers the popular open source e-commerce applications based on stuff like Magento, as well as the Cloud based SaaS applications like Microsoft Dynamics, Salesforce, SAP Hybris, currently popular in many sectors. So whilst ‘monolithic’ sounds old hat, it is still the most successful and prevalent IT architecture for serving businesses.
Whilst monolithic applications and their suppliers have a wonderful set of features and functions out of the box, there are many hidden costs and gotchas for any changes to licensed function or use. Having good DevOps can help a lot in terms of shortening the development cycle of this bespoke functionality, but then monolithic apps are still a major headache in terms of the amount of time, cost and risk involved in standing up a useful end-end service.
“Microservices is a new way to architect applications”
Microservices goes hand in hand with DevOps tools, framework, general capability and culture. OK so far so good, However, a microservices architecture is NOT the same as SOA, which focused on decoupling and hiding information. Rather, each microservice is a complete stand-alone independent function which can be knocked out of the overall application without bringing the overall application down. The overall application could still function in a slightly degraded manner to meet its primary function. This is really tough to get my head around, because most of the applications I have written had always been organised into into information hiding layers – e.g. a client tier, middleware tier, server tier (it used to be 7 in the old days for any communications software!).
David finished his talk by summarising the benefits of Microservices:
- Agility – Services can be changed and updated independently
- Scalability – Services can be scaled independently
- Availability – Services have their own SLAs
The role that API gateways play is to provide an easy way for Microservices developers to interact with each other and also to expose their applications to other developers and users.
David’s talk was then followed by a lot of discussion about how Microservices fits into our client architectures and which clients were well-suited to this approach and which were not. Rodolfo described a typical target reference architecture and the role of the ESB, API Manager and potential fit for microservices . .. We all chipped in with ideas and suggestions – and a few differences of opinion surfaced… time for another beer!