Platform Engineering is helping organizations streamline the way with which they are building applications and delivering value to their customers. But how do you make sure you are building the right thing and building the thing right? In this blog, we will talk about how Portworx provides the resilient and enterprise grade data platform for your internal developer platforms (IDPs) – ensuring you are building the best platform to increase developer productivity and reduce operational overhead.
But before we talk about Portworx, let’s talk about how organizations can measure progress and build a successful DevOps practice by talking about the latest DORA Report. This year’s research focused on not just software delivery performance metrics like previous reports but added three key outcomes that organizations should aim for to get better:
- Organizational performance: Focus not just on revenue – but also the value an organization brings to its customers and its extended community
- Team performance: Enable applications and service teams to create value, innovate and collaborate better
- Employee well-being: Focus on increasing productivity while reducing burnout, resulting in an overall satisfying job experience
Continuous Improvement
Organizations should focus on approaches like Kaizen to make small but continuous improvements that can help them move closer to the outcomes discussed above and become a high-performing or an elite organization. Platform Engineering is one such practice through which organizations are aiming to reduce unnecessary toil on developers, so they don’t have to spend time and effort on performing repetitive and non-differentiated tasks that can lead to burnout. Platform engineering is about building golden paths for developers, so they can focus their efforts on innovating and creating value for customers.
Organizations that are on the forefront of platform engineering have dedicated teams working on building internal developer platforms for their developers and treating their internal developer platforms as a product that caters to their internal customers. Organizations should not just focus on what vendors are pitching as the best way to build platforms, but rather look internally, interview application and service teams, identify their day to day challenges, and see how they can fix those by building golden paths. A simple “hello world” version of an internal developer platform might just provide developers with the ability to get access to a build server to run their CI/CD pipelines, but that’s not where it should stop. Building golden paths is about identifying bottlenecks or repetitive tasks and building abstractions to streamline development cycles inside an organization.
Let’s talk about a couple of non-golden paths or “gravel paths” that organizations are stuck on today:
- Developers that are building applications for the multi-cloud world have to spend a lot of dev cycles and sprint budgets to add application resiliency features in their code. Avoiding single point of failure scenarios like node/server failures or cloud region failures involves additional design work, development cycles and QA testing before code can be pushed to production. This is all time that is not spent on building better applications for customers.
- Being on-call is often the most stressful part of the job for developers and SREs as they have to be on standby and ready to respond if there is an outage or an urgent incident like an application component going offline. On-call responsibilities might never go away with the “You build it, You run it” mantra, but, organizations should always learn from incidents and build abstractions, so that developers don’t have to worry about the same outages on a recurring basis. One such scenario is storage capacity management – we all know that an application component will go offline if it runs out of storage. While this might be an easy fix if your underlying solution and StorageClass allow online expansion, it will still result in a developer or SRE getting paged in the middle of the night – which can lead to burnout and unnecessary toil.
Portworx helps build Golden Paths for Internal Developer Platforms
Let’s talk about how Portworx helps pave over those gravel paths and build golden paths for your organization. This is not supposed to be an exhaustive list of golden paths that you should have in your internal developer platform, but it gives examples of paths that are essential for reducing toil on developers.
- Native High Availability and Replication: With Portworx high availability, platform engineers can create golden paths by configuring custom storage classes on your underlying Kubernetes clusters with different levels of replication factors. When the user deploys a new stateful application on the Kubernetes cluster, they can rely on the underlying platform to replicate their data across different nodes in the cluster. This eliminates the need for developers to maintain multiple copies of their data at the application level – thus freeing up cycles needed to add that logic in their application code or configurations.
- Automated Data Protection: Platform engineers can leverage Portworx Backup to configure namespace label based backup jobs, which allow developers to trust that the applications that they deploy in a namespace will automatically be backed up as long as they use the right label when deploying the namespace. A different variation of this can be the automatic creation of the namespace with the required labels, when the developer uses their internal developer platforms to deploy their apps or uses GitOps methods to deploy their apps on a target Kubernetes cluster.
- Consistency: As researched in the 2023 State of Production Kubernetes report, 69% of the respondents are already using more than one Kubernetes hosting environment. This includes cloud providers like AWS, Azure, GCP, and also on-prem environments for bare metal, virtualized, and edge deployments. When deploying to multiple environments, the internal developer platform is supposed to abstract away the differences between environments and allow developers to use a single way to build and deploy their applications. Platform engineers can’t achieve this out of the box, as each cloud provider and on-prem infrastructure stack will have its own set of unique capabilities. This creates a lot of confusion and overhead when trying to build unified platforms. Portworx being a cloud-native storage solution provides a consistent experience regardless of the underlying cloud, on-prem infrastructure, or underlying Kubernetes distribution as long as it is CNCF conformant.
- Automated Storage Capacity Management: As we discussed earlier, being on-call is not a great experience. So, let’s make being on-call as easy as possible! Portworx Autopilot allows application teams to create custom rules, where Portworx automatically expands their persistent volumes, if they cross a specific threshold configured by the developers themselves. So, their applications never go offline because they ran out of storage! Portworx Autopilot also allows platform engineers to configure a cluster wide policy to keep expanding PVCs across all namespaces, so storage is not one of the issues anyone needs to worry about.
- Disaster Recovery and Business Continuity: Rack failures, datacenter outages,cloud regions going offline, and natural disasters are all events organizations need to be ready for when designing their disaster recovery and business continuity strategies. One way to do this is by using geographically distributed managed databases in the cloud, where your data is outside your Kubernetes cluster – but this leaves organizations vulnerable to cloud lock-in and additional complexity, as they might have to find a unique solution for each database or data service they might use in their microservices based application architecture. Portworx Disaster Recovery is a Kubernetes native and true disaster recovery solution that can help organizations plan for disaster events and build synchronous and asynchronous disaster recovery solutions for their applications. Platform Engineering teams can build and maintain the production primary and secondary Kubernetes clusters, and when developers deploy their applications as part of their CI/CD pipelines, they are automatically added to the migration schedules so developers don’t have to worry about configuring complex DR solutions on their own. Portworx can also help build these DR architectures as part of test and staging environments, so developers can validate and observe their application behavior during a simulated disaster event.
Conclusion
Building an internal developer platform and the practice of Platform Engineering has enabled organizations to not only take a step back and identify bottlenecks, but also dedicate budget to improve the developer and operations teams productivity by building golden paths.
As Jeff Bezos highlighted in his startup school talk , just because the brewery in Luxembourg generated their own electric power, didn’t make their beer taste better. Similarly, just because your developers can build extra features in their application given more time and resources, won’t make the application serve its users better. Organizations whose purpose is to build better vaccines, or build electric cars, or build the next generation of financial infrastructure should focus on their key differentiators, innovate, and add value to the community instead of spending time and money on things that add more undifferentiated heavy lifting by their teams.
If you want to learn more about the next steps, watch this webinar to see how you can bring your Platform Engineering practice to life with a Data platform.
