After our extensive enterprise containerisation series and subsequent feature entitled ‘Preparing for enterprise class containerisation’, the Computer Weekly Open Source Insider team sat down (virtually, socially distanced) to discuss further and related container issues with John Smith, director, solution architects, at application security provider Veracode.
Smith is vocal on the aspects of architecting, developing, deploying and maintaining software containers.
He notes that there are advantages to securing code in a container environment. Each container is like an individual application in and of itself. This means they’re smaller and less complicated to work with – and it’s much easier to write secure code that is small and uncomplicated. This doesn’t mean that the problem disappears; it just means that it easier to tackle.
But he says, developer teams still require a baseline of security hygiene.
Smith writes below in his own words as follows…
If you want to have a beautiful, shiny, web-scale application, a legacy, monolithic block of code is not the best place to start. That would be like trying to change the wheel while you’re driving along the motorway. Somehow you have to balance the competing desire to move to a new architecture with the need to support an existing monolithic application.
As with any engineering decision that you make, there are trade-offs to be made. One of these might be restricting any future changes to the existing application, building it fresh, and, when it’s ready, switching people over from the old to the new. But the short answer is yes – it is difficult to connect legacy non-API compliant systems to container ecosystems.
Where the above exists, enterprise organisations may be forced into a predicament where they are running containers, but forced to create parallel systems at some level to work with older legacy systems that can’t be migrated successfully to run alongside cloud-native technologies.
People often ask me if this is correct… and it is. Veracode has been going through our own transformation along these lines. It’s been a gradual process of taking new features of functionality and bolting them on to the side of an existing piece, then taking pieces out and adding them on to the new paradigm.
Then we hit the tipping point, when the legacy piece had been largely removed or rewritten. But this is not the end of the process because the new paradigm is constantly evolving. It will be easier to adapt to the newer paradigm because we’ve moved to an environment where you write one chapter at a time rather than the whole book. If we look at the direction software is moving in however, the next chapter is being written only one paragraph at a time. The components become increasingly small, contained and constrained – tighter and simpler – and it’s the building up of these simple blocks that allow us to make something amazing.
There are no golden passports to web-scale scalability and infinite elasticity, but if you’re starting from scratch and creating something entirely new with the use of containers and modern architectures, the path is going to be far smoother.
No easy ride & no free lunch
That’s not to say there will be no effort involved. It will still be hard work, but it will be much easier to start from scratch. However, for most companies that have existed for more than a couple of years, there’s no easy ride here – it’s all hard work.
One of the great things about software development is that you must keep on learning. Whether it’s a new programming language, a new systems environment, or a new paradigm like container-based software or cloud native software, you can’t adapt to change without learning along the way.
Containers are a different way of thinking about how we develop software. It’s like trying to write secure code – developers don’t want to write insecure code, but if they don’t know how to write secure code properly they will make some mistakes. The same is true of developing an application that’s container-based – knowing what you’re doing will make the job easier. If there was a ‘containiversity’, I’d be the first to sign up.