Internal Developer Platforms (IDPs) like Humanitec are a way to enable self-service for any developer. Let’s zoom in and look at how a frontend developer would use such a platform on a daily basis. Throughout the article, you can find video interviews with a frontend developer veteran who has been using Humanitec for several years now. He’ll share how front-ends’ workflows change with the introduction of an IDP.
We’re sitting on a pretty unique set of data by now. Our surveys regularly reach thousands of users, our customer success teams look at literally hundreds of setups in detail every year. That gives us good insights into how frontend developers across different org sizes work. We’ll be telling the story of Aziz, a frontend developer specializing in ReactJS - his case is representative of most frontends out there.
What do we mean by “self-service” for frontend developers?
Talking about self-service in this context might need a little bit of clarification: we mean self-service in anything that touches the operational elements of app development. For example things that go beyond writing some code and pushing a new image to the CI pipeline. This might include adding environment variables, trying to understand what changes were introduced between environments, spinning up a new pr-environment, rolling-back, searching through logs. Really anything you need to do to get your app from idea to production.
Size doesn’t matter
Interestingly enough, the reality of front-end engineers in the deployment process is fairly similar throughout teams of different sizes. They’re usually kept away from it. If there is something to be done, they have somebody that helps them. They can rarely self-serve infrastructure directly to run their apps and services. They are highly dependent on others and this blocks them. Some are used to simply sending their code off to a DevOps or backend engineer to be deployed and don’t even think about it.
Aziz puts this powerfully: any update of an image in his non-IDP setup would require someone from operations to do that for him. He would have a local setup of all the microservices that his front-end depends on to try to mimic the behaviour in the cloud. If the deployment failed, that meant a manual roll-back, another change. Literally back and forth on Slack hoping the Ops colleague wouldn’t leave to vacation at some point. Which would mean you wait for two weeks.
The company back then was using Jenkins deploying to Kubernetes. He knew that if you pushed to dev there was an image build, but what happened after was a black-box. Lots of messy scripts that some guy wrote would update images into one cluster he had no touchpoints with. Context of how the app ran in production was basically not given at all.
Even seemingly simple procedures such as adding an environment variable like a new GoogleMap-Key was hard. This was done by somebody else you had to go to and brief, on an environment by environment basis. “They said we do DevOps and it looked ‘automated from the outside’. They called it continuous deployment but it wasn’t continuous at all. It was manual and slow and I was isolated from what happened under the hood”.
How front-end developers use IDPs
Aziz, as many front-end developers, describes the experience working with an Internal Developer Platform as entirely game-changing. The key was not being dependent on others anymore but literally being able to operate apps on his own.
The local machine and the production environment are suddenly right beside each other. Aziz would now only run the service locally that he immediately worked on. This service locally runs in a Docker container. Changes are deployed with a simple git-push to the CI that builds the final image and notifies Humanitec, which in turn updates the correct environment following automation rules. Integration and other tests on how the individual service works in the fleet of the total app can now be performed in production-like environments.
But the actual self-service comes into play if there is anything to do that goes beyond the simple update of an image. Adding an environment variable is as simple as navigating to the respective microservice in the correct environment and entering it using variable substitution, which can directly pull available endpoints from the resource management of the platform. The system will take care to dynamically create manifests at deployment time, injecting the correct dependencies as secrets, based on the context of the environment.
You also have all the information you need to understand how your service runs in the context of all other services. Visibility is key. You know what’s running where, in what version, you can stream error messages, apply diffs to see what changes were introduced between environments. Or even being able to spin up new environments on demand.
Aziz puts it brilliantly: “It is as if you have a colleague constantly helping you out but you are in full control of everything”.
Does an IDP restrict developers?
The plain answer is no. IDPs take front-end developers from a situation of almost zero context into one where they have full visibility into how their apps run. IDPs are abstractions that provide transparency.
Meaning at any point in time the individual developer can go deep and understand the services, dependent resources and the interplay between application layer and infrastructure. Want to change low level configurations in Helm? Go for it. Terraform on top of your daily Typescript workload? Knock yourself out. It matters that developers understand how the code they write actually runs. Complicated setups that in the end can only be operated by subject matter experts don’t help anybody. That’s the dark side of developer self-service, IDPs are the bright side.
This blog post is part of a whole series on how software engineering teams work with an IDP. Check how product managers, QA and backend engineers use IDPs in their daily workflows.
