In this post, we explore the extremes between a centralised model and a completely democratised model, and we suggest a possible nirvana between the two. Platform Engineering is a hot topic right now - QCon London had an entire track devoted to it in 2023, PlatformCon 2023 saw a massive increase in attendees. It’s seen some huge success in places like Monzo , where the shape of a microservice is strongly defined by a platform team, and engineers use a single CLI command to generate their instance on said platform. This model is great… when it suits your organisation.

There is a tension that is constantly at play in software engineering teams - increase their autonomy to enable them to build without hand-offs, while reducing the same teams’ cognitive load to allow them to focus on delivering value. With cloud computing, shifting left on everything, and maturing practices that enable continuous delivery, teams now have the potential to build, run and operate every aspect of their applications. But with this potential, comes the very real threat of burnout, skill gaps that lead to poor quality products, unwanted risks or slow time to market.

Paved Paths. Golden Paths. Paved Roads. You’d be forgiven for thinking the industry already had these nailed down, a solved problem that has been spoken about for years in various guises. This is part 1 of a series exploring all aspects of Paved Paths.

We often build and deploy web applications specifically for users internal to our organisation. Azure Static Web Apps is proving to be an excellent replacement for Azure App Service in these scenarios. At a high-level the service provides you with a great set of features (outlined in the Azure release notes ) Globally distributed content for production apps Tailored CI/CD workflows from code to cloud Auto-provisioned preview environments Custom domain configuration and free SSL certificates Built-in access to a variety of authentication providers Route-based authorization Custom routing Integration with serverless APIs powered by Azure Functions A custom Visual Studio Code developer extension A feature-rich CLI for local development The desired experience?

In my previous post I touched on the things I learnt while migrating ARM templates to Bicep . Bicep also introduces the concept of modules to enable template reuse. I took some time to refactor a composite application that had already been converted from using ARM to Bicep templates, to use Bicep modules. This post will cover the things that I learnt by working through that process. Why modules? From the Bicep documentation :

You may have heard of Bicep , and you may be wondering how much effort it is going to take to move all your ARM templates to this new way of deploying Azure resources. I gave migrating from ARM to Bicep a go. This post will cover going from JSON ARM templates to shiny new Bicep templates that have no errors and don’t contain any warnings or linting issues! Why should you migrate?