The interview with middleware expert Mark Little, featured in ZDNet, reveals some fascinating perspectives behind the interest in the industry trend microservices, including – importantly – how microservices might coexist with existing IT investments.
Micro what?
Microservices. A new term to some, but with a growing market awareness, microservices is a “software architecture style… [in] which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs”.
Microservices has what SDTimes refers to as “striking resemblance to service-oriented architecture”. Such process are “small, highly decoupled and focus on doing a small task”, while the idea behind small services is akin to the “Unix philosophy of ‘Do one thing and do it well’”.
Small wonder perhaps that exponents of this approach include Amazon, Netflix and Bluemix. Outside these pioneers, what challenges ahead does it face as microservices looks to become main-stream?
Micro versus monolith
In the same way that technologies including CORBA, SOA and Web Services appeared over time, the pursuit of more efficient methods of how applications and systems communicate has never been off the table. While in each case these technologies offered an exciting new paradigm with profound potential, none of them became the ubiquitous global standard to replace all other protocols. Why is that? Simple really – there was too much complexity and cost involved in changing what was already there.
Interestingly, in the same article, Mark Little entertains the idea of a pragmatic approach. “If you’ve got something that doesn’t work, you should still look to see if there’s some of it that you could carve off and keep – particularly if you’ve had it deployed for 20 or 30 years”. He adds “‘even where software is not working, avoid re-implementing everything from scratch because there may be elements that could be retained”.
This is profoundly shrewd. Accepting and exploiting the available, working infrastructure, retaining the value where possible, enables micro service creation to focus only on what new technology is needed. Using this approach, a journey towards a microservices architecture is a simpler, easier and less risky one as a result. But is that really possible? Let’s explore two popular incumbent core technologies that might need examination – COBOL and CORBA – to which Little had referred.
COBOL
Now in its 6th decade of industry use, it is hardly surprising that mature COBOL systems, so often the lifeblood of enterprise IT, are identified as important systems of record with which new microservices may need to integrate.
Little makes it clear that COBOL could well form the underlying support for robust systems that don’t need to change, “if it’s implemented in COBOL, then it’s battle-tested”, he phrases it. The value of this trusted application is that it represents “COBOL code that you could take and use again…”
One of the seemingly incompatible aspects of talking about COBOL and microservices together is that these technologies hail from entirely different eras of technical evolution. However, the continued evolution of the COBOL language and supporting technology ensures that it remains as current as contemporary approaches may require. Indeed, Product Director for Micro Focus’ Visual COBOL product, Scot Nielsen, confirmed “the upcoming (Visual COBOL) release includes support for REST-ful style services that is well suited as an integration mechanism for creating COBOL Microservices”.
CORBA
One microservices definition refers to it as a model that “might also integrate with other applications via either web services or a message broker”. Little refers to CORBA as a fairly typical communications model that may need to co-exist with microservices.
CORBA-based communications technology, conceived over 20 years ago, is a valued communications protocol that supports mission-critical systems across a variety of industries including FS, Telco, aerospace, government and manufacturing. Micro Focus CORBA Solutions Product Director, John McHugh, said that it was a typical case in many customers for them to look at “protecting existing investments to lower costs and risk … to use [CORBA] products in conjunction with emerging trends and expanding their value and footprint: it is one of the reasons why CORBA continues to thrive”.
Talking of the broad technology choices enterprises have faced over time, McHugh continued “it demonstrates again the fragmentation that can occur when a new architectural style is introduced, and why any technology innovation should be seen as part of an evolutionary journey”.
Conclusion – Building Bridges
Tried and trusted systems of record, featuring transactional, messaging and core business processing components are the lifeblood of most successful organizations. This is the technology that makes the organization work. Labels such as monolithic, old, cumbersome might be lazily applied, but just as appropriate would be mission-critical, valued, trusted, and reliable.
These systems are in the comet tail of technology innovation. These ideas came to market some time ago, stood up to scrutiny, enjoyed widespread adoption, and just carry on working, without fail, quietly in the background; meanwhile, and continuing the comet theme, white-hot innovation drives new technical direction.
As Mark Little explains, and as Micro Focus would agree, bridging from valued technology investments into new innovative ways of working – microservices being a great example – is both technically possible and eminently sensible.
Learn more about Micro Focus’ COBOL and CORBA offerings at our website.
