Dmitry Nikolaev - Fotolia
How composable applications can improve software development
We speak to experts in the field of software development about the pros and cons of componentising application software
If every protagonist in the service-based, cloud-centric, software-integrated connected world is to be believed, the age of monolithic software is dead.
They now talk about the merits of ‘composable’ applications.
Composable applications is the idea that the functional blocks of an application can be decoupled from the complete applications. These individual component parts can then be more finely tuned to create a new application that is ideologically, if not also functionally, greater than the sum of its parts.
To make applications composable, it is necessary to define new parameters and perimeters for each individual constituent part. Essentially this is the world of packaged software.
Unlike commercial off the shelf (or COTS) products, that comprise of packaged software which offer a set of built-in features, composable applications are not predefined. Instead, packaged software represents granular and modular component blocks that can be brought together in the always-on world of web and cloud to form what effectively represents an entirely new technology proposition in every use case.
Packaged software is the process of intelligently and logically componentising and containerising related and co-related software functions, tools or even complete platform elements into defined packages.
These packages can be consumed, used, implemented and deployed by developers in entirely new compute environments and in totally different ways to anything the package’s original developers may have considered.
So why are packages so critical to successful software application development today and how does composable modularity in software enable developers to be more Agile?
Singularity matters
In a post on the Computer Weekly Developer Network blog, Daniel Jones, CTO of EngineerBetter, notes: “Software that is well-packaged requires a lower cognitive load of the engineers using it, allowing them to focus on solving business problems.”
Jones believes if a software-powered service only has a single thing to do then the developers who need to use that service in their own code only need to understand a few things about it.
Decoupling application code
Cloud Foundry’s buildpacks. are a good example of where there is a clear separation of responsibilities: the developer provides the app code and the platform provides the operating system, base filesystem and language runtime.
This separation allows the application code to have a ‘change cadence’ independent of the underlying software layers, meaning kernel patches can be applied below deployed applications, without interference.
However, technologies such as Docker have blended these responsibilities. This means developers now need to care about what operating system and native libraries are available to their applications. After years of striving for more abstraction, the industry appears to shifting towards greater coupling.
Source: Daniel Jones, CTO, EngineerBetter
“Single-purpose tools are more efficient,” Jones explains. As an analogy he says:“ Although we can make dual-necked musical instruments that combine a guitar and a bass, you can’t play both necks at the same time, but we do still have to carry the weight of both even if you only need to use one.”
Simplicity is key. Software that is capable of performing multiple functions means that people that use it need to remember more about its capabilities and its state. He argues that this is the reason why interfaces with multiple modes are dangerous in critical applications.
“Humans prefer things that always work singularly,” says Jones. “How many times have you failed to log into a system because you accidentally had CAPS lock on?” He says that software with a single responsibility can be reused more effectively and by defining well-thought-out boundaries with clear interfaces it can be changed and iterated upon with minimal impact on other elements of the system.
Package abstraction
In the past, every language and platform had its own packaging system. Ruby used gems, .NET had Nuget, Java’s was Maven. With different packaging systems it becomes impossible for developers to truly share all of their code, according to Burke Holland, director of developer relations at Progress Software.
Writing on CWDN, Burke acknowledges the benefits of JavaScript to aid code portability and the ability to share with other developers.
Read more about composable applications
- Compossable challenges: Ikea optimises everything in its warehouse, but people still have the trauma of putting together the furniture.
- Compossable benefits: Traditional ‘monolithic’ application designs tend to be extremely complex, with enormous code bases built to encapsulate all functionality into a single block.
- NPM makes it a lot easier to work with compossable applications. NPM works with Node.js and JavaScript to make it easy for JavaScript developers to share and reuse code.
Holland recommends developers take advantage of the rise of server-side applications and combine them with front-end JavaScript software, giving developers the scope to package packages as finely as they require. According to Holland, NPM has done a remarkable job of package abstraction, making applications more modular than was ever possible previously.
“Such ease in package management doesn’t come without trade-offs though. When developers use NPM packages they then have a dependency on them, meaning that if the creator decides to remove their NPM package, this could cause problems,” Holland warns.
Avoiding dependency hell
Dependencies, the link between different software packages, is among the challenges facing compossible applications.
While the theory of packaging software looks good on paper, according to Arianna Aondio field engineer at content delivery specialist Varnish Software it can lead to so-called 'dependency hell', where internal software elements depend upon each other.
Aondio has worked in second-line technical support, where the software being supported needs to run on more than one operating system and there is the added complexity of having to support several versions of the product.
She explained the problem in a CWDN guest blog post: “When a customer calls with a problem, I often need to install the version he or she is working on. Invariably, the customer’s installation has multiple dependencies. This means I need to download the same libraries to replicate the problem... and so on and on.”
In software, components evolve all the time, along with dependencies. Cutting through these dependencies is unnecessarily time consuming. Containers like Docker are the best remedy according to Aondio says, for managing the dependencies efficiently. “Once you’ve invested the time defining the provision file for each of your containers you can then install your favourite software, avoiding the 'hell',” she explains.
“Each container runs a different piece of software/application and it's up to you to decide if you want them to interact or not,” she adds.
Microservices as a standard
A microservices architecture seems to be the approach of choice for many companies.
Modernising IT applications using an elastic microservices architecture, which offers advantages like better performance, scalability and fault isolation along with minimising application downtime.
Chetan Manjarekar, senior VP head of Syntel’s Digital One practice says the key characteristics that make microservices an attractive proposition for developing new software, is the complexity associated with the old ways of doing things.
Writing on the CWDN blog Manjarekar notes: “In recent years, there has been a profound shift from legacy programs and applications to flexible, cloud-native applications that can deliver the speed, scale, and security required for the digital world. Traditional monolithic application designs tend to be extremely complex, with enormous code bases built to encapsulate all functionality into a single block.”
Takeaway package
There is, unfortunately, something of a dependency and connectivity tradeoff when it comes to software packages and packaging. When developers break their software apart into smaller component parts, these components still need to be connected together in order to perform something useful.
Given the views of the experts on CWDN, it seems a considered and methodical approach with a full appreciate for the total architectural well-being of the entire software stack appears to be the most prudent way forward when considering composable applications.
