Translating insights into design solutions that changed the way developers create and deploy applications on OpenShift
When it comes to application development, companies need to look beyond IT infrastructure concerns to create an atmosphere for innovation. By taking a broader approach when defining business priorities, that includes investing in smart developer tools, teams will have more time in their development schedule for break-through thinking. This can help to create a culture for innovation.
Designing one’s code to do API-driven deployment of microservices as secure containers with zero-downtime deployment is critical for the continuous delivery of software services. However, it is time-consuming and nerve-racking for developers to roll updates to a live application accessed by millions because stability and security are at stake.
The topology view in the OpenShift Web Console’s Developer Perspective is a great example of how a thoughtful design approach, assisted by the combined power of containers, microservices, API-driven integration, and DevOps automation, is helping developers achieve more and with less time and stress.
Before getting into the topology view in-depth, let’s get ourselves acquainted with OpenShift.
Disclaimer: This blog post contains some features that are under design and development, there is no commitment to when or if these actually would be released. Some of these features have been marked with an asterisk(*).
OpenShift
OpenShift is an enterprise-ready Kubernetes container platform with full-stack automated operations, that allows users to develop, run, and manage applications without getting lost in the complexity of building and maintaining the infrastructure involved in the application deployment process.
OpenShift Developer Experience
With OpenShift 4.2 we introduced a new feature to the Web Console called the Developer Perspective. This perspective significantly simplifies the workflows for commonplace development tasks. The topology view is the landing page within this perspective. Through its highly intuitive and comprehensible visual layout, it enables developers to:
- Look at health status alerts*
- Identify areas that may require intervention in the application structure
- Take required corrective actions
- View real-time feedback on transitional stages
The topology view provides an application-centric view of a project, in the simplest way possible, visualizing application components and their connections, in addition to real-time status of some of the components.
The Topology View
The topology view is a thoughtfully designed interface that provides a visual representation of the application structure. It helps developers to identify one resource type from the other, as well as understand the overall communication dynamics among the existing resources.
Design insights and the topology view
Adhering to the values of ‘Open’ over the decades has helped Red Hat to become the leading Open Source enterprise solution provider — with a versatile client base and the support of millions of open source developers. Red Hat has a presence and participates at almost every conference that relates to Open Source. This widespread penetration has allowed Red Hat to talk to developers and to gather insights into the developer mindset. The design team for the OpenShift developer perspective leveraged the most relevant insights and used them as a baseline for creating the interactions found today in the topology view.
Provide immediate feedback
Not being able to see immediate feedback for their actions has been an everyday struggle for developers on various platforms. This brings in an extra delay in their process as they have to take additional steps to validate their syntax before moving on to the next step. The topology view solves this problem with the following design approaches:
- Adding a resource[4.2] — When a user adds a new resource to their application, a component is immediately added to the topology graph, providing instant feedback regarding their actions and it’s status.
- Scaling up/down, Starting Rollouts and Recreating Pods[4.3] — In Kubernetes, to increase or decrease the number of replicas of a workload user wants to run, they have to scale up or scale down. While scaling, the pod goes through a set of transitional phases before it gets up and running. Similarly, while starting a rollout or recreating a pod, there are many intermediary transitional stages that the pods go through. Topology allows users to see the real-time status of those stages through an animated visual representation.
- Connecting a database to an application* — A user can add a database to their node.js application through the topology view by merely dragging an arrowhead of a connection handle.
Developer friendly failsoft approach
The fear of breaking a build is real. With every push to the production branch, there begins the anxiety of breaking the code. To ease developers of this worry, the operations must be made failsoft(just like Lego blocks, rather than failing with an error message, every interaction attempts to do something sensible even when presented with out-of-range inputs).
- Adding resources in context* — While the users are in the topology view of a given application, performing a right-click provides them with an option to add a resource. However, depending on the visual area where the action is initiated from, the options for the resource type that could be added varies. This brings down the chances of deploying any irrelevant resource type for a given application.
- Determining connection-type[4.3] — The topology view allows for creating a connection between any given pair of resources by simply dragging a handle from the origin nodes and dropping it over a target node. It reduces the cognitive load on the developers by doing a smart assessment of whether an operator managed backing services is available for creating the intended binding. In the absence of an operator managed backing service, an annotation-based connection is created.
- Role-based access control (RBAC) — To further bring down the developer’s distress, the role-based access control (RBAC) implemented in the Developer’s Perspective of OpenShift adds an additional check on the actions available to a user. It ensures meaningful segregation of tasks and responsibilities for the user based on their role in the team to avoid overlap and conflicts. However, restricting actions might become a source of frustration in certain cases if the cause isn’t communicated very clearly. Framing the appropriate error messages plays a very crucial role in ensuring their continued engagement with the console. Instead of simply stating the failure of a performed action, the message also clearly communicates the reason and provides the alternate solution, if any.
Concrete visual interaction for abstract data
While writing the code for an application, a developer has to deal with manifestations of various kinds of information and data in the command-line interface. The visual fatigue caused by the monotony of characters in code can very easily result in oversights that might be difficult to reverse later. Humans are much more responsive to visuals rather than abstract data. Translating the crucial data into perceivable and actionable visuals can save time for the developers, allowing them to identify the area that requires immediate interventions and take the appropriate actions with ease.
- Displaying event sources* — The topology view shows elements from Knative Eventing, namely event sources, which helps give a developer quick insight into which event sources will trigger their application by looking at it visually.
- Representing hierarchy and groupings on topology view — With the help of visual demarcations, a hierarchy is maintained in the topology view for the resources in use under an application. The grouping of nodes into visual groups when needed(e.g. application, Knative services, Helm workloads, Operator backed workloads) and the nesting of those groups provides a tangible idea of the depth of the application structure.
The topology view of the OpenShift Developer Perspective is a re-defined approach to application development that demonstrates many possibilities of what the future could be like. By using context-based visualizations to assist the developer, the topology view interface frees up their time to focus on other tasks. This could very well be an onset of a more productive and innovative era in application development for cloud-native, microservice deployments. Besides making it easier for the developers, this simplification of tasks, and automation of the infrastructure managing and monitoring front should also reflect positively on the developer experience, security, stability, and business value side.
*Scheduled for future release. Actual implementation might differ.
