Creating a Vending Machine

When I joined my current employer I moved from being a Software Engineer to be a Product Owner. Switching from having someone leading the roadmap towards the product vision I was not myself in the driver seat.

I had no idea on how to start, so I started reading a lot of books on the topic of product development and I took some courses at Pendo. I got an understanding that working with product development and what makes the deliverable of high value for users ties to just that, users.

I went from being a hyper-focused engineer with eyes on targets, to starting up conversations with people working with development instead. Although it was not apparent that Cloud was a hassle to start working with, I understood that patterns that had been enforced by the platform team that was considered "best practises" in fact held many engineers stopped from starting to develop projects fast. They had to wait for the platform team to pick up the ticket in ServiceNow and provision the infrastructure they needed.

To be fair the platform team had been through a lot since they moved a lot of infrastructure to their own landing zone from an already existing one. On top of carving out existing environment to it's own, the requirements for the organizations manufacturing is that private networking is used. This was new to me since I came from the serverless world, I didn't need EC2 with a private link.

It became apparent that freedom for engineers was the highest priority for the roadmap ahead.

We started the development with "Subscription vending". The concept was aimed toward removing the ticket way of working towards a self-service environment where engineers themselves can create an account/subscription with all infrastructure required for private networking, since that was a common way to build.

The design took in concepts as Domain-driven-design, with a workload application mantra. Cloud Adoption Framework where the Landing Zone is introduced. Self-service with GitHub as a code collaboration platform. RBAC with tied to each new account/subscription. Open source for IP address allocation strategy.

Now the first release made engineers being able to create accounts/subscriptions with a self-service capability by opening a Pull Request in our repository whenever they needed. They no longer needed to wait for us to first, I creating the subscription, I having to ask my colleagues about them moving it into the right management group and then someone else creating the different Entra-groups that had different rights depending on the roles people had, Owner, Contributor or Reader.

This took away the manual boring work to instead empowering engineers. We can spend time in more fullfilling development and engineers won't experience frustration.

The next move was to add the private networking-as a service in to the subscription vending. Private links, Virtual Networks and subnets were long something the platform team created for engineers. By creating clear README's of instruction for how you request different network resources, it won't be hard to start developing a project.

We started seeing more teams choosing Cloud before OnPrem. But we still had a lot of non intuitive policies that stopped people. We then introduced the Online management group in our landign zone. The management group Corp which before was locked down environment cut away from all potential of exposing our application to outside sources was now not a hard requirement set by us. If engineers had web applications that they can protect through a CDN instead of Virtual Networks, it should be up to them to make the decision of designing their architecture differently.

The landing zone now had Corp with Sandbox, nonprod and prod. The Online had Sandbox, nonprod and prod. Fine and dandy. But what about the DevEx with this new concept? By talking to users we understood that creating projects was not so easy after all, although much documentation existing from the Cloud providers side.

We started the next Epic called "Golden paths". A major OKR communicated from management was "Creating excellence by Software". I came from Serverless, how can we make it happen here? How about we create some "golden paths" that work as boilerplate script that users can quickly spin up, just as easy as the vending machine. We chose Function apps as the next target. That is close to how much of "Server"-less as one can get. Pay only for what you consume, compute only based on events.

We investigated different CLI tools that works almost as a git clone, but on a repository level and with prompts as features for engineers to customize their own projects. If they get prompted with "What do you want to name your project?" and other questions like tags, we can make the project development happen even faster.

With that, the vending machine and golden paths made the organization choose Cloud, it was now not locked down, but freedom under boundaries. This is what software engineering should be, fun and motivational to learn by doing.

How was this done in code then?

Azure provides azure-rm modules in Terraform, users then edited the YAML-file where they wanted to place their new account/subscription. We created the repository folder structure to resemble our Landing Zone. We imported existing Virtual Networks so that nothing would to clash with it. We use a Pull Request flow where at least one approver needs to be added before it can be meged. We used Azure IPAM as IP address manager.