Kubernetes Local Development, Building a PaaS, & Platform Personas

Dave Sudia, Senior DevOps Engineer at GoSpotCheck, joined Ambassador to discuss creating an effective local developer experience for Kubernetes,  migrating away from Heroku and building a Kubernetes-based platform as a service (PaaS), and how his team developed an understanding of all of the personas involved with creating a platform. Be sure to check out the additional episodes of the "Livin' on the Edge" podcast.

Key takeaways from the podcast included:

• GoSpotCheck initially ran their field management software applications on Heroku’s platform as a service (PaaS). This platform served the organisation well during the early stages of their business. As the organisation grew and volume of users increased the GoSpotCheck team migrated the underlying platform to Kubernetes for both scalability and cost reasons.
• The Heroku developer experience was very effective for engineers wanting to release code fast. The operational overhead of the PaaS was also minimal.
• Kubernetes is a good foundation on which to build a platform, but the GoSpotCheck team had to assemble various open source components in order to replicate the required PaaS-like developer experience and continuous delivery.
• Treating the platform as a product is essential for success. It must be designed appropriately, with all users identified and their requirements understood. It should also be staffed accordingly, with product managers, user experience, and engineering teams.
• Defining personas of all of the platform stakeholders has helped ensure that the platform has been designed and built in order to be as useful, and usable, as possible.
• Platform teams must realize they are not building a platform for themselves: their “customers” are other application developers and engineers within the organization.
• After running a survey within the development teams the number one issue raised related to the local development experience: "the way you could make my life more easier is to give me 64 cores on my laptop." The support teams were also unsure of how they could support the results of continuously delivered applications.
• The creation of the Kubernetes-based platform was divided into phases. The first phase explored was the local development experience. When components were identified, the team evaluated whether these could also be used in the next phase, which was building a continuous delivery pipeline.
• The development team is using Cloud Native Buildpacks for building their applications. Local development consists of initially building and testing services in isolation (using mock, stubs, and contracts), and then integration testing within a remote cluster using Skaffold for local-to-remote build and deploy. Edge Stack API Gateway Service Preview functionality is also of interest.
• Observability is vital for business and operational reasons. The GoSpotCheck team like Charity Majors and the Honeycomb team’s model for collecting everything and “slice and dice it every way you can” to find business-impacting problem.
• The GoSpotCheck CloudOps (platform) team made an early commitment to adopting open standards, particularly CNCF-backed standards such as Prometheus metrics (now OpenMetrics) and OpenTracing OpenTelemetry).
• Initially the CloudOps team ran internal services that supported these open standards, but migrated to commercial services as these became available and cost effective.
• When evaluating components in the cloud native ecosystem, "if you can wait six months then do". The landscape evolves rapidly.
• The engineering teams are investing more in progressive delivery, and are exploring the use of feature flags and canary releases. The ability to rapidly experiment in a safe manner can be a competitive advantage.