Five years ago, I wrote in our very first blog:
In working with building infrastructure for large data centers over the past 15 years, I’ve observed that…Infrastructure provisioning today is done distinctly and separately from application provisioning…This complicates deployment scripts, necessitates the need for machine infrastructure orchestration tools such as Chef, Puppet and creates a static environment where “adds, moves and changes” of the infrastructure are complicated.
If an application needs storage capacity, it should be able to self-describe the capacity it needs, and dynamically and programmatically control the requirements. Provisioning should not be ticket-based or done by way of people getting involved. With Docker, an application’s environment, its libraries, and dependencies are self-described and self-provisioned. Then why stop there? Why not go all the way and self describe the runtime resource and infrastructure requirements?
At the time Docker was king of the world and Kubernetes was yet to be even in its 1.0 version. But it was clear to me that infrastructure, especially storage infrastructure, needed to radically change to keep up with the demands of how modern applications are being designed and deployed.
Why was that? What was actually happening? Was it Docker, Containers? To me, it was the desire for a new application-oriented control plane to manage how we now design, develop and deploy distributed applications. Up until people started using containers to package their applications, they used machine-centric constructs, like VMs to manage their applications.
At this time, developers started realizing that machines are not the center of the universe, but instead that their applications are the most important thing. They need to think application-focused, not machine focused. And ironically, containers allowed them to break out of this mindset. This defined a shift from a machine-centric control plane to an application-focused control plane. That is where Kubernetes comes in. Kubernetes understood the real transformation that was about to happen. And it started to define a rich grammar that could orchestrate this new application oriented control plane – the cloud native way of doing things.
But runtime infrastructure like storage needed to change to support such a new control plane and its new grammar and the new workflows that took advantage of this control plane.
It was our vision to build, along with my co-founders Murli Thirumale, Vinod Jayaraman, and the rest of the Portworx team, a data services platform that would move storage and data management (data availability, DR, shared access, backup, security, migrations, etc) into the background so that users could simply focus on their application development – in a container and service-oriented way. This new intelligent infrastructure needs to take care of itself and offer a developer-friendly self-service experience for the distributed, service-oriented application needs. This needs to be done in such a way that the runtime infrastructure is fused with this new control plane, and not an external resource that is remotely connected to it. Read my co-founder’s blog on how we do this here.
Today, I think that we’ve achieved this vision and the proof is what the experienced teams of our customers have been able to build using Kubernetes, Portworx, and other pieces of the cloud-native stack. Companies like Royal Bank of Canada who run mission-critical apps on Kubernetes across multiple data centers with true zero RPO disaster recovery. T-Mobile who pushes the envelope on what a modern, application platform can deliver for world-wide development teams, reducing application deployment time from six months to hours.
It is against this backdrop that I am thrilled to announce that Portworx is joining Pure Storage to form a new business unit dedicated to accelerating customer’s digital transformation by delivering a Modern Data Experience for any app running on any cloud and any storage infrastructure, at every stage of the Cloud Native lifecycle.
…Any App: Stateless or Persistent, Local or Geo-distributed…with security, HA, backup, and DR
…Any Cloud: Multiple Public Clouds, On-Prem or Hybrid, Core to Edge;
…Any Infrastructure: Managed k8s services, cloud storage infrastructure, bare metal servers with SSDs or HDDs, or Enterprise Arrays;
…At every stage of the cloud native journey: from development to test to production to containers-as-a-service at global scale.
Having worked with the team at Pure Storage closely over the past few months, I stand by their commitment to not just continue offering Portworx as a standalone product– serving customers running solely in the public cloud and on top of non-Pure Storage infrastructure– but to accelerate the innovation that Portworx customers are used to and expect. Culturally, Pure also shares Portworx’s fanatical commitment to customer support so expect to continue engaging with Portworx as a true partner in your digital transformation, not just as a vendor.
So what happens next? The entire Portworx team is laser-focused on delivering on the Portworx roadmap. We are working on some very exciting capabilities to easily manage the most popular cloud-native data services like Cassandra, Kafka, Elasticsearch, and more. We are deepening our integrations and partnerships with the leading Kubernetes platforms in the cloud–EKS, AKS, GKE, IKS– as well as multi-cloud platforms like RedHat OpenShift, Rancher, Anthos, and Tanzu. And we continue to invest in more scale, more performance, more intuitive user interfaces, and more use cases.
Looking back at the last five years, I couldn’t be happier for all that Portworx has accomplished. And I can’t wait for the next five. I hope you’ll join us on this journey.
More About Today’s News from the Pure and Portworx Execs
Charlie Giancarlo, Pure Storage Chairman and CEO
Matt “Kix” Kixmoeller, Pure Storage, VP of Strategy
Murli Thirumale, Portworx Co-founder and CTO
Vinod Jayaraman, Portworx Co-founder and Chief Architect