For my org. I don’t have budget for a dedicated in-house opsec team, so if I on-prem it triggers additional salary burden for security . How would I overcome this?
You can't. That's the use case FOR AWS/GCP. Once the differential between having a in-house team and the AWS premium becomes positive is when you make the switch.
A lot of the discussion here is that the cost of the in-house team is less than people think.
For instance: at a former gig, we used a service in the EU that handled weekends, holidays and night time issues and escalated to our team as needed. It was pretty cheap, approximately $10K monthly fee for availability and hourly rate when there were any issues to be resolved. There were a few mornings I had an email with a post-mortem report and an invoice for a hundred euros or so. We came pretty close to 5 9's uptime but we didn't have to worry about SLA's or anything.
There is also the factor that the idea that you don't need administrators for AWS is bullshit. Cool idea, bro. Go to your favorite jobs portal. Search for "devops" ... 1000s of jobs. I click on the first link.
Well, well, they have a whole team doing "devops administration" on AWS and require extra people. So not having the money for an in-house team ... no AWS for you.
I've worked for 2 large-ish firms in the past 3 years. One huge telco, one "medium" telco (still 100s of people). BOTH had a team just for AWS IAM administration. Only for that one thing, because that was company-wide (and was regularly demonstrated to be a single point of failure). And they had AWS administrator teams, yes teams, for every department (even HR had one, though in the medium telco all management had a shared team, but the networking and development departments still had their own AWS teams, who, btw, also did IAM. The company-wide IAM team maintained an AWS IAM and some solution they'd bought that also worked for their windows domain and ticketing system (I hate you IBM remedy), and eqiupment ordering portal and ...)
AND there were "devops" positions on every development team, and on the network engineering team, and even a small one for the building "technics" team.
Oh and they both had an internal cluster on top of AWS, part on-premise, part rented DC space, which did at least half the compute work (but presumably a lot less of the weird edge-cases), that one ran the company services that are just insane on AWS like any kind of video.
they sell "you don't need a team"... which is true om your prototype and mvp phase. and you know when you grow you will have an ops team and maybe move out.
but in the very long middle time... you will be supporting clients and sla etc, and will end up paying both aws AND an ops team without even realizing.
Familiarize yourself with your company’s decision process on strategic decisions like this. Ensure you have a way to submit a proposal for a decision on making the change (or find someone who has that access to sponsor your proposal), build a business case that shows cost of opsec team, hardware and everything else is lower than AWS (or if cost is higher then some other business value is gained from making the change — currently digital sovereignty could be a strong argument if you are EU based).
If you cant build a positive business case then its not the correct move. Cash is king. Sadly.
If you don't have budget for someone to handle this for you, you can't afford AWS either, as you still need to handle the same things and they're generally more complex when you use AWS.
Funny, we are working to implement this same logic in our in-house financial categorization agent. When we have a repeat prompt it goes to a json that stores answers and only goes to AI for edge cases.
Awesome to hear you’ve done similar. JSON artifacts from runs seem to be a common approach for building this in house, similar to what we did with the muscle mem. Detecting cache misses is a bit hard without seeing what the model sees, part of what inspired this proxy direction.
The concern is not the course, but the ability to adjust a layout due to deviations from the plan due to normal construction errors.
For example a pipe might not be in the location shown on plan for many reasons ranging from simple human error to a delta between the plan location when the pipe was layed and the time the robot got its data…keep in mind that when the pipe went in there was only dirt, not anything to accept ink.
But at that point it's back to engineering to figure out what to do (leave the pipe where it is and adjust around it _or_ move the pipe - possibly cutting concrete and perhaps untensioning/retensioning post-tensioned cables at substantial delay/cost) or move the piece of equipment that the penetration is serving.
One nice thing about automation like this is that the "as built" plans are more likely to be accurate because the only way to get "the computer" and "the robot" to stop squawking is to change the plans they are operating off of.
If this can't handle dirt surfaces, future generations/models probably will if there's demand. Perhaps such models would use spray paint/stencils or driving pins into the ground for marking purposes (or something more practical - I'm a software guy and this sounds like a hardware problem!).
My experience is with small residential builds but I would hope on large projects the location of each "unmovable" pipe/conduit etc that will end up penetrating a slab is already carefully verified before the next step is taken (such as placing concrete). Hopefully this is done with a total station rather than guys with chalk lines and tape measures. But a solution like this could reduce manual checking mistakes (of course, it's less likely to result in an experienced subcontractor noticing that the plan must be wrong because there's no reason for a conduit for 1KV electrical cables to come up 2cm away from a toilet trap in a multi-stall public bathroom - GIGO).
each "unmovable" pipe/conduit etc that will end up penetrating a slab is already carefully verified before the next step is taken (such as placing concrete)
My experience is as an architect.
The CAD file isn’t the building no matter how much everyone might wish it were.
Even if the plans were the building odds of everybody using the same plan revision all the time is just about zero.
And most of the time, nobody is gonna pay for a super accurate as-built BIM. Because the point of the exercise is a certificate of occupancy.
Weirdly it turns out to be cheaper/faster than paying a human being to do the same thing in use cases where you have large concrete slabs with complex walls/casework layout
