Cloudnative

Are you failing enough?

The process of creating software, compared to other manufacturing processes, is a little bit special. One unique property of a software product is that it can be changed easily and (relatively) cheaply.

Over in the physical world, changing a product is not so easy. Supply chains, inventory, machinery, whole factories, who knows what’s involved that is either difficult to change quickly and/or prohibitively expensive to change.

So what about this failing more often? Well if you have the ability to quickly change your software product, you can also run A LOT of experiments!

You build it, you run it... but what exactly?

“You build it, you run it”, easy to say, but, depending on your developer experience and platform capability… not at all easy. What am I expected to “build” and what should I “run”? Let’s take a look.

Let’s start with this overview that I show teams I engage with during their onboarding and where their responsibilities begin and what not to worry about (but can still affect them of course).

Your organization could use a cookbook

That is… if you don’t have one yet of course.

A self-service effort is not complete without proper documentation. You could store that inside the repository with the code that makes up the service, but that could make it harder to find. And what if you have a bunch of services that all have their own docs? It’ll be completely scattered. To make knowledge easily find-able, and even searchable, a central knowledge base is the solution. In other words… a cookbook!

Tactical versus strategic coding

Vacation time for me generally means reading time and for this occasion I brought “A philosophy of software design” by John Ousterhout with me. So over the course of a few warm summer evenings I read my way through it and here are some thoughts and an interesting thing I picked up.

Many things that the book covered were more or less in the tool belt, a refresher is always nice and I agree with most of the things the book describes.

Paved road - Templates

In my previous post about paving the road to production there were some ideas around offering deployment pipelines as a service in your organization. In this post, we’re going to take it up a level and have a look what we can do to remove even more friction, specifically when creating a new app from scratch.

The process of creating a new app generally looks something like this:

• Pick runtime and language
• Pick any suitable frameworks
• Add any additional dependencies for stuff like databases, single sign on, logging, etc.
• Integrate all the above
• Make sure it all works locally
• Set up configs for various environments
• Set up a pipeline
• Deploy to dev/test or other environment to get pipeline working
• Create value for your users ✨

Before you go ahead and start building something generic that you can quickly duplicate for new apps, you should think about what you are willing to support and what level of customization is going to make the most sense.

Paved road - Deployments

Speeding up developer teams by eliminating waste and busywork can come in many forms. A huge step comes through automation, deployment specifically. Getting your app to production in an automated manner through some sort of pipeline is a huge timesaver.

Given this automation, you can take it one step further by moving the creation and management of those pipelines one step up and offer ready made pipelines that teams can take from the digital shelf. These pipelines can be managed by the internal developer community or maybe a supporting team that already enables teams in other ways.