The ephemeral composable stack - IFS: Move over monoliths, microservices ahead
This is a guest post for the Computer Weekly Developer Network written by Antony Bourne in his role as SVP Industries at IFS — IFS develops and delivers enterprise software for companies around the world that manufacture and distribute goods, build and maintain assets and manage service-focused operations.
The original title in full for this piece was: Move over monoliths, microservices are here to stay.
Bourne writes as follows…
In a recent report, IDC asserted organisations are “moving beyond the ‘dinosaur enterprise apps’ to new modular enterprise apps”. While dinosaur applications can’t be declared extinct quite yet, they are undoubtedly on the way out, as the longer-term shift to composable enterprises continues apace. As more and more people realise composability enables them to gain better visibility of their own business, respond to emerging market needs and save CIOs time, effort and money, that shift is only ever going to accelerate.
Users of monolithic software i.e. self-contained, tightly-coupled applications built as one unit, know this all too well, with many having seen their tech stacks growing into what software developers often term the ‘Big Ball of Mud’. A sprawling application that—due to financial and time pressures, piecemeal growth, too many patch fixes/quick hacks and a haphazard structure—ends up having no perceivable architecture. It’s a situation where no single developer, or even group of developers, can understand the application as a whole.
It’s no surprise they’re going the way of the dodo – the only surprise is that it’s taken this long.
More modular, more responsive
Today, many businesses are latching onto the fact that nimble and agile software translates to nimble and agile responses to their market. But many are still asking where they can find that agility.
The aforementioned IDC report attributes four key traits to modular applications: “SaaS and cloud enabled, with automated workflows…constructed using a microservices architecture and APIs.”
Cloud may not be for everyone, but for the most part it allows companies to be nimbler and more flexible, while providing anywhere, anytime access. And as far as automation is concerned, the move away from rule-based functionality to AI/machine learning and robotic process automation (RPA) is becoming increasingly important to delivering optimal results for customers and positive outcomes for the business.
However, it’s the latter two of the modular applications traits IDC cites that are perhaps the most important from a composability perspective. Breaking down what sits in a monolithic application into individual, but complementary, microservices and capabilities is increasingly popular for a reason. Being able to spin these capabilities up and down as required – and maintain and update them independently without detrimental impact to the others – is a big improvement over more ‘forklift’ approaches.
The Bourne Connectivity: Think about shifting to a servitized model for ephemeral composable control & power in the modern IT stack.
Not every element of a business – and as such their software needs – evolves at the same pace. In some areas, horizontal technologies evolve rapidly and it makes sense to take advantage of new capabilities as they arise. In others, the software that powers it may not see meaningful change for years or decades.
Building for best fit
Building applications as loosely coupled services makes sense here – allowing organisations who employ a composable architecture to capitalise on independently deployable modules that are organised around business capabilities, swapping modules in and out to suit emergent needs and building up a well-structured, best fit solution for their business.
These microservices are independently scalable, so as demand for an application increases, it’s easier to add resources to the most needed microservice rather than having to scale the entire application. This flexible approach is quicker and more cost-effective than scaling with a monolithic architecture.
On the subject of pace, a composable application’s time-to-market is far quicker than alternative architectures. If you’re able to write code in small sections that can be tested and deployed independently, make it simpler to integrate new components of the application and deliver these updates much more quickly, that can be a significant competitive advantage. In practice, this means it’s much easier to leverage and apply tools such as robotic process automation, artificial intelligence or the plethora of hyperautomation capabilities available today, aimed at simplifying workflows and optimising business processes.
Where some may see difficulties with this approach is when the microservices an organisation wants to use sit in two or more distinct applications – and this is why it’s not simply about breaking down monoliths into more manageable chunks. Application Programming Interfaces (APIs) are not a new concept (their origins stretch back as far as the 1940s), but the major recent shift has been in how they are used.
Historically, APIs have been used in monolithic applications to exchange data between the entire application and external applications and services. But in composable software, there are two important differences. Firstly, the exchange is from individual modules (not from the entire application) to external applications and services. And secondly, APIs exchange data within the application too—from module to module. This has significant implications for how systems are designed and built.
Good citizens breed goodwill
Most vendors have realized they don’t have all the answers to their customers’ problems and have largely stopped trying to claim that they can, preferring instead to either build or acquire the capability later. Today, they’re much more willing to play a more collaborative role as part of a wider ecosystem of software specified by the customer to suit their needs, with this customer-centric model also giving rise to low-code/no-code approaches among others.
APIs, of course, play a key role here, but composability requires we go beyond the bare minimum exchange of data and move to an approach where applications are “good citizens” in a customer’s ecosystem – whether the vendors have a strategic alliance or are close competitors. If a manufacturer can seamlessly combine microservices from a financial software application, with resource planning and service management capabilities from another and customer relationship management from another still, they can understand the full lifecycle of a sale and end user experience. If they can do that, they can find efficiencies and areas for improvement. In addition, they can think about shifting to a ‘servitized’ model, selling on an outcomes basis and armed with insight into the full lifecycle costs of the products they sell and can price a packaged service accordingly.
It is possible to do this without a composable architecture and even on-premises, but the costs involved and resources required are eye-watering. Embracing composability is the best way to capture all of the advantages of modern enterprise software and as few of the pitfalls as possible. The sooner vendors realise the best way they can serve their customers and deliver the most value is to be more open to this model, the better. The sooner they focus on doing what they do well and allow others to do the same in a seamless, harmonious way, the sooner the technology industry can reach its full potential and make an even greater economic and societal impact than it does today.