As an OpenShift Administrator, what questions should you ask your developers

As a member of the Red Hat consulting team, I often encourage organizations to bring forth a business fuelled use-case to help them deploy and run OpenShift so that they have a starting point for container adoption. What happens after that? Does that platform continue to grow and develop? It certainly should. OpenShift Container Platform has been designed with multi-tenancy in mind and more applications should be introduced to share the compute, networking, storage, and expense of running such a platform.  Where does one start though when wanting to introduce a new workload to this platform? There are a few questions that can help you identify some of the baseline requirements of this new workload as well as prompt you to improve on the current features offered by OpenShift in your organization and make a more compelling offering to your business.

Questions when onboarding new users

The questions below have been divided into categories to help SREs and Product Owners  understand the types of capabilities to develop within the platform or be supported by the organization. 

Core Platform Requirements: 

• What kind of storage requirements are needed (Size, type, availability)? It is often the case that platform SREs deploy more than one storage type as a capability for the platform. This means that different storage features around speed IO etc or types of storage (file, block etc) could be a requirement by different applications. An ongoing reevaluation of the consumption and adoption of these storage offerings on a regular basis will better help offer desirable assets to the business.
• How much compute are they likely to consume per environment? It is often the case that different types of workloads are hosted on the same platform. Based on the compute requirements, additional nodes including new types of nodes may need to be introduced to cater to certain workloads.
• What type of memory requirements are there? Again, this fits in with the above compute requirements. 
• Are there specific network bandwidth and requirements (requests etc)? Will the current ingress controllers be able to handle the new request? Do we need new ones? What about the underlying network platform?
• When traffic accesses the application, what kind of traffic is it (HTTP, tcp, other)? Do we need to consider a different ingress strategy, such as LoadBalancer Services or NodePorts.

Observability:

• How will application developers monitor the performance of their applications? Do we need to look into customizing or creating an application specific prometheus instance? Do we need to look into other areas of monitoring?
• What about log aggregation? Do we need to consider multiple cluster logging? Does an application consider DR or active-active setup and if so, how do we make sure that developers get their logs?

Application Design:

• Is the application stateful or stateless? If stateful, how is it handled (i.e. require sticky sessions etc.)?
• Are there multiple components/processes or a single one to run?
• What are the dependencies of the application on startup or network connectivity (are there other containerised applications that need to communicate with it)?
• What are the security and authentication requirements of the application?
• How is the resilience of the application handled? Is there a need for workload scheduling / affinities?

CICD and Code/Image Promotion and deployment:

• How will promotion and deployment be facilitated? Is there a central location where we have all the images stored? What about source code promotion? 
• How will they be promoting images across environments?
• How many environments do they need before going into production?
• What about configuration promotion?
• What are their current release processes and frequency of releasing? 

• How CI/CD pipelines (existing and new) will integrate with the platform?
• What’s their current CICD model? Centralized in the organization/department, per team? (This is to determine if we need to think about CICD tooling at all as an offering part of the platform)
• What SCM management strategy are they using - monolithic repos (one repo) -  or microservice specific setup? How are they managing the repository: trunk/git flow/PRs etc. How is code review performed? What dependencies on other applications do they have? (data flow diagrams would be useful)
• What development tools are your developers using?
• What language/frameworks are they working with?
• How are they developing currently (tools used, testing used)? Where do they think they can change their development processes?
• What kind of authentication mechanisms do they use/provide to end users?

Developer Onboarding

• How do they onboard their new developers (do they have different types of roles within the team? 
• Do we need to worry about different permissions for different developer types?
• Do the developers have different access in the development environments than production environments?

Know the importance of a good conversation

These questions are a way to allow a good conversation between you and the development teams that want to make use of the container platform. This is a good start in encouraging open and agile working practices and also a good idea in keeping things transparent and setting expectations early. Using these questions as part of a conversation is far better than sending them out as a form or spreadsheet. Although the latter will likely be more accurate in terms of numbers when initially asked, what we can gauge from these questions are the actual priorities of the users of the platform when it comes to the features we asked.

The next steps are to prioritize the capabilities the developers have asked for, and then break them into tasks to be added to the SRE backlog. If you're interviewing more than one development team, then the most important items to them should be the ones that are at the higher priority of your backlog. These items need to be fed back to the development teams as things you've prioritized as part of the platform product you're managing to verify that this is the right direction for you and your organization. It illustrates to your consumers that you’ve heard their requests and prioritized their requirements in a tangible way for delivery. They might also be the first people that would give you feedback on 

The areas highlighted as part of this discussion are only a starting point for getting to better know consumers of the container platform and how to improve the overall operating environment.  If there are more items that you think have been missed from this list, then please comment below on your experience.