Sheriff Cad
scientia potentia est
- 31,181
- 74,047
IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
Sheriff Cad
scientia potentia est
- 31,181
- 74,047
I have a computer science degree, worked as a software engineer for 10 years before going to law school. I did C/C++/Java back in the day (I stopped in SW in 2007).
Almost all hardware was on site then, so where my knowledge gaps are is in AWS/Azure etc because that shit did not exist then.
- 8,660
- 15,388
So, at a very high level using my corp as an example. We currently have a hybrid of AWS running the majority of our enterprise apps, with on prem legacy mainframes and data stores, with a smattering of Azure. To move everything to AWS isn't just a turn key operation. Switching from on prem virtualization to AWS Virtualization is complex and rather lengthy. You are trying to replace apps while they still need to run in parallel. Let's say you reach the end goal of everything being in the cloud 100% native all, SaaS, 3rd party integrations are successful. You would have to maintain the power, hardware, staffing, and contracts for ISPs active for whatever length of time in order to cut back to your own data center at some point in the future. That is a massive spend. Which is why its all in and once you are in AWS or whatever you get raped 10 ways from sunday because now you're captured. I'll give a really small portion of our current opex bill. to record the API write events to a single S3 storage bucket for our data intelligence team in a calendar year, this is not including storage, just recording the API write events, not the API read events. is $1.6 million a year.
- 2
- 1
Sheriff Cad
scientia potentia est
- 31,181
- 74,047
I understand all that but it still doesn't make sense why, if AWS/Azure results in these ridiculous bills, are the on-site bills even more ridiculous? If so then you're getting the cheapest deal already. If not, then why not pull it back on site, even if it costs more in the short term?
Is the issue that on-site costs less in the long term, but nobody wants to eat the short term spend?
Haus
I am Big Balls!
- 18,746
- 77,429
Mostly it has to do with how microservices and cloud architecture are different.
When the first companies tried to "move to the cloud" they just took their existing servers, and mimicked them in VMs running in the various cloud providers (called "forklifting", or "lift and shift"). They quickly ended up costing more because the apps weren't designed to work with the modular microservice oriented nature of the cloud. They also couldn't easily dynamically scale for demand, which was supposed to be one of the major plusses to the cloud.
So they re-architected and redesigned how their apps were built to specifically leverage cloud infrastructure and architecture. Efficiency improved, performance improved, and lock in improved.
Real world example. I know a company who had a very successful product, completely written in house, built to drop in and install on any suitable Linux host you wanted to run in your data center to run it. Lean, Mean, and effective. But not scalable. They then decided that they had to "move to the cloud" to be scalable. So they made their software where it could be installed on any Linux VM in Azure,AWS, or GCP. Ran into some minor hitches but it managed, but still had scaling limitations. They then wanted to "modernize it" and retooled to take advantage of anything in GCP which Google offered. This locked them into just GCP (mostly due to heavy reliance on Big Query as a microservice). They added new features and a new UI and things were pretty good, and they could massively scale now. Except they had a handful list of features the old school stand alone version could do they STILL don't have on the GCP hosted cloud service, because of how GCP works. AND they can't make an on Prem option of the new product because there's no such thing as "On Prem Big Query" which they use for their database searching now....
- 1
moonarchia
The Scientific Shitlord
- 29,817
- 57,970
Khane
Got something right about marriage
- 21,540
- 15,443
"You need to move your applications to be scalable and durable! The cloud is the answer" actually means "You need to move your applications into our software ecosystem, and we're pretending the hardware we use in our data centers is magical and different than yours and floats up in the sky!"
So you buy the double speak and move your applications onto their hardware and they have options available to you to do what Haus described as the "lift and shift". Your homegrown .NET applications can run just fine in their ecosystems after some initial set up pain and working with their onboarding engineers/architects. This whole time their team is talking up how much easier and faster everything is if you just migrate this code into their applications. They call it "scalable" when really all that means is these behemoths have the hardware and infrastructure in place to turn extra servers on for you whenever you give the green light with your wallet. It's immediate because it's already in place.
So you re-write your applications to use their native "microservices", APIs and SaaS products and now the problem isn't funding a new buildout in a data center that they don't own so you can suddenly call where your applications live "on prem" again. Its re-writing, probably, most of your applications almost entirely because they now exist on proprietary products you cannot migrate off their platforms in any way, shape or form. Your software is very literally fucking worthless outside of their ecosystem.
You once had an application you could package and sell to anyone, anywhere, running any OS. Now you have an application that runs on Microsoft's servers and will not work anywhere else, ever again.
This is a mild exaggeration, but that's basically the 50,000 foot view. You bought your kid a new swingset with all the hottest new add-ons, that every kid in the neighborhood has. It gets delivered and none of your tools are compatible with their proprietary screw heads, nuts and bolts. So you buy some new tools, build it, it works great so you start buying everything from that company. Now your whole house is full of gadgets and doo-dads and widgets that their tools work on! So you sell all your old tools. A few years go buy the sheen wears off the products start malfunctioning and you peel away the layers to find its all a grift. So you start fighting back with your wallet, but woops, none of your goddamn tools work on all the normie shit you want to buy.
So you buy the double speak and move your applications onto their hardware and they have options available to you to do what Haus described as the "lift and shift". Your homegrown .NET applications can run just fine in their ecosystems after some initial set up pain and working with their onboarding engineers/architects. This whole time their team is talking up how much easier and faster everything is if you just migrate this code into their applications. They call it "scalable" when really all that means is these behemoths have the hardware and infrastructure in place to turn extra servers on for you whenever you give the green light with your wallet. It's immediate because it's already in place.
So you re-write your applications to use their native "microservices", APIs and SaaS products and now the problem isn't funding a new buildout in a data center that they don't own so you can suddenly call where your applications live "on prem" again. Its re-writing, probably, most of your applications almost entirely because they now exist on proprietary products you cannot migrate off their platforms in any way, shape or form. Your software is very literally fucking worthless outside of their ecosystem.
You once had an application you could package and sell to anyone, anywhere, running any OS. Now you have an application that runs on Microsoft's servers and will not work anywhere else, ever again.
This is a mild exaggeration, but that's basically the 50,000 foot view. You bought your kid a new swingset with all the hottest new add-ons, that every kid in the neighborhood has. It gets delivered and none of your tools are compatible with their proprietary screw heads, nuts and bolts. So you buy some new tools, build it, it works great so you start buying everything from that company. Now your whole house is full of gadgets and doo-dads and widgets that their tools work on! So you sell all your old tools. A few years go buy the sheen wears off the products start malfunctioning and you peel away the layers to find its all a grift. So you start fighting back with your wallet, but woops, none of your goddamn tools work on all the normie shit you want to buy.
- 3
Haus
I am Big Balls!
- 18,746
- 77,429
Yep... you nailed it essentially.
Or as an old VP of product at a former employer once told me :
Never build your product on someone else's platform.
TJT
Mr. Poopybutthole
- 46,543
- 127,167
I'll expand on this some in that it also heavily applies to softer SAAS services. Not just AWS and the like.
My company used a SAAS product called Zuora for many years. Once we changed leadership they wanted that gone. As our C-Suite all originated from Salesforce executive leadership guess what they wanted? Zuora only handled our customer billings and some finance functions. A relatively small slice of the pie in day to day operations, but obviously an important one.
We already had Salesforce as a primary CRM and sales platform. So adding another Salesforce product, one called CPQ, was all we were doing. The move from Zuora to Salesforce alone cost us like $5M+ and took a year and half to complete. These two systems are built from the ground up to be plug and play so to speak. Backend shifting is of course many times more expensive and complicated.
- 2
TJT
Mr. Poopybutthole
- 46,543
- 127,167
Some AI success for me at work this last week. These could have been done without AI but it would have taken a long ass time and not something I could have just done as a side project in a few spare hours. As my team is small these have been some thorns in my side for awhile that I knocked out in a few days. Process changes pending of course.
- Instituting Platform-As-Code for Data Objects:
- Even in the biggest orgs I have worked in this is haphazard nonsensical bullshit. As DDL is inherently tedious to write even in the best case scenarios.
- Snowflake, in all its glory, has things that would otherwise be auxiliary development baked into it. Such as data objects for S3 integrations, API calls, Github, etc.
- Which can now be easily packaged.
- I can deploy all of this via airflow and Snowflake's idempotent command structures. Really neat.
- Instituting Architecture/Docs as Code:
- Following the same vein as above, once again even in huge orgs like General Motors arch docs were tedious to make. Everyone made them their own bullshit way using whatever they had on hand. Inconsistent, hard to manage and maintain accuracy.
- Github natively renders Mermaid (Mermaid).
- You can just describe shit to AI and have it put it all into Mermaid script that will be rendered for you directly in github.
- Can be pushed to Confluence with just a little tweaking and the Mermaid renderer added to Jira Cloud.
- Add in the rest of your docs the same way as markdown files and just push as you would normally. Glorious.
- You can just describe shit to AI and have it put it all into Mermaid script that will be rendered for you directly in github.
- 2
TJT
Mr. Poopybutthole
- 46,543
- 127,167
Above my level. We were within costs though as I didn't hear too much bitching about that. Our critical TTP was to begin the cutover at like 10 months in and hypercare the remaining and we did fall into that. However some of the critical financial functions we needed are still not in place so it wasn't perfect by any stretch.
ShakyJake
<Donor>
- 8,454
- 21,099
We recently had to add a new feature to our ancient WebForms app. Nothing too crazy, but if you've ever worked with WebForms, you know how easily you can spiral into postback hell.
Anyway, I used Codex to build it. I fed it the requirements, pointed it at the stubbed files, and presto it just worked. I finished in a couple of hours what I'm confident would've taken me most of the week otherwise. Best part is the page layout looked fantastic. Everything was nicely laid out, clean, and proportional. I barely gave it any guidance beyond "hey, use the standard app CSS styles defined in that file over there..."
Having Codex (or Claude) work directly on my system (editing files, making changes, the whole deal) is incredibly powerful. Absolutely amazing.
Anyway, I used Codex to build it. I fed it the requirements, pointed it at the stubbed files, and presto it just worked. I finished in a couple of hours what I'm confident would've taken me most of the week otherwise. Best part is the page layout looked fantastic. Everything was nicely laid out, clean, and proportional. I barely gave it any guidance beyond "hey, use the standard app CSS styles defined in that file over there..."
Having Codex (or Claude) work directly on my system (editing files, making changes, the whole deal) is incredibly powerful. Absolutely amazing.