BoxBoat Blog
Service updates, customer stories, and tips and tricks for effective DevOps
Building Internal Cloud-Native Platforms with Product Thinking
by Faheem Memon | Wednesday, Feb 3, 2021 | Kubernetes Cloud-Native DevSecOps
In line with the findings reported in the current State of the DevOps Report 2020, organizations such as Apple, Spotify, Eventbrite, and others have been showcasing their internal cloud-native platforms at recent KubeCon events. These organizations have mature DevOps practices and provide compelling self-service platforms to their internal customers that are built with product thinking and backed by end-to-end automation. At BoxBoat, we engage with our clients at different points in their cloud-native or DevSecOps adoption journey, and we believe that most of the foundational ideas, especially product thinking, should be adopted early in the process.
Adopting a product mindset can help you alleviate several pain points. For example, infrastructure teams often spend a considerable amount of time building new platforms and services but are met with a lukewarm response from their internal teams after the rollout.
The reason?
Application teams want to keep working with the old tools because they use a certain feature in the old platform that the new platform does not support. Alternatively, we sometimes encounter situations where the infrastructure teams release a half-baked platform due to management pressure and have a hard time supporting it. They find themselves inundated with support requests and platform instability issues.
Product thinking can set you off on the right foot. Start by treating your internal teams as customers and design a minimum viable product (MVP) that solves high-impact problems for them. Building a successful platform requires cross-functional teams who can build, customize, maintain, and support it. Also, like any other product development team, the platform teams also need a structure and a process to achieve their goals. The following are some of the ideas that can be borrowed by a platform engineering team.
User Personas
Before you begin, identify the target platform users and design the platform with their needs and skills in mind. For example, a data scientist may use the system differently than a quality assurance testing team. User personas will help you anticipate user needs, build the platform around their use-cases, and provide a better user experience.
Minimum Viable Product
Building a cloud-native platform requires a substantial material and emotional investment, and you want to make sure you are creating value for your customers from the start. Incorporating user feedback into the platform buildout as early as possible can make a big difference. Identify and work with the early-adopters to create the blueprints of the target platform.
Customer Empathy
Learning a new platform can be a daunting task. Platform teams should be patient and should try to see the issues from a user perspective. Design a system that is resilient and helps users avoid common mistakes. For example, create an open-policy agent rule to validate the correct storage class with an appropriate retain-policy for critical stateful applications, or set up an early warning system using USE dashboards in Grafana. Similarly, add a point into your postmortems to look at how the platform could have helped the user avoid an issue.
Communication and User Engagement
Publish your product roadmaps for everybody to see. Announce and socialize any changes and improvements to the platform. Invite user feedback routinely and incorporate any issues or enhancements into the platform. Evangelize the platform adoption by holding regular presentations, webinars, or other media.
Cross-functional Teams
The cloud-native platform requires expertise from multiple disciplines, and having engineers from varied backgrounds is crucial. For example, you would need system administration, networking, cloud engineering, security, storage, and application development skills.
User Journey and Experience
It is essential to think about how the users will consume the new platform - try to minimize the cognitive load and strive for a pleasant experience. For example, Rancher provides an excellent graphical user interface for an on-premises cloud-native platform to launch new or review existing workloads and performance metrics. Users don't necessarily have to learn to work with the Kubernetes CLI. Build higher-level functions for your end-users whenever possible.
Conclusion
Building and maintaining a successful cloud-native platform, in cloud or on-premises, requires substantial investment and resources. By adopting the product thinking, you maximize your chances of a successful rollout. Fortunately, the cloud-native community is thriving, and you can easily find multiple solutions to address any single problem. You can build or buy the tools you need depending on your team size and customer base. BoxBoat invests in building cross-functional teams, and we can help you with your cloud-native platform journey. Contact us, and we'll be glad to guide you through the process!
