Disclaimers and excuses.
I’d like to think I know as much or more than the average tech. pundit when it comes to building large-scale, resilient systems. In a previous life I spent the best part of a decade building large complex distributed systems for space, transport, telco. and utilities using CORBA, DCE, COM, WS*, REST, etc. So for what it’s worth here are my views on the latest architectural buzz-word du-jour – microservices. I’ve also heard numerous terms to describe the ideas behind microservices :
- μservices (this one is bankrupt)
- hipster-SOA (I like that one)
- MSA (why does everything have to be a TLA in this industry ?)
- agile SOA (this one has some merit)
- SOA-2.0 (Just. No.).
I think I’m going to stick with microservices until someone proposes a better alternative. But Agile SOA – yeh – I like that.
There are lots of articles on the web about microservices, and I’ve included links to what I believe are the better ones below. I’ve also seen quite a few conference presentations (some good, some bad) and they all fall into one of two categories :
- In the trenches, doing it today, at scale for real customers.
- Higher-level description and fundamental principles
There really aren’t many of the former and this post falls into the latter category. I haven’t been a “real” developer for at least 15 years and I won’t show any detailed blueprints or code in this post. But I do intend to share some of my experiences, research and what I’m hearing from customers, analysts and other tech. pundits. I’ll also answer some questions I’m already being asked; a small sample here :
- Isn’t a microservice architecture just SOA ?
- Is this just the next software vendor buzz-word du-jour ?
- How many LOC (Lines Of Code) is a microservice ?
- Are there any applicable standards ?
- Is an architecture build on APIs microservices ?
- How do microservices relate to agile and DevOps ?
- Where can I buy a microservice product ?
At this point I should add – these are my words and my opinion but they are heavily influenced by my role here at Red Hat where I run Product Management and where I have responsibility for a bunch of Red Hat’s Middleware products. I’d like to think I’m generally fairly impartial but I can’t promise not to be a little biased here and there. Finally – I’m learning here as well – I welcome challenges, questions, feedback and discussion. Comments are open.
New challenges.
So what has changed that has people across the industry questioning the architectural approaches and design decisions they’ve made in the past; or more importantly looking at alternatives to those architectures and practices for developing the next generation of applications ? A number of things :
Technical / architectural debt
When we talk about Applications in the Enterprises – we’re more often than not talking about complex compositions of intercommunicating systems – often developed over many decades using an array of technology. Individual elements of the “system” have their own release cadence, dependencies and often different owners with different goals. An increasing amount of energy is required to merely keep things running and avoiding outages that impact the business. Less and less energy is available to create competitive services and applications to serve the business.
The rise of DevOps
There is a strong headwind from the DevOps movement to radically change the way software is delivered and maintained. An essential element of DevOps is the notion of Continuous Delivery – a continuous stream of small, incremental chances to production applications instead of large disruptive upgrades. This requires an agile process and solid automated build and test using modern software development tools and practices.
Greenfield Opportunity – Digital Engagement
A shift towards developing net new systems that are focussed externally vs internally – if you follow Gartner – that’s the shift towards Systems of Engagement (or Innovation) or mode 2 applications using their Bi-modal IT vernacular. Or IDC’s third platform. Or Forrester’s “The Age of the Customer”.
Open Choice
During the last decade and a half – when building an application for the enterprise – there were two dominant choices – Java EE or .NET. More recently developer’s choices have expanded and IT has been willing to support a broader range of technologies. Especially for the kinds of green-field systems described above, developers are much more likely to make choices beyond the mainstream IT approved stacks and pick fit-for-purpose technology (eg. node.js for mobile, PHP for web, Java for middle-tier logic and back-end integration) Open source has made the technology that supports building resilient, distributed, web-scale applications far more accessible to far more developers. As with many other areas of technology – the innovation is happening in open collaborative communities and not in the ivory towers of traditional software vendors. Some notable examples are vert.x, ReactiveX, Netflix OSS.
Anatomy of a Micro-service
- Microservices build on the same solid principles of good software design long espoused by practitioners of Object Oriented Systems and Service Oriented Architectures. Namely :
- Loose coupling in all dimensions – time, lifecycle, type, location, interface, version.
- Clearly defined purpose.
- Autonomous – eg. taking responsibility for failure, resilience, security, etc.
- Explicit Boundaries – self contained implementation; dependable public APIs.
- Standards-based wire protocols, not language-specific APIs for interoperability (assuming heterogeneous technology)
- Policy & Meta-data driven – favoring configuration changes over code changes
Microservices can only be useful in an underlying environment or with a platform that provides a means for :
- service discovery
- service replication (for availability and scaling)
- dependency resolution and management
- service failure detection and recovery
- reliable and flexible build, package and deploy toolchain
- service monitoring, alerting, eventing and introspection
Many of these technologies and solutions exist today and have been used successfully with monolithic and SOAs for many years but microservices deployments may push existing tools to the limit for a number of reasons – scale and heterogeneity. So this begs the question – “How is microservices different from SOA ?” Well, firstly – it’s not about size. We shouldn’t get too hung up on the “micro” prefix – services (micro or otherwise) should have a well-defined single purpose and a stable API – it shouldn’t matter if the implementation is 100 lines of COBOL or 900 lines of Scala. Some would argue it’s about the underlying technology – some pundits claim microservices is a movement against and away from traditional SOA and integration technology and vendors. I’m not convinced this is a major differentiator or driver for microservices – there are many ways to implement micro services and few people will be willing to completely burn their IT portfolio to the ground and start again. Well, I’m not completely convinced – I do think the whole integration space has become associated with large proprietary software vendor stacks and overly complex standards – I can understand why people are looking for a more agile, lightweight alternative. For me – the major change in thinking is something that we haven’t been talking about in the SOA world much in the last decade and that is operational agility and flexibility. Essentially, I believe microservices is good SOA principles married with modern DevOps practices – it’s an architecture that supports a fast cadence of continuous change in an operational environment vs big-bang upgrades with long release cycles. That’s an architectural approach married with an agile process for delivering the new breed of customer engagement applications I discussed previously.
Some Cautionary Notes
Building reliable, maintainable distributed systems is hard and many of our previous assumptions about software development no longer apply. As we learnt with CORBA and COM – moving objects / services out of process adds latency, performance and code overhead. It introduces failure scenarios and potential security exploits that didn’t previously exist – eg. well constructed in-memory function calls rarely if ever fail; add an air gap and everything changes – the code overhead to handle failures, retries, security, etc. likely eclipses the application complexity (and cost) itself. This was also true moving from non-SOA to SOAs. Managing service dependencies is also a challenge – we faced similar challenges building distributed systems with DCE, DCOM and CORBA and more recently SOAs and that underlined the importance of governance and API management tools, but microservices architectures will exacerbate the issue as we increase the number of services. Decomposing applications into fine-grained services each with their own process-space and possibly their own container / virtual-machine introduces additional resource utilization and process management overhead. Finally and as I mentioned above – micro services architectures build on solid SOA principles to solve some very real operational bottlenecks – I strongly suspect that successful microservices practitioners are also successful agile and DevOps practitioners.
Summary
Microservices is an architectural style that builds on solid principles of good software design – when used in a mature DevOps environment it can increase the cadence of change without increasing the risk and cost of maintaining large, complex systems. It delivers operational flexibility and agility but it comes at a cost. It requires developers to understand distributed systems development and requires sophisticated systems and application management tools. Ultimately people will have to make the tradeoff between operational agility and development complexity Microservices represents an evolution not a revolution and IT practitioners should avoid micro service envy and rush to re-architect perfectly serviceable applications without discrete problems in mind than can be solved with a move to microservices. Oh, and if someone tries to sell you a microservice product – run away as fast and far as you can.
Further Reading
“What is so Special about Microservices? An Interview with Mark Little” , InfoQ, February 2015 “Micro services : Decomposing Applications for Deployability and Scalability”, Chris Richardson, InfoQ, May 2014 “Micro services” by Martin Fowler, ThoughWorks, March 2014 “Micro-Services – Java, the UNIX way” by James Lewis, ThoughWorks, Sept. 2013
