it depends, I noticed that many engineers will input information on a slide following their thought process closely, they rarely think about the audience's perspective, especially if the audience is less technical or not familiar with the domain.
Sure mate, because taking a messy list of confusing statements and turning it into something like: "High risk of failure on re-entry - foam strike more than 600 times bigger than test data - test data unfit to support decision as flight condition is significantly outside of test database" requires a PhD in Materials Science.
If you can't effectively communicate how the results (or lack of results) of your research will impact the outcome of a high-stakes space mission you have no business being in that room from the start.
I can't remember the last time I saw a slide as mangled as the one in the article. It hurts my brain just reading it.
But you are right, most engineers would consider that reasonable, while complaining about the "muggles" that just don't get it.
As a Software Architect, one of my main responsibilities has been to take information presented like above and turn it into something that non-technical people can digest.
Being able to express a complex concept in simple terms is an invaluable skill.
The magic of cloud is how quickly you can scale things up. If you're a new fast growing business it will give you a competitive edge.
If you drank to cloud kool-aid from the beginning you kind of get used to huge costs for simple services so it's easier for your brain to justify paying 10k a month for a simple web app deployed in kubernetes, using cosmos db and any other number of services.
I've seen many companies that started on the cloud and their core architecture is so interleaved with the cloud that it would a huge investment to reduce that dependency and switch.
Cloud providers will always make their in-house offerings more attractive and easier to use compared to other (open standards) solutions. That's how you get locked in.
I don't think Google is afraid LLMs will "fix" all its issues. I think they're more afraid that their seemingly unassailable moat is suddenly exposed to disruption.
People use search engines to find answers to questions. If ChatGPT can give an answer faster and in a more natural format then people will flock to it. Most won't care that the quality of the response is as low or lower than what a search engine returns.
The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate
But they are accountable to their stakeholders (clients, upper management, etc). They take your estimate and many others from other people in the team and work those into a delivery plan.
A good manager will know how to manage risks and remove blockers in a way that gives a developer the best chance to work within the estimate. A bad manager will usually have no plan and put all the blame on the developers if things go awry.
I expect a plumber to give me an estimate of time and cost for his "tasks" before starting work. Even if he doesn't tell me the exact cost upfront he'll still be able to tell me roughly if he'll be done in 2-3 hours or less/more.
If I have a big project and I'm dealing with a plumbing company I might not be talking directly to the plumbers but to their manager. The manager will usually ask for time/complexity estimates from his plumbers before sending me a quote. The manager will usually factor into the quote any risks plus the company's profit margin.
There's a lot of talk about agile, scrum, no-estimates and so on, but a big part of the software industry still works with time estimates and budgets communicated up front.
500 - the number of employees before your CEO becomes a political figure
1000 - the size of company when you’re at risk of losing accountability
From my own experience and other sources (https://news.ycombinator.com/item?id=35206141) those numbers seem too high. I've seen this happen 2 times in front of my eyes while both companies were in the 100-200 range.
One of them managed to go to the next level and adapt to the new reality the other is still struggling.
I started my career in a software agency, maybe I was unlucky, but in this particular agency I overheard the more senior employees staying after-hours and making fun of the the junior employees (in their absence) and the quality of the code they had wrote. There was no actual code review process but this memory had made me very defensive in regards to my code. I was always trying to push the perfect code in one shot, which led me to overthink solution, and if for whatever reason I had to push a rushed change I felt guilty and tried to find excuses preemptively.
At one time I had to onboard the client's new dev team to a project that I had built alone for about one year. The product had become successful so the client wanted to invest in rebuilding it on better foundations to prepare for accelerating its growth.
Working alone on the code for a year had subdued my fears of public shaming but, once I started going through it with a team of seniors looking over my shoulder, my anxiety went through the roof. For every new file I was opening I started my explanation with an apology about the quality of the code and tried to explain why I didn't have the time during implementation to write that code properly.
After the 2nd or 3rd explanation one of the new guys stopped me and said something like: "You don't have to explain yourself to us. This code is the result of the context it has been written in. We are only having this conversation because the product that you helped build by writing that code is successful. Because of this success we now have the chance to spend time and think about how we can improve the code".
I only realized later, but that was one of the most liberating things anyone has ever told me. It felt like a huge weight had just been lifted of my shoulders. People were looking at my code and discussing it not as a reflection of my quality as a person but as the output of different factors and priorities at a given point in time.
I worked with that team long enough to feel deconditioned from the previous toxic behavior.
did that before: running a single monolithic app inside a kubernetes cluster on a single pod. I still feel dirty after doing it.
My current hobby is to try and run monolithic apps like these on serverless services like cloud run. There's still some pain related to attaching persistent storage to a container but otherwise it feels like a great option.
I'm not an "on-premise bare-metal server absolutist". Of course there are trade offs in terms of convenience but there are also trade offs in terms of cost and performance and vendor lock-in. It all depends on what you need and what are your specific constraints.
Is time to market critical? Will you have daily traffic fluctuation between 10 to 10k users? Will you lose a ton of money/customers for any service interruption? By all means use the latest version of managed kubernetes combined with whatever other cloud service tickles those itches. But don't forget to always keep an eye on your bills and think how can you reduce them by simplifying your architecture.
But if you're just building a corporate intranet for a few dozen users who log in once a week I'm pretty sure a simple VM (even if managed in AWS) would make much more sense.
And if you really want to roll your own there are plenty of options to make your life much easier compared to sending a rocket into outer-space. Yes it's more work upfront but after you do the setup the first time there's little to do.
infra automation & templates:
- ansible, docker, etc
log storage:
- mount shared storage
- ELK
- use a paid LaaS or monitoring SaaS
certificate management (on LB machine only):
- certbot
access controls:
- linux user and groups management
patch management:
- enable unattanded upgrades for security patches
health monitoring:
- in terms of lb nginx has that built in.
- for more advanced use cases use a paid service (new relic) or a free one (nagios)
remote administration:
- ansible, etc.
Don't get me wrong I use cloud on a daily basis for work, I'm just sad because most teams don't know how to use it effectively without jumping the gun.
> It’s not like you can pull people off the street and have them get away with infrastructure this simple
I know that in many cases simple != easy but I can't help feeling sad while reading this.
When I started my career cloud wasn't yet mainstream bu as a beginner I was able to deploy and configure a nginx proxy and loadbalance between 2-3 backend servers without too much effort. It wasn't some kind of rocket science.
I guess the current issue is that cloud has been marketed so much that nobody who's just starting out in the industry even has a second thought about using it by default. What can I say, great job from the cloud providers in capturing their customers as soon as they get in front of the store.
Agreed, but would most engineers understand that they can keep the simplicity of the solution if the underlying infrastructure is based in the cloud/serverless/etc?
Fro my limited experience many engineers fall in the trap of adding accidental complexity to an otherwise simple architecture just by trying to use the latest/coolest cloud architecture trend.
Monolith in the cloud on kubernetes? Speak no such abomination.
Of course we have to do microservices, the more the better. How can we scale otherwise?
SQL DB? What is this, 2010? Of course we're going to use Cosmos DB, how else could we get "single-digit millisecond response times, automatic and instant scalability, along with guarantee speed at any scale".
Of course I'm exaggerating for dramatic effect but I rarely see teams disciplined enough to keep cloud architectures simple and clean.