Platform Developer

Developing to a Platform

For the context of this post it is developing apps in a platform not for. As we look throughout how we have developed the term platform is over used. When we look back we had mainframes. And mainframes are platforms. And with some of my conversations on Twitter they were the original platforms. And in the time of COVID these platform developers became in high demand in many states. Never in my life did I expect the call to come out, “looking for COBOL developers”.

We evolved somewhat away from mainframes. But they never went away. As cloud is growing in popularity both public and private we see the rise of platforms. Each of the large cloud providers have “Platform as a Service” or PaaS offerings. They are somewhat easy to use. The ability to write a cloud-native application faster and easier than before. With in your data center(s) you have some other offerings like OpenShift and Cloud Foundry. Now Kubernetes is the new hotness and most offerings are a flavor of it. But with these they are all at the end of the day a platform. Some are productized and others are still open source.

When I first got my full on emersion in the private cloud platforms it was with Pivotal Cloud Foundry (PCF). Now known as Tanzu Application Service (TAS). I had used Azure before, I come from the Microsoft stack. But PCF was a new experience. My work on that platform what cutting edge. We went to production with Steeltoe being in beta. And our build packs having very frequent updates. But my experience as a developer was one of the best I could remember. I didn’t worry about configuring IIS. I wrote my code and at times I did the infamous cf push to get my code to the platform. At the time I never thought I was developing to a platform. I didn’t code anything less, and I added one extra file to my project manifest.yml.

The company I worked for at the time was kicking off it’s partnership with Pivotal (now part of VMware). I had wrapped up my last large engagement and I had to go back and enable others to be cloud-native developers. Sound simple enough. Talk about how easy it was to crank out applications. Leveraging some key features like RabbitMQ with a few clicks. Not waiting on infrastructure to provision me anything.

But what I got was a lot of push back. I head terms like “I am not a platform developer” and “I don’t do SaaS”. To even straight up “nope not gonna learn it and bet my career on it”. But there wasn’t much to learn. Unless coding best practices were new to you. The fact of the matter there was this stigma around developing to a platform. Like it made you less of a developer or technologist. I will admit I had a few people eager and willing to learn it. But the vast majority of my staff fought it. So the months our team took putting together a training program went nowhere. Of the hundreds of developers and testers little over 30 took the course. Almost impossible to say you can deliver on a cloud-native project.

But getting back to what it took to develop to this platform. I had to know about newer concepts. Circuit breaking, scaling / descaling and service discovery. But did it take away from my code? The answer is “no”. I actually only added one file for the platform as I mentioned before. But beside that ONE file there was nothing else platform specific. Adding circuit breaking to a monolith is possible. Sure service discovery in a monolith might be overkill. What I learned from this is that developing to a platform pushed newer concepts. These concepts where specific to one platform but to most others as well.

The change in learning how to develop to a platform is not as scary. The learning like anything else in technology is never ending. But having a stigma on tying yourself to a platform needs to change like technology does. Developing to Service Fabric or PCF doesn’t make you less of a developer. It makes you a developer focused more on outcomes less on blocking and tackling.