Over the weekend, I visited one of my favorite grocery stores to pick up one item, my favorite fruit e.g star fruit. Because of the location, the grocery star started to implement parking validation so folks would not abuse their free parking deck for extended periods of time. As I just had a handful of star fruits, I decided to use the self-checkout. This was my first time buying produce via self-checkout. I certainly had some challenges, understanding if I had to weigh the star fruit vs if they were charged per fruit. Usually, a cashier would take care of that complexity for me. This time they were going by weight so worked my way through that complexity. Validated my parking and then as I was ready to exit, dropped my parking ticket under my car at the automated parking station exit. A few choice words later managed to fish my parking ticket from under my car and was back on my way.
These near-failures in a mundane task such as picking up fruit from a grocery store do have parallels to our professional lives. A big trend in the past several years is developer self-service. With the rise of platform-as-a-service’s [PaaS’s] in the decade past, developer self-service is a cornerstone of a modern development experience. Though because you are providing or being offered self-service, is that experience a better experience? In my shopping experience, I might argue that I did not have the best experience over the weekend. Providing self-service in the name of self-service a good experience? Developer self-service is a paradigm based on balance.
The Balance of Self-Service
There is a balance in developer self-service. You need to balance choice and convention; this can be viewed as also balancing innovation vs control. Software development is an exercise in constant innovation. Paradigms, frameworks, and approaches are always up for change as the innovation flywheel continues to turn. Though there is the connective tissue between approaches and this is where convention comes in. For example, building a Docker Image, thanks to Continuous Integration and your friend the Docker File, this task is pretty mundane. A team could leverage a blueprint or archetype to build their source code and create a Docker Image and this is considered building by convention.
Though that mundane task can be opened up to choice. What if you want to leverage something like a distroless base image, now you will need to continue to edit the mighty Docker File. The lines start to blur between choice and convention. The choices can be plentiful as you start to layer in confidence-building steps such as test coverage into your Continuous Integration pipeline. This is just the packaging of your application; not even touching the functionality of the application itself. The functionality of the application can be open to almost infinite choices in how to create and deliver said functionality. Balancing both the choice and convention radio dials can create complexity.
Is Developer Self-Service Creating Complexity?
For most of my adult life, I have been shopping for myself. Though crossing the finish line at the grocery store has changed and was challenging for me, an experienced grocery shopper. Oddly enough the grocery store I went to piloted a “just walk out” technology where you don’t even need to interact with the self-checkout. Other stores I visit have some sort of self-service experience also; from home improvement stores to warehouse clubs that I am a member of. Though each experience is different. For software engineers, self-service is different from organization to organization due to the sometimes bespoke nature of Internal Developer Platforms [IDPs].
Building an Internal Developer Platform is not without its complexities. In a recent piece in SD Times, there are multiple fallacies when creating and maintaining an Internal Developer Platform such as the fallacies of static technology and administer choices. If you are building an Internal Developer Platform, user empathy is crucial. For a developer, they most likely have not deployed their applications outside a local or development-centric integration environment. So tossing a multiple-step self-service process for a large swath of non-functional requirements such as connectivity in front of a user e.g the software engineer can be challenging for the internal customer. Similar to someone walking up to a self-checkout for the first time, even though they have bought groceries before e.g have written features that have been deployed, are used to a certain expectation of some expertise, for example, a cashier or in the software world a release or DevOps engineering helping out.
Even technologies out there such as Kubernetes, viewed as a great equalizer of development and operations since both teams can speak YAML, is not without its complexity. Just because you can read a YAML does not mean you can author a YAML. A problem with any configuration-based system is an inception problem. With Shipa, we are focused on solving these challenges.
Shipa, Balance Innovation and Control by Convention
At Shipa, we have been laser-focused on delivering and scaling Internal Developer Platforms that you can offer your internal clients. Shipa is part policy engine and part abstraction layer to provide the innovation and control that is needed. We are striving to make Kubernetes an afterthought.
From a software engineering perspective, non-functional requirements such as ingress/egress connectivity are delivered via convention e.g a Shipa Framework.
In an upcoming talk at DevOps Pro Europe, we will be discussing these concepts in detail. Hope to catch you there and make sure to sign up for Shipa, today!