Not only is the majority of an EV the exact same components as an ICE car, but the electric car industry has been using off the shelf components for decades.
Tesla buys plenty of products from them, including things like electric steering assist.
Bosch wants to stay relevant for longer than ICE cars after all, and a lot of these components were developed for ICE cars anyway.
Tesla have done a lot of vertical integration, but for other manufacturers there's a lot of common electronic components. Stuff like headlamps (even if it's a different plastic housing the board will be the same basic design), door locks, infotainment, dashboard displays where there's little reason to significantly reengineer them for an EV.
I don't think it would have to be only electric cars, if you're building a hybrid where the 12V battery is kept charged by the high voltage battery, you've got basically the same situation.
Availability of accessories seems like it would be inconvenient for any early adopters, e.g. you can readily get USB chargers, portable generators, coolers, tire inflators, battery boosters, etc. that run off 12V... if you get a 48V vehicle today, you'd either need a 110V->12V adapter to run accessories, or you'd be limited to 48V RV accessories.
Virtually all electronics need a step down (buck) converters as they run at lower voltages 5, 3.3, 1.8. 12V > 3.3- 1V would a single step. 48V ones would likely require an intermediate step. The only exception would be running some power systems where it'd require less current.
You're going to need the expensive bits of a power supply anyway to meet transient requirements, so it's not much of a savings to run at native voltage and it gives a lot of design freedom/reusability to have one voltage for everything.
The main savings is current though, because the wiring harness is one of the most expensive parts of a car.
The move to 48v is very much about efficiency within the harness backbone. For the same wattage, less amperage is needed in a higher voltage system, meaning the wires can be smaller and they produce less waste heat.
There are a few different topologies for a 48v harness, but somewhere in the line there's a 12V DC/DC converter in there somewhere.
The wiring for 48V can be a lot thinner than it is for 12V. As there is a square law involved for resistive heating it turns out that wiring for 48V can use 1/16th of the weight of copper as that for 12V.
A switchmode converter can be designed for 48V just as easily as 12V.
It's far cheaper and easier to just pluck a readily available 12V power supply off the shelf than it is to design one that will have limited applications outside of a single manufacturer.
Because all of the IC's that are attached to the battery are designed for 12V. Things like solid state relays (BTS7008 for exammple) and the 5/3.3 volt regulators.
> Terraform is there specifically to solve the Aws infrastructure complexity.
I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
I have to disagree a little here, if you're already in AWS, then an investment in fixing your terraform structure is not just worth the money, but gives you a better understanding of the infrastructure architecture, you also retain ownership of your deployments. What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website. You're now depending on, and maybe even paying for, an external company for devops support to do something you already know how to do.
It seems to be in the long term, that time is definitely not better spent elsewhere.
> What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website.
These are all valid points. This is a fundamental issue with relying on non-open 3rd party solutions and (leaky) abstractions. The best solution here would be some standard that the hyperscalers implement themselves, but this is of course incredibly unlikely.
> some standard that the hyperscalers implement themselves
I'm kind of amazed that they haven't already. It would be such a good selling point for Azure, or GCP, etc. "We have a UI like Heroku or Vercel. Compare that to our confusing competitors!"
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
This hits home so much!
I remember last year when I asked our Cloud Ops to add an additional EC2 instance and adjust sizes on two others. It took twelve work hours and resulted in +3k -2k changed lines "because they had no way of doing it now without merging seven hundred other changes.
Its an anti-pattern that negates some of the advantages of the cloud and re-introduces issues people had when things were still handled by the old internal IT infra department. I‘ve seen it a lot.
That smells like some really nasty problem in your company. If the change was really what you said it was, it might take some time and terraform code (i.e. nested submodules with hardcoded values that needs to support parameters all the way down) but it should not be a diff of that size.
I guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.
They could get customers initially by promising a simple start to get "on the cloud", but would keep customers due to support, scaling, monitoring, ci/cd and maintenance. Cheap startups could use it as a one-time tool, but I think a lot would see the added value they bring.
