With the continued growth and transition to microservices it’s important to ensure modern, cloud-based solutions are at the forefront of your organization’s goals. In this multi-part series, we’ll look at all the different components and considerations that must be taken when modernizing to microservices. 

In this blog, we’ll look at process management & production capacity.

Keep a Close Eye on Processes

When an audit or process has no correlation with the quality of the release, there is an opportunity for improvement. When ignored, it reduces the teams’ ability to deliver, and people may feel a sense of fatalism, perpetuating the concept that process-following is more valuable than the result itself.

Processes that contribute nominal value to the final product often originate from a well-intentioned policy that has, over time, become a checkbox exercise. Examples include attaching documentation to issues with little review of its quality and usefulness, or writing troubleshooting articles that end up being low value-add, like a copy-paste from other services. The self-inflicted pain of check-the-box activities takes courage to address, yet always pays back dividends exponentially when improved. The proper agency and a relentless focus are needed to trim processes and prioritize value add.

When a regulatory process is a bottleneck, revisit the original requirements to analyze whether the processes can be changed to achieve compliance more efficiently. For instance, a regulation originally intended to guarantee third-party penetration testing can now leverage automation and AI-based tools. Change the process and improve the results.

Plan for Production-Only Issues

Unfortunately, not all problems occur within the confines of test environments. Problems occur in production, too. When they do, what’s most important is how they are managed to minimize the impact on end users and the business.

Let’s talk about a situation where an issue – not found in testing – shows up in production and impacts end users. The first thing teams attempt is to reproduce the issue in lower environments. But what if that reproduction can’t be done in a timely manner (and timeliness depends on the impact)? Improving the test environments and/or processes is needed, postmortem, but what about right now? Is there a plan in place that allows for controlled changes that pass all the existing tests, and that would tentatively improve the situation, to be deployed to production? Or is the organization entering into analysis paralysis and falling back to the process as a cover for taking calculated risks? Fear of making things worse is good, but stopping progress because of fear is not.

Employees often follow the process to mitigate the risk to themselves – processes that present issues that have likely occurred previously. Nobody gets in trouble for following processes, even if the outcome is detrimental. Successful continuous delivery and continuous improvement must include the ability to roll back extremely quickly and efficiently. When the business model permits, canary releases can also be leveraged to test changes. There are times when a change that tentatively addresses a production issue is not reproducible in lower environments – and still passes all the reviews and tests in those lower environments – is an appropriate level of risk to take in the short term.

Previously, we looked at the importance of starting with the team and defining ownership. 

In part four, we’ll look at how to reserve capacity for innovation.

Ready to modernize your organization’s microservices? Oteemo is a leader in cloud-native application development. Learn more: https://oteemo.com/cloud-native-application-development/