The software is live. The team has reached that state that it calls ‘production’, denoting a software application or system’s living status. Once software code graduates from its various pre-stage, alpha, beta and release candidate stages, it gets pushed (figuratively, but often quite literally) to live production, where it is often referred to as having reached GA and/or RTM stage, denoting general availability or release to manufacturing.
But that was just day-1 of the job; the real work to actually finesse and ‘make good’ an application often starts on day-2.
Day-2, when the users start to use
In real terms, day-2 is the point at which users start to actually use. Let’s remember that this is 2021 and that some of those users will be human users, some will be intelligent machines and some will be elemental (and possibly ephemeral) sub-components of other applications that make connections to a new app via an Application Programming Interface (API). Regardless of whether they are carbon-based lifeforms or digital, once the software is live, users and machines use it.
So how do we press onward to day-2 software deployment effectively and efficiently?
Taking the popular cloud container orchestration platform Kubernetes as a case in point, he says that these computing environments often show up their real challenges on day-2 i.e. the team has designed, developed, built and deployed an application, but has it thought through the longer term impact factors of usage?
As in (live) rock music, it is in (live) software
Typically, day-2 sees the software team start to get some real world User Acceptance Testing (UAT) feedback. Although they’ll naturally have carried out some of that UAT process beforehand as part of due diligence – as in rock music it is in software – there’s nothing quite like the real live effect of real world performance. Day-2 will also see activities involving maintenance, management and monitoring of an application.
MORE FOR YOU
Whether it’s Kubernetes or some other fundamental baseline technology, Marshall argues that the most common issues with software are caused by poor application design and configuration from the get-go — and that these are simply compounded by a platform that demands that applications are well behaved and use best-practice conventions.
The Appvia tech guru also points to day-2 issues that can arise due to integration issues. “Preparation is key, as they say… and it’s no different here in the world of enterprise software. The way a software team addresses integrating applications is crucial. The delivery lifecycle should be reinforced and strengthened by continuous testing that considers the production delivery platform at every stage,” said Marshall.
Design for failure, enjoy successes
He advises that one of the most important considerations when designing an enterprise application is to design for failure. Prudent software design is all about expecting downtime, so an appreciation for that truth needs to be built into application design.
In order to fail early and/or resolve things quickly, the development process should enable testing. Marshall says this applies to an organization’s teams and to its platform provider, so we can ask smart questions like: (in the case of Kubernetes) can you de-bug in-cluster? Or, when you’re building, is the focus is on security, availability and debug time?
“It is vital to ensure your application build process is optimized for creating containers with minimal dependencies. A simple container with a single process reduces risk caused by complexity and directly increases security. A complex container with many dependencies will increase debugging time and compound day-2 production issues,” he said.
Day-2 honeymoon: find problems before the customers
Overall, Appvia’s Marshall and his team are agreed on the core goal here: software teams need to use that valuable (honeymoon period) of day-2 to detect and find problems before customers who will ultimately use the software find them.
This means that day-2 is all about setting up practices to do this successfully with monitoring application metrics and good alerting. A good software platform should also provide close ties with developers to support things like self-service, upgrades and platform debugging.
“Testing and profiling an enterprise application with realistic workloads is key to understanding how your application will fit together with your other platform elements, before any release to production,” concluded Marshall.
If you’re a C-suite suit listening to your IT function tell you all about a new platform or software system roll-out initiative, don’t be 100% lulled into any false sense of security by the pizzazz of all the new functionality promised. Ask about day-2 contingency plans, ask about integration and maintenance insurance windows, perhaps even throw a curveball in there and ask about ‘in-cluster debugging’ just to show you’ve been doing your research.
In the sacred scriptures of the enterprise software release playbook: day-1 is important, day-2 is very important and day-222 is even more important if an enterprise wants to architect functional IT systems that deliver for the short, medium and long term.