9 ms·

Regarding enterprise culture I’m curious who will be in this “platform engineering” team and what expertise they’ll have. In (enterprise) reality it will more

Regarding enterprise culture I’m curious who will be in this “platform engineering” team and what expertise they’ll have. In (enterprise) reality it will more than likely be a bunch of sysadmins and former “network/storage guys” who saw which way the wind was blowing and got a cloud cert. They really have no business forcing a particular infra pattern on application teams because they have no application level expertise and nothing about adding LUNs to ESXi, typing Cisco configs, or writing bash scripts to automate yum update gives you expertise in application design/architecture. Then because they know nothing about application level concerns the PE team’s golden patterns will either be ignored or will be customized for every application to the point that they’re unmaintainable. Note this is the enterprise view. It’s probably different at tech focused companies.

smcleod 3y ago
I think that once a company is big enough you can have a few options to get code to prod and make sure it stays running as expected. You could have an option where a team is focused on building most of the platform up to an agreed point (e.g. everything under an application’s container image) and provide some common ways of setting up application monitoring / logging etc…. Making sure that while there is a core internal platform as a product team that you’re focused on being a capability rather than a business unit - by that I mean you should have some if not most folks embedded (or rotating through) dev teams. You can also have an option that lets teams self organise how they get their code running - with some light touch guard rails and potentially caveats for applications with PII etc…
KaiserPro 3y ago
> In (enterprise) reality it will more than likely be a bunch of sysadmins and former “network/storage guys” who saw which way the wind was blowing and got a cloud cert. This sounds like a tale of woe. but. The fault is the culture, not the people doing the grunt work. Like devs, if you're used to nails, then you'll want to use a hammer for everything. > gives you expertise in application design/architecture. a sysadmin should know much better how your application runs in real life, and more importantly, how it behaves when it goes to shit. They _should_ know more about all the different types of services (ie kafka vs NATS etc) because they will have had to set way more of them up than a typical dev. If thats not the case, you've had bad or poorly mentored juniors running your stuff. The reason they should know, is because they have the pager to make it work at 4am. Look, if I had it my way, and I was at a medium sized company, I would buy in 3 mainframes, in three disparate locations, set the lock step replication to "very yes" and make sure each dev used the local DB and use the job description lang, to define scale. Pay the $1million a year to outsource reliability of DB and state. Because frankly most people can't program for either scale, redundancy or recoverability. (yes that includes k8s) let the hardware do all of that and save a bunch on staffing costs. I work at a HUGE scale place, and yes there is a need for special sauce there. but even then not that much, and not enough to justify the massive churn in systems. Most PE is just cargo culting busy work. Stick to ECS and PSQL and just get on with making actual buisness features.
- anotherhue 3y ago
  > "very yes" is my new favourite consistency setting.
ddaaeugzzgg444 3y ago
[dead]

smcleod 3y ago

I think that once a company is big enough you can have a few options to get code to prod and make sure it stays running as expected. You could have an option where a team is focused on building most of the platform up to an agreed point (e.g. everything under an application’s container image) and provide some common ways of setting up application monitoring / logging etc…. Making sure that while there is a core internal platform as a product team that you’re focused on being a capability rather than a business unit - by that I mean you should have some if not most folks embedded (or rotating through) dev teams. You can also have an option that lets teams self organise how they get their code running - with some light touch guard rails and potentially caveats for applications with PII etc…

KaiserPro 3y ago

> In (enterprise) reality it will more than likely be a bunch of sysadmins and former “network/storage guys” who saw which way the wind was blowing and got a cloud cert. This sounds like a tale of woe. but. The fault is the culture, not the people doing the grunt work. Like devs, if you're used to nails, then you'll want to use a hammer for everything. > gives you expertise in application design/architecture. a sysadmin should know much better how your application runs in real life, and more importantly, how it behaves when it goes to shit. They _should_ know more about all the different types of services (ie kafka vs NATS etc) because they will have had to set way more of them up than a typical dev. If thats not the case, you've had bad or poorly mentored juniors running your stuff. The reason they should know, is because they have the pager to make it work at 4am. Look, if I had it my way, and I was at a medium sized company, I would buy in 3 mainframes, in three disparate locations, set the lock step replication to "very yes" and make sure each dev used the local DB and use the job description lang, to define scale. Pay the $1million a year to outsource reliability of DB and state. Because frankly most people can't program for either scale, redundancy or recoverability. (yes that includes k8s) let the hardware do all of that and save a bunch on staffing costs. I work at a HUGE scale place, and yes there is a need for special sauce there. but even then not that much, and not enough to justify the massive churn in systems. Most PE is just cargo culting busy work. Stick to ECS and PSQL and just get on with making actual buisness features.

anotherhue 3y ago
> "very yes" is my new favourite consistency setting.

ddaaeugzzgg444 3y ago

[dead]