Intro
The role of Platform Engineer as evolved through the ages. I’ve gone through all the names: Sys Admin, Infrastructure Engineer, DevOps Engineer, Cloud Engineer, Platform Engineer, but it all comes back to the same aim which is to help deliver a product to market as quickly, securely and easily as possible.
As Platform Engineers, we build toolchains and workflows that empower engineers to iterate effectively and provide a platform. We enable self-service capabilities to improve developer velocity and therefore speed up product to market which is the end goal. A typical frontend developer just wants an environment that comes fully stacked with everything they need to deploy their code, not necessarily caring where it runs, it's in our best interest to make that a self-service want.
Here are a few topics I'd like to share that have improved Developer Experience generally speaking and in a recent engagement I was apart of.
Do Kanban... If you can...
If you can, try and implement a Kanban framework for your team. A team of platform engineers can be a very reactive team. Quite often requests come in ad-hoc and we find ourselves prioritising requests and requirements in real-time. If we used the SCRUM framework –we would constantly break the sprints. The product informs the infrastructure, the infrastructure does not build the product. The move to Kanban really helped us in a recent engagement we were on:
- We had 4 columns: backlog, ready, in progress and done
- We also had an expedite lane for high priority tickets (with an agreed expedite policy)
- We had telemetry such as lead time (backlog-done) and cycle time (in progress-done) to keep the PMs happy along with t-shirt sizing our user stories
- Rituals included replenishment, retrospective and a general catchup and our cycles were typically 2 weeks
CRUD* is not a bad word...
If done properly, you can grant developers access to what they need in a lower environment. Instilling trust is crucial to building a good developer experience.
In a recent engagement I was on, Developers had access to manipulate services in their respected kubernetes namespaces (deletion of pods, rollout restart of deployment etc., viewing logs and port-forwarding to test api functionality), and when they needed to revert back it was all Infrastructure as Code, so running a build put everything back.
We leveraged istio services and one of the developers needed to inject some faults into one of their service’s API to test failure and how the application would react (would it drop the event or place it back into the messaging queue until the service was available). We made it possible for the developers to set fault injection up themselves by CRUDing an Istio VirtualService alongside the main Istio VirtualService to abort requests based on a matching correlationId header so the application itself could still be active but drop connections based on the header value.
Harmonise Cycles and communicate cycle goals…
Harmonise cycles and communicate cycle goals. Regardless of what framework you use as part of your ways of working, attempt to plan your cycles and the developer sprint cycles in parallel. That way there is no misalignment of priorities and there is visibility of work on both sides.
I was in a recent engagement where the infrastructure squad had priorities of decommissioning old infrastructure and the engineering squads had the need of new infrastructure to be provisioned. This resulted in a clash of priorities and we had to reset and realign expectations of each team which slowed down work. You could go further and have representatives at some of each other’s rituals but typically alignment of goals and priorities adds enough clarity
Write yourself out the role...
Write yourself out the role to focus on other awesome stuff. PaaS where possible. Treat the platform as a product. Version control it. You can’t build a platform and decide it’s finished. Don’t forget maintenance, enhancements and features. If developers need a repository with a set of pipelines and build validations etc. Modularise it and provide it as a service. Seek developer input and understanding how developers work. Don’t build the product and hope for the best.
In a recent engagement, the developers were using Azure DevOps to store, build and deploy their code. We managed to leverage the ADO provider in terraform and wrapped everything into a module, the developer only needed to specify the name of the repository they wished to build and the module built out all what was needed including the repository, pipelines and build validations.
Have documentation in place such as a runbook or platform guide for the developers to use. We built out one recently to perform actions such as creating pipelines, adding tools to build agents, creating kafka credentials and topics etc.
When building out User stories always have an acceptance criteria of documenting where appropriate so nothing gets left out. Having this in place enabled us to focus on other areas of improvement and optimisation of the infrastructure stack (reducing costs, optimising for performance, fun spikes etc.)
In Summary...
- PaaS where possible. Treat the platform as a product
- Seek input and harmonise cycles and communicate
- Remember that the platform is the golden path to developer productivity. I said originally that we build toolchains and workflows that empower engineers to iterate effectively and provide a platform. The developer experience is built around the toolchains and workflows developer use.
No comments:
Post a Comment