"...so hot right now!"
I'm a little excited for the recent surge in what for now I'm going to call declarative microservice architecture frameworks.
They're a concept that have organically emerged from deployment and infrastructure templates getting together and having a real long hard think about developer experience.
Early days
For the longest time we've had Terraform and Ansible as the industry leaders to declaratively manage infrastructure. But I think it's no big secret that the end result hasn't always yielded something we enjoy maintaining. Even in my own experience a few years back, I started with Terraform, believing it to be the best of breed choice, but quickly came to regret it and shifted over to Pulumi.
The biggest drag I personally found with Terraform was how hard the syntax fought you when you started to try and create standardized building blocks. That is to say: "abstractions" (a bit of foreshadowing).
Not to say that it's outright impossible to abstract with Terraform. But it doesn't take long before you're reaching for ambiguous built-in constructs, pasting a lot of boilerplate and doing painful & brittle find-replaces.
⚠️ By their own advice, Terraform urges you to try and remain as toplevel as possible because eventually looping and referencing borks its determinism.
Luckily for me, I was late to this game, so over I went to Pulumi where I could use normal language constructs to have a nice clean, strongly typed API around Google Cloud (or Azure, or AWS).
Because one of their supported languages is csharp, I could write extension methods, classes, records & enums. I could use LINQ, parameterize my builds to represent the various environments I needed and even write unit tests for my deployments!
Admittedly, it's no longer declarative at that point, but it took that common form of declarative that many languages reach nowadays when they're coopted as a DSL.
I think to date, this has been the nicest experience I've had with infrastructure templating. Using Pulumi, I was able to define an abstraction that represented what "services" meant to me. By leveraging my shallow data model, I could make choices like which compute and storage to provision, how to hook ingress all the way up to DNS and what identities and permissions they need.
Saturated space
So far I've mentioned Pulumi and Terraform, but there are others! This is a space virtually flooded with tools that overlap, and you can take it far. Helm, ArgoCD, Bicep, ARM templates, Cloud Formation Templates, AWS CDK. That's not mentioning the countless Kubernetes operators which will help you provision infrastructure as well. Heck, you could cram things like Spinnaker and Octopus Deploy into the list too if you wanted.
Before even talking about the CNCF landscape, the devops space is crowded with options, all offering a different take on provisioning and/or deployment.
One thing they haven't been however is consistent or - more importantly - developer friendly.
Battered by innovation
There seems to be some rapid innovation happening which I'd describe as exciting, but also potentially inconvenient.
While Terraform has enjoyed a long dominance, tools like Pulumi have hardly had a chance to reach that critical "early majority" stage before the wheels have started to turn again.
Last year, the CNCF accepted Radius into their sandbox projects, which takes aim at platform architecture end-to-end.
Combined with something like dapr, Radius has the potential to further democratize infrastructure and bring it further left.
I've always found there to be some degree of parallel innovation in the tech space, especially where communities are strong or interconnected.
Not to be outdone, this situation seems to be following that same path as Radius isn't the only tool with the potential to upend the space being worked on. Many other projects are cropping up, each trying to break these problems down in their own ways. Dotnet Aspire is one and just the other day, I became aware of SST.
😅 Actually, I'd love to see a list of these types of tools compiled together at some point. Maybe I should make
atrauzzi/awesome-microsevice-frameworkson github?
Challenges for today
Implications for operations professionals
This category of tool takes aim at the historic disconnect between operations teams and developers by offering not just the tools to manage infrastructure, but a standard for abstractions within which to define service dependencies.
This is usually where "platform architecture" comes up in the discussion, and I think it's appropriate. But that's a space that really can only be served with a left-shift mindset and if your platform architecture group is staffed with ex-operations (the "open a ticket" types), you risk disappointment.
Ecosystem agnosticism
Aspire is an amazing tool and actually scores the best in my estimation, getting at least 85% of the abstraction correct. Unfortunately, by benefitting from the strong dotnet project ecosystem, they've also severely crippled their prospects for adoption.
Now I have no issues with dotnet, I'd argue it's one of if not the most sophisticated ecosystems for development and collaboration out there. But there are viable alternatives with less capricious sponsors which the community has shown its preference for.
Radius on the other hand seems to be aiming for more scope than Aspire and is doing so in an ecosystem agnostic way. My hope is that they can surge forward and reach a level of maturity, ease of use and adoption to start turning heads.
Staying productive while focusing forward
Right now, I don't think any player in this space has reached a point of maturity where I could recommend them yet. Which means we're stuck for now relying on the in-betweeners like Terraform or Pulumi. Major cloud vendors have their own infrastructure DSLs and libraries which might be fine to continue with, but I don't know if they'll be bringing you any closer to the kind of potential I see in Radius or Aspire.
It's potentially worth it to take a bit of short term pain right now and not overly committing to any tooling. Especially if you're thinking of getting started today. A minimalist approach in anticipation of a 1.x release of Radius seems prudent in my view.
If you'd still like to move the needle on your platform architecture, dapr is definitely a safe place to start, and it seems to have first-class support in current preview versions of Radius already.
What I'd like to see
Overall, I've really gotta hand it to the people working on these tools. They're building up communal knowledge and abstractions in a space that I have been wishing existed since 2016.
The main things I hope they can be mindful of are:
- Easy transition from current tools (adopting existing deployed resources)
- Simple "one command" local development bootstrap
- Facilitate one-off commands or one-time tools like migrations
- Ecosystems comprised of projects from multiple git repositories
- Process management, being able to start/stop with automatic dependency management
- Attaching debuggers
If a developer can install something like Radius on their workstation, clone repositories and have them all self-knit together, that would be incredible. Adding dapr to that formula then makes it possible to have a clean set of abstractions and communications channels between the services.
On the infrastructure side, Radius then becomes the tool by which to fulfil all the explicitly defined dependencies of each service.
Honestly, if you spend a little time thinking about it, this has to be some of the most exciting stuff going on in development.
More exciting than AI?
🤷♂️