Or just put them above the road then? :P

Put them above the road and tall trucks can't go through anymore. Plus, the support structures needed suddenly become obstacles for cars to hit when making emergency maneuvers or drivers lose control, and now you've got tons of glass shards, electrified wires and steel supports falling down onto the freeway.

Under the road is literally the only option, and it's a terrible option at that. Rooftops - or better yet, former farm fields- are always going to be cheaper and more efficient.

There's a standard maximum height for vehicles that is taken into account for freeway bridges, so your first argument is nonsense.

The rest still stands, of course. If you absolutely do want to put solar panels in the same place as cars, starting with parking lots is clearly a better idea. Fewer problems with high speed collisions, the electricity is generated closer to where it's needed, and people will be thankful for having parking in the shade. (Still more expensive than putting panels on a roof or field of course.)

"Nonsense" would only apply if practice were as good as theory; a very very brief Google search will net plenty of results for freeway overpasses and pedestrian bridges being hit. One example:

https://www.cbs58.com/news/truck-wedged-under-bridge-shuts-d...

This isn't really a criticism of the core idea to just say "what if somebody built it stupidly low", traffic lights have been fine my entire life and maybe some highways will have to be skipped or doubled for NASA/ military purposes.

I have to use both. I find google easier to do simple things.. but I find it lacks some of the flexibility AWS has for less simple things.

Well, that and Google's managed k8s solution was down for multiple days awhile back when I was doing a comparison. Another reason I use EKS atm.... despite I think GKE is a bit better.

I don't know when this happened. Give GKE a try, it's really amazing. Blows EKS out of water. As per the flexibility is concerned, once you learn how to use Google Services, you can get the flexibility with simplicity. AWS services are too complex and even things like billing require a PhD degree in finance to optimize for anything non-trivial.

Not even in the same universe. Containers using some managed k8s (EKS, or GKE) cluster with helm is ridiculously easier to manage a dynamic sets of applications running than bare amis. I have a k8s cluster that runs across >1k ec2 instances where I have thousand of containers running various jobs. I can apply/delete any massive deployment across that literally in seconds. with a single command.

The layers make it a lot lot easier here.

My perspective is shaped by my experience developing and maintaining mostly monolithic apps on fleets of servers. I never had the problem of having to manage dozens/hundreds of independently deployable jobs/services. And I hope I never will :) I can see how K8 can be super useful there, but it’s a situation I try to avoid :)

You know, that makes sense. I was missing that context.

If you ever do, please give container orchestration a look. It makes it honestly easy.

Weird -- the services you're utilizing are developed exactly the way you're going to avoid!

When developing a monolithic application your choices make sense. When you're taking an approach designed to allow for feature development by multiple teams in an Enterprise setting they start to be a bottleneck.

I’ve seen AWS from inside and I helped build a small part of it. Each individual product is closer to a monolith than a constellation of indispensably deployable jobs/services. The 3 products I worked on were definitely monoliths because we intentionally wanted them to be so. Obviously I don’t mean that they didn’t horizontally scale. Only that the entire app could run from 1 process, the build system produced 1 build artifact, every deployment deploys to all server, and there’s only 1 version of the app running in prod.

K8S and containers in general encourage people to split applications into micro services even if there is no good reason for it.

Yeah. Terraform is the mature standard for this. To me it feels like OP isn't that familiar with large scale infra work.

Author here. I helped manage thousands servers at Amazon across 20 regions. Obviously Terraform wasn’t an option :)

My company runs AWS cloud all 20 of the non government regions as well, google cloud, and our own data centers around the world. Yeah certain regions (hello eu-north-1) are problemmatic, but we have work arounds for that. Terraform has been fine.

> Obviously Terraform wasn’t an option :)

Why?

Because I worked at AWS for the last 8 years :)

Tbh, I don’t think it’s prohibited, but CloudFormation was the default choice.

You probably would have run into security issues with using terraform as each version would have to be vetted and any extensions you use

The Terraform AWS providers are maintained by AWS engineers, but the rest of the code will still need vetting.

That is not my experience. I've been shipping code for >20 years across a ton of platforms. MS tech has always been a snowflake headache.

I do machine learning--- but hate the overhead headache with DoD work. However if they paid me enough, of course :P

I see people getting excited about something new "past REST"... which by that what they mean is RPC.

Yup. I make 3x what glassdoor lists for my company. So do at least 2 other senior engineer friends of mine at the company.

And now someone else will easily pick up the contract, and Google loses any ability at all to influence it. Perhaps they could have reduced civilian casualities more so than whoever picks it up.

My crack selling business is the safest, too!

That's the biggest integrity-lacking cop-out imaginable.

"If I don't do it somebody else will!"

Or people just enjoy building something that scratches an itch for them?