This is a contributed piece for the Computer Weekly Developer Network written by Crystal Morin in her capacity as cybersecurity strategist for Sysdig.
In her role today, Morin is tasked with bridging the gap between business and security through cloud and container-focused analysis for everyone from executives to technical practitioners. She was originally a threat research engineer on the Sysdig Threat Research Team, Crystal spent her time discovering and analysing cyber threat actors who took advantage of the cloud.
Morin writes as follows…
Everyone hates to waste time and effort.
For developers, spending time on things that may not matter at the end of a sprint gets in the way of time spent problem-solving and writing code. If an organisation wants to improve developer experience (DX) and get the most out of the efforts put in, then we have to know where to focus.
For many developers, anything that is not directly related to their end goal of putting together software can be perceived as negatively affecting DX. This can include meetings and reviews that aren’t focused on code. However, listening to a strong brief once in a while regarding business goals can be an efficient way to inform a developer’s actions and decisions around how they code and the tools or platforms they use.
That meeting might save a developer hours of wasted work due to lack of communication or misunderstandings.
Just as developers hate wasting time in meetings, they should avoid wasting time on unnecessary code too. A developer may have assumptions on what the software infrastructure needs to function, but are those functions correct in practice? Are there dependencies that need to be looked at, or are there elements that aren’t required? To improve DX in the area of software variables, we have to look at what exactly the real challenges are and where time and effort waste can be avoided.
Look at runtime operations
So how do you know what is actually needed in your software deployments and where you need to focus your efforts?
One approach is to look at what is actually used rather than what you assume you may use. We may rely on standard, third-party, pre-packaged container images that host all the components that another organisation’s developers believe need to be included – and we continue to use those images any time we need to spin up a new container.
But think about it, do each of your containers need all of that code every time you call it?
Looking at runtime environments, a developer can see what is actually happening in applications, to include what is being called and what is not. Over time, this will show if there are components in the software images that don’t ever get used. These unused components add unnecessary security risk and maintenance requirements for developers. Rather than using base container images that are bloated, developers should prioritise time to reduce container image sizes across their libraries and repositories as much as possible to reduce maintenance requirements and security risks.
This improves DX by making it easier for developers to keep their focus on what truly matters, writing and improving software code.
Demote container bloat
Reducing container bloat also makes containers more performant. When you are dealing with hundreds or thousands of containers as part of a microservices application, every size reduction leads to a cost saving on cloud resources consumed over time, and that can add up to be quite substantial.
DX is about making life easier for developers so they can build software and create code. By looking first at what is running, developers can keep their emphasis on what is really valuable and avoid the headache of maintaining bloated containers.