The ephemeral composable stack - Perforce: Shifting to 'assembly culture' with bigger widgets
As the Computer Weekly Developer Network embarks upon its editorial analysis series examining the ether (and on-premises synaptic connection points) that now form the ephemeral and inherently composabe technology stack of today, we feature a series of guest authors.
This post is written by Rod Cope in his capacity as CTO of Perforce – a company known for its Software Change & Configuration Management (SCCM) technology and its wider competancies in development tools spanning version control, application lifecycle management and agile planning.
The original (lengthy) title of this piece is —
Ephemeral DevOps in a Composable World: it’s not perfect yet, but it’s needed, inevitable and developers need to embrace it.
Cope writes as follows…
Bigger widgets, by far
We’ve been talking about composable IT for over 20 years, but what has changed is the size of the reusable components. Instead of widgets, we’re now talking about reusable databases, clouds and virtual machines. While that ideal world where nothing has to be built from scratch is not here yet, the demand to develop faster and at scale means that pulling together ephemeral components to deliver projects quickly is forcing the pace of change. Plus, open source — the adoption of which we all know is growing fast in organisations of all kinds — is in itself a form of composable development.
Composable IT is here to stay and developers — and business management — must address the challenges and embrace the opportunities.
Perforce CTO Cope: Quit bashing those rocks together guys, get ready for bigger widgets & a cultural mindset shift.
The good news for developers is that they spend less time creating basic building blocks, can deliver more code more quickly, hopefully freeing up some time to spend on more out-of-the-box innovative thinking, or at their very least, adding to an app whatever their unique contribution might be.
Shifting to ‘assembly culture’
That’s a huge cultural change for many teams and it does mean more time spent on assembling those pieces of code. Plus, at the moment, a lot of those pieces don’t naturally fit together very well, so overcoming that can take up a lot of time, and developers may question whether it was worth the effort.
There is help out there: for instance, there are some security-hardened, vetted infrastructure components out there from the likes of Ansible, Chef and Puppet, that help teams grab what already works off-the-shelf and customise for their particular needs, with an automated infrastructure-as-a-code approach. Net result? Developers get to compose well-tested pieces into an existing DevOps workflow, providing better agility and quality, at speed and at scale.
There’s also a mindset change needed on a management level because the Total Cost of Ownership (TCO) of composable IT will be hard to predict and old metrics are not valid. Cloud is typically charged by the hour and those hours are going to go up and down, plus also… experience shows that overall expenditure goes up. However, the business may have become more agile, delivered more products to market faster and generated greater sales: yet again, it’s time to view IT as an asset and not a cost centre.
Also, composability-at-scale means reuse and knowing what a company already has, rather than having to reinvent the same wheels over and over again. There are ways to deal with this, such as having searchable central repositories of all APIs.
Composable development means some significant changes and a lot of people don’t like change. However, now is the time to get on board — perhaps just partially at first, start small and grow — rather than risk being left behind.
