Company forgets why they exist after 11-week migration to Kubernetes (2020)
theolognion.com
theolognion.com
"Company accidentally increased dev productivity 3x by laying off 20% of middle management"
https://www.theolognion.com/p/company-accidentally-increased...
"The Board of Directors plans to hire several Agile Analyticistis, Working Culture Ambassador Researchers, Import-Export-Integrator-Optimizer Masters and Kanban Disruptors in order to help them investigate the unexpected outcome."
Some people just love proves of concept and the shiny next thing. I guess that role is useful, in its own way.
The problem is that companies take a Java 5 monolith without any CI/CD and want to take rewriting AND re-platforming AND business changes all at once in a giant project. Then they pick the technology that is anyone might be blaming and run with that excuse so it's nobody's fault.
PS. What you describe seems to be not even about PoC (the rule about PoC is that it should work at all), but about following the herd and inventing a setup to appear busy. But that'd be also not very good environment to stay at, as an employee..
It's why many brilliant minds appear to be quite content working for unethical tech giants, advertising or surveillance companies.
The reason why the company exists doesn't matter to them.
What the company actually does outside of their computer doesn't matter to them.
The technology and their freedom to pursue the New does. Companies love the production and enthusiasm they provide and pay well for it.
(Usually these types of developers do have a conscience and it's often taken up, used and displayed in worthwhile and benevolent corporate friendly style social activism)
I see this as positive because computer nerds (I'm one) get to be paid very well to figure out the new and shiny. It's what I'd be doing at home anyway.
Most of the time nothing of value is created (Except my amusement), but every once in a while something brilliant is, and due to scale, it can have big impact.
Good specialist engineers designed gas chambers in Nazi Germany
Promos require promo packs, and promo packs require large beefy projects. (Good luck jack of all trades).
Thus, you end up with these situations where large beefy projects are solutions looking for a problem as the core problem being solved is a promo, not a business need.
https://www.theolognion.com/p/dev-builds-perfect-note-taking...
Edit: oh, and how about this one:
https://www.theolognion.com/p/ai-solves-all-political-econom...
also, their homepage does not work well. i can read all the articles but i can't dismiss their "gimme your email" homepage popup. So i guess i'm not adding this site to my list of blogs i read often.
> Many at the company thought it's a good chance to upgrade software dependencies and libraries as well. A large part of a PostgreSQL database running on a single machine could as well be transformed into a distributed KV storage, leveraging the tremendous power of flexibility of AWS.
Stick to the scope.
1) Be clear about your requirements, understand your target platform and take the time to estimate costs. Blindly picking an off the shelf cloud provider can ruin you if you suddenly get hit with unexpected costs e.g. ingress/egress.
2) Kubernetes is often the sensible way to go so long as you're using a managed platform e.g EKS. As it allows you to build out your platform in a scalable, highly-available and geo-distributed way without needlessly tying yourself to any one cloud.
Because aaaany day now, AWS is going to turn around and jack up prices on EC2 instances because they can. Humans are terrible at risk analysis. There are good reasons to arbitrage between clouds, but business continuity isn't one of them.
EC2 instance prices are nothing compared to the many hidden costs e.g. ingress, VPC, NAT.
ROBERT ENGLUND - Freddy Krueger
Don't use (self-managed) k8s when you can use the managed k8s provided by your cloud provider.
Oh god the mid level infrastructure engineers are on HN now.
No, running your own Kubernetes installation is absolutely not often the sensible way to go.
Yes you should measure costs, well done, but be realistic and include at additional annual salaries for the people whose full time jobs are now managing Kubernetes and productivity loss due to failures of your unnecessary installation of massively complex software.
If you haven’t noticed from posts like this, Kubernetes is an industry meme for wasted engineering effort and has a reputation of being something added to companies by young engineers practicing resume-driven development.
Why not make your own monitors? Computer displays have enormous markups and monitor providers could increase prices at any moment.
Finally: EKS also falls under the definition of using an off the shelf cloud provider as the other commenter has already pointed out.
The joke concentrates on Kubernetes (if I wanted to be kind, it's probably because a joke is better with an actual examples, but I actually think it's because the author is in that engineering world, and doesn't know the other places where the same applies), but you could do the same with server-side rendering, with AI, with $modernFrontendLib, $modernLanguage
Of course running their DB was a bit challenging as they forgot to set proper K8S storage configs and saw their data disappear after their pod was suddenly migrated
If you already use docker, it shouldn't take nearly that long. If you don't, then kube isn't the problem for any migration similar
Hackernews however is a frounder, frontend scene first site. So I'd imagine that is what normal feels like to most of you.
Sounds like someone has only worked with trivial, low-complexity systems and limited themselves to operating within their own capabilities.
Where's the 40 year old IBM mainframe the business depends on, and which limits customers to 8-character alphanumeric passwords? Where's the critical business system which won't run on anything higher than Java 7 and which nobody maintains? Where's the corporate policy insisting such obsolete software isn't allowed on the new system, but providing no budget or headcount to upgrade it? Where's the software that needs to connect to external services, but the team doesn't know all the hostnames or IP addresses? Where's the guy blocking DHCP and DNS because they weren't on the list of approved external services? Where's the crucial software with its license locked to a server with a certain MAC address and CPU ID?
Do you even have a sworn statement from the creators of Kubernetes that no slave labour was used? No, I thought not. Unlike you, some of us are opposed to slavery.
Google released GCP 15 years ago and they still haven't moved their internal services to use it. That proves they're web-scale and you're not.
/s
And yet, engineers would rather deliver a pizza by organizing an expedition team, climbing Mount Everest, taking a picture of the pizza at the summit, then fly the pizza back home, rent a Lamborghini and drive the Mongolian rally race, then 18 months later deliver said pizza.
While they do that, just get on a cheap scooter and drive it down the street. Win.
You'd be surprised how many companies that maintained <20 vms migrated to k8s. The motivations include ordering a chaotic status quo, premature optimisation, young blood wanting to prove themselves, boredom, "its new so it must be better", "i want to try this" [...], you get the idea.
1. Do one thing at a time.
2. Start simple.
I migrated our services to Kubernetes without any issues. But it took two years of learning and trying, migrating small services. I tried several approaches before coming to the most suitable and that’s not something you would find in the Internet. I’m using gitops without automation, I just kubectl apply -k what I need, because I decided back at a time, that flux was unnecessarily complex to start with. Now I have few dozens of services and good understanding of things, I’m thinking about introducing flux.
In 1979 I bought a radio-shack Tandy I. Soon I was deep into playing at home with Foxbase, a DOS based database program (later known as FoxPro and bought by MSft in the early 1990s). In 1981 I opened my own firm. Back then the newest advance in office production was the fax machine and electric typewriters that had one line screens; memory; and tiny disks that could hold forms. Businesses still did not use personal computers.
My law firm soon had ~10 attorneys and another 12 support staff. I bought Compaq computers fir every secretary. I spent much of my time writing a time and billing program to replace the manual paste-strips. Then I learned how - and installed - a network. No other firm I knew of had a computer. We had 10+ for the support staff plus 4-5 "portable" Compaqs for attorneys to review the bills before they were sent to clients.
Meanwhile I was running the business into the ground. We had world-class tech before anyone else had even one computer, but I wasn't focused on lawyering or smoozing the business clients. Instead I was locked up behind closed doors programming. I finally closed the firm in 1994.
But they sure were exciting times - soon every from had computers for word processing but commercial billing programs didn't exist. For a period of maybe 24 months, every lawyer from other firms I worked with wanted my billing program. But I was too focused on having fun programming while drowning trying to keep up with my case load. My law practice was the perfect lab from my programs. Too bad my programming ruined my business.
Edit: corrected horrible number of typos.
I’m interested in those paper based techniques because I learned over the years that physical representation of abstract things helps a lot of people keeping a general overview in projects.
All, of course, to migrate a perfectly functioning app (mostly CRUD) and doesn't need any of the tradeoffs given by GraphQL or an interactive frontend.
The longer I am in this industry the more I see people in charge have no idea of what they're doing.
It saddens me because improving code (especially one that changes often) is absolutely crucial, but we seem to never bite the bullet and improve the existing code, instead opting to rewrite the entire world in never-ending projects.
After a company gets burned by one of these rewrites, they often become averse to any refactoring and the few legitimate rewrites that need to happen.
We spend all our influence capital on useless projects and then wonder why our industry is so often viewed as unprofessional and amateurish.
It has burned me and it has burned others. Just doing cosmetic refactorings alone me and others I have observed caused new bugs. Let alone doing architectural or other "deeper" refactorings.
At this point I pretty much refuse touching anything not related to my ticket, everything else is a risk to my reputation.
When I see junior developers take on unrelated refactorings, I let them fly too close to the sun, they will learn through the pain.
Last thing I did a few years ago was changing a weird boolean field that could be null. I thought it would be smarter to default it to false, client team told me it was fine. We then found out in production that very old clients actually had different logic based on true, false AND null. I got pinged in my free time, it ruined the date I was on and thus at least the whole day.
In a perfect world you have CDC and all the testing in the world, but in reality you just don‘t.
Doing small incremental improvements is, most of the time, the best way to improve. But because in general there's no incentive to have even a base level of quality in software, the incentive is towards rewriting and dealing with all the issues after the fact.
It really makes me sad.
I liked this one - Dev realizes he is still in the interview stage after 2 years of work [https://www.theolognion.com/p/dev-realizes-he-is-still-in-th...]
Especially the conclusion:
> Pawri's hope is that the offer will come before his retirement date.
At this point I am convinced devops is a job security scam, all the way up to the director in charge, with many of the engineers in between actually believing they are doing something useful and happy to be learning $in_demand_skill.
Just like "cloud" and "cloud native" altogether. Costs more, requires more engineers to be kept running and is just as incomprehensible, customized and brittle as good old sh scripts on bare metal.
Almost lost my coffee.
I think execs and managers at Google are just high on their own farts at this point.
Three times I’ve been involved in a Kubernetes (or competitor) migration where the plot gets lost along the way. At my current company we have canceled the product roadmap to focus on year three of the migration and we likely have at least another year to go.
No one can tell me why our current ECS based deployments are a problem. No one bothered to train people on appropriate uses of Kafka before double abstracting it into a framework.
But hey, the board was promised a cost savings and globally available product from this effort so at least the executive that promised it all has two more years to figure out how to make good on it.
Best of all is we have a new CTO and he has openly questioned why we don’t just use Kubernetes itself instead of the couple of Hashicorp products we’ve settled on. Maybe I’ll get to do this a fourth time once we finish the current migration.
This is the most surreal thing I've read on here. You went from a company that delivers some product, to a company that delivers a migration.
You sure your company is not the one in the OP? ;)
The problem is it's not Kubernetes.
I am in the exact same situation. New manager arrives and wants to move to Kubernetes, just because.
Because suggesting Hashicorp over Kubernetes makes a lot of sense so long as you are ignorant about budgets and costs. Because from experience they are one of the worst vendors around at squeezing money out of their customers.
I imagine if you were the CTO you would likely agree with them.
We’re just cosplaying a large tech org when this company, like the others I’ve been at, is a sales company with an IT team. There’s nothing inherently wrong with that. It’s a good business to be in. We just don’t need a complex runtime with software defined networking to deploy a series of three server blue/green deployments for relatively low traffic use cases.
The problem itself has been the same for the past three companies I’ve worked at.
Of course these companies exist and there is a core of truth in what the article says. Otherwise, it wouldn't be satire.
In reality, though, a migration to K8S in most organizations won't take only 11 weeks because most organizations are completely dysfunctional.
https://www.theolognion.com/p/dev-realizes-he-is-still-in-th...
This is nonsense! Such migration could not be even "seemingly" completed in 11 weeks, rather 11 years. /s