Originally posted on the Israeli Tech Radar on medium.

TLDR; Just when we thought we’ve got it figured out! We learn there’s a better, faster way of doing things, frameworks, abstractions, and methodologies invented to make our development experience easier, and help us during our journey to building a platform. But…Do we really need one?/Should we adopt one? What impact will that have on our product? The following post will try to tackle some of these questions as we explore building a better Developer Experience.

▶️ Intro

In the past 2 decades of my experience moving from Ops 2 Dev, I’ve switched between many work styles and frameworks, mainly due to the nature of my work as a consultant.

In some cases, the frustration of onboarding a new platform (if there is one) might take 1–2 weeks before I start contributing to the client’s effort, and in some there are none, and if we’re lucky and it’s a small group of people we find a workflow which scales until the next phase which would happen when our team grows from ~2 hand-full to more …

Why am I writing about this❓and why now❓

Spoiler for my talk on CloudNative Dev’s

To be honest, I’m preparing a talk for our annual RadarCon 2021 on Cloud Native Dev’s, and considering it is something I’ve been working on all my career, mainly because of my operations background which started with zero understanding of what an IDE is or Source control for that matter, to the point that my first go-to tools are Git & vscode.

BTW, the evolution from it-ops to dev without me being aware of it became a big advantage nowadays considering the nature of IT automation and how it has become programmable …

What Changed❓

Besides the fact that we aim to be faster, higher, and stronger ;) ?, in 3 words or abstractions, Cloud, Microservices, and** Modern Architecture styles** such as event-driven/serverless applications.

IMHO in the early stages of microservices we “ops guys” were so excited by the idea of running microservices we almost forgot how to connect them together …

Once we did that, all the operational aspects of operating them seemed to have consumed us with various deployment schemes and tooling which really added a TOIL to the development process — which not many were/are willing to pay … — we called that TOIL -> Yak Shaving ;)

🦬 Yak Shaving ❗

Some call this TOIL e.g — Carlin Vieri is credited with coining the term Yak Shaving back in ’00 based on the plot of an episode of Ren and Stimpy.*

Personally, I first heard this term in ChefConf. There is even a short video of the 2018 opening which really describes the feeling they had internally with “Yak shaving” and how their automation and operation helped reduce the TOIL off their developers and I’m sure there are many more examples out there.

eveydayconcepts.io

Many of these Yak Shaving yield tools/frameworks and even architecture styles which attend to those operational TOIL’s we hate paying, a great example is serverless or managed services in general.

As an Ops guy from raking servers to writing terraform code, engineering wasn’t something I had to master in order to stack 40 servers in a rack … Nowadays in order to run a cluster, I first need to provision it connect it to the correct DNS (considering there is always more than 1) etc … It was “shave away” or “engineer it”!

Some say pressure makes diamonds (but not overnight … 😉)

How did this happen❓

Well, 1st we do the best we can … until we know better.

“Do the best we can until we know better. Then when we know better, we do better.”

We look at the big ones who seem to have solved the problem … and see:

• The Cloud — 👍🏻
• Microservices — 👍🏻
• Docker — 👍🏻
• Kubernetes — 👍🏻
• 100’s of CNCF projects — 👍🏻
• Managed / Self-managed … — 👍🏻
• *aaS — 👍🏻
• Or god forbid … DevOps as a Service — 👎🏻 (I had to …)

👥 Luckily we have a conscience & compass

As we build our radar based on our customer and our collective experience within each domain, we get a chance once in a while to look ahead, what’s next and what are the unicorns doing differently, which makes them a success story (focused on the technological aspects of course).

When we all look at a global scale, it isn’t a surprise our short-list of companies we look at are Google, Facebook, Amazon, and not surprisingly companies such as Hashicorp which just joined the stock market.

What do all these idles have in common that we don’t? Besides the obvious, which is “their way of doing it”?

▶️ **A platform **❗

(And for the Netflix’s out there — you’ve built it 👏🏻👏🏻👏🏻 , I’m an Israeli consuming content on-demand around the world with 0 interruptions !)

Building A “Platform”❗

A great example of companies that “have a Platform” are companies such as Hashicorp and Netflix. And I didn’t take these two examples by chance: one is a consumer product and the other is B2B, both companies have Open Source libraries sharing their way of handling TOIL, and in many cases how they avoid it.

In our previous radar, we had Greg Burrell, Senior Reliability Engineer, Netflix talk about their “travel in time” going from a DVD rental mail company to fully global and digital.

Netflix’s FullCycle — platform approach

Their experience brought them to invest in the “FullCycle team” model which enables developers to focus on their work and eliminate/decrease the TOIL that comes with it.

From an operational perspective, I was very impressed with the series of posts on how they tackled a regional outage on AWS, and how that pushed them to go multi-regional, I couldn’t fathom these aspects and their impact on their internal consumers — the developers.

The 2nd company I mentioned is Hashicorp (I’m truly unbiased or sponsored by neither), which has taken a similar approach with tooling.

If you sum all the open-source Hashicorp tooling together without including their online integrated offering you get — A platform — and you will definitely not get fired for doing that, but you still need the training and implementation process for that platform.

We all went full-stack when we felt the pressure on the Backend and the notion of Microservices started to redefine the way engineering teams worked.

As an Opsguy, I found myself in the Developer’s seat, with the knowledge of what it should look like after you get to par with object-oriented thinking, However, I was lacking the tooling that can get me to be as fast as I can go … which is a necessity of scale ⚖️.

A great starting point is the following post of Five proven approaches for a better Developer Experience in your organization by, Jacob Bo Tiedemann and Tanja Bach which really put things into perspective for me in how to get started and clear all the clutter.

🛠️ Tools that may help you build your Platform

As engineers, we’ve always looked for frameworks to solve our problems.

• I see companies build their Platform around Jenkins, Gitlab, Bitbucket, CodePipeline, and many others, it seems like everything is around the CI solution, not many have shifted in priorities and implementation — that is the number one cause of confusion and context switch.

• Review the Developer Journey — Define the “tough points”

• The ones that influence your KPI’s the most!

• Separation of concerns or a better definition of Roles and Responsibilities between/within the team — will sure help [ see team topologies ]

Flexibility / Adaptive process:

Review the impact of one of the following workflows and see if it suits your team ideas such as:

• IDP Internal Developer Platform https://internaldeveloperplatform.org/ for a good starting point of defining your KPI’s

• Backstage (by Spotify) -> I’ve been test driving it lately and is used by a few customers, what I personally liked is the mission statement

“Backstage makes it easy for one team to manage 10 services — and makes it possible for your company to manage thousands of them”

IMHO, You don’t have to adopt backstage to read into the principles of gluing all the information together.

• Gitlab with their AutoDevOps … / Github actions + Many Other like **Hashicorp** as mentioned above

• They provide a flexible enough starting point

• + Don’t murder your Jenkins just yet (he got us this far…)If you want it can scale!

To Conclude

punch-card computer from the early 80’s

If you time-traveled from the ’50s with your “punch-card in hand” and fell into 2021 — Everything (well, on not much depending on how you choose to look at it …) has changed -> there’s a linear learning curve — but the principles of computing haven’t changed (it just moves — like the cheese).

monolith to microservice — nowadays

For those of you working in the industry for the past 20 years, you might have a few techniques and frameworks to master but we’ll get there … — it’s already here under our noses …

The approach of adopting existing tools has always been a guideline as long as they adhere to my needs and of course the list of cons must be short.

The **agile approach **which is also very optimistic (once you’ve removed all the opinionated tooling), helped magnify the principle of “do one thing well”, and if the sum of the things we do — and I am sure in many cases it’s only a majority of them. Everything can be improved and automated to the extent of our time and thoughts of the process, from what I’ve learned, finding them will best define your Internal Development Platform — that should shortly boost your Development Experience.