In company with 350+ employees. 100 of them in pro...
# general
m
In company with 350+ employees. 100 of them in product&tech. Been looking a long time for developer platforms, hearing about thoughtworks putting dev platforms on "adopt". Still cannot get my around developing our own "platform", it just seems so much work. We do have some sort of structure. A "landing zone" script invoked pr team which creates two azure subscriptions with some basic resources, access groups, service principals, service connections, azdevops project ++. Also considering adding observability components and policies into this script. I guess that's our "platform". Script can be re-invoked if extended with more components. Teams use terraform for provisioning infrastructure. We have our own modules that should simplify their job
Answering in thread to @Lennard Berger : Yes we have looked into K8 but havent jumped on it. Yet. At the moment we mostly use App Services. Now Azure Container Apps will also give you a fine way of deploying containers without maintaining your own K8.
And.. I believe K8 is not the answer to everything. You would still need a lot of other components for a team. Identities, service connections, pipelines (azdevops), etc..
l
while that’s true, the standardisation of the platform has led to plenty of solutions for most of the things you have mentioned. it really more becomes a plug-and-play nowadays. a custom script to set up Azure subscriptions etc sounds cumbersome and fault-intolerant. At least from my experience with AWS, managed scripts can break apart at any time, and application recovery is a nightmare. None of these issues have ever occurred to us on K8, and we deploy for a fraction of the cost on bare-metal
m
The scripts are really just a pipeline with terraform code combined with a couple Az CLI commands The subscriptions are there for isolation purposes and an extra security layer I'm not against K8 at all, it could very well replace our current setup with app services, and some teams have already started. Then I would guess K8 and some initial work for creating namespace pr team would be the "platform".
l
indeed, there is not much more magic to it
n
I think it's worth digging some more on what problems are you running into today and what's the scale of your system. Are individual product teams operating their own services? Is there a central infra team that operates everything? Are you running into developer velocities issues? Overall I don't think the answer is black and white and there isn't an architecture you have to get to. It all comes down to ROI and bandwidth.
n
@Martin Helgesen What’s the problem you’re trying to solve?