It was not our decision. People in marketing and people in suits made the decision for us lowly software people 
Everything of ours is transcribed neatly in Terraform and Puppet. But that wasn’t good enough apparently.
We’re keeping “on-prem” as a “hybrid cloud” solution because of contractual obligations, as I am told.
This requirement always makes me laugh, it’s a relic from the past. Gooogle/Aamazon/Azure datacenters have way more security than your office building or whatever colo you have stuck your servers in.
I’m a huge fan of “hybrid” but not “K8s on prem” lol. But yeah this job and the last job we had a mix of folks that didn’t trust Amazon, felt they were competitors with Amazon, and/or didn’t want us hosting their data to “some third party”.
Overall I agree with what you’re saying. Still a Kh8r tho 
Can i ask you to elaborate on why? Other than "lazy’?
It’s overkill for 99% of organizations out there. We spent an exorbitant amount of time going “immutable bro” and we got very little back on that time/man power investment. Going containers is proving to be the same. I keep hearing “just build the container and ship it!” – But you have to build the container correctly to ship it. I’m not finding any time savings in developing for a Dockerfile vs developing for Packer and building an AMI/Golden Image and using Terraform + Puppet.
It’s just “not my thing”. I don’t believe the hype, because the hype train has created months (about two years) of work and is introducing a ton of abstraction which is likely going to be a nightmare to sift through down the line.
That’s like… 10 lines in a Dockerfile unless you’re doing crazy shit.
I don’t think there’s that much abstraction if you go with a managed k8s offering. But you said you were on-prem so that’s probably a fair critique as you have to make a lot of decisions and integrations that GKE has already made for me.
We’re squeezing a good ol’ monolith into containers, running tons of apt commands to get it configured, and giving permissions to tomcat
Lol…
“If we just use RDS for MySQL then it’s microservices yeah? Microservices! Deploy fast! Spin up and go!”
My team was deploying in less than 10 minutes when they were configuration drifting through space 
Honestly this is what I would prefer, but “the contract” is preventing us going all in.
So we have some stuff on VMware, some on AWS, some on GCP, and some on Azure.
Don’t dox me bro.
Honestly Digital Ocean’s implementation of Kubernetes is better than the bare metal implementation.
Do you have a mult-stage Dockerfile set up? And are you pushing the intermediary containers to a container registry so you don’t have to build them each time? That would help with this.
Time to deploy isn’t a big deal imo. It has to progress through dev, staging, integration, and then finally make its way to prod if all the tests pass and the canary routing hasn’t shown an increase in errors.
We have a few that are building with/from various containers. We have some that are from a repo and then FROM scratch to import the binaries/libraries/whatever.
But yeah, we’re using $CLOUD_PROVIDER’s container registry service.
The maintenance isn’t bad it’s just the “converting”.
Lmao.
Yeah we had that in place before containers. We’re starting to get some of our tests into containers too (docker-compose has been a huge help with this to be honest…).
Progress is progress I guess 
If you want even better test coverage (including your k8s resources), kind is a dead-simple way to get a local cluster up and running for CI or just local testing on your laptop.
Nice, I will definitely relay this to the team. Thanks brozilla.
On-prem is still important in the event of any downtime what so ever.
For example, at a distribution center where I used to work every hour of downtime would cost the company roughly $60K so there were several robust power and networking solutions in place.
It’s not wise to just cloudify everything.
We’re currently developing cloud services for a series of loT products we’ll be launching in near future. We’re setting up everything from scratch. We will have a series of nodes at our customers which will have to be upgradable in the future, both for simple updates and for new services.
We had two choices, build our own or go with a something predefined. There’s no question we could’ve done it well using k8s, k3s or one of the many other solutions available, would probably end up spending the same time as well. However, we decided to build our own, for the simple reason, we wanted to have a running system which fit our products and future needs, rather than build our products so they fit into what someone else believes is needed, or make it run how we want with hacks, which would be even worse.
There are situations where our approach is not a viable, and all of these predefined systems are absolutely perfect.
My personal opinion tho, the reason for choosing these predefined systems to some part is based on herd mentality and fear of failing, especially because of a much larger challenge, but also because it’s easier. Then of course there are the idiots in managerial positions, without a clue, who feels the need to assert themselves.
If Google would’ve stuck with existing, predefined systems when they first started, would they be in a better or worse place today opposed to building their own?
Disagree. It’s because they work well enough and you can spin them up (and down!) in a couple of minutes with just a few API calls. Building your own takes a lot of time and then you have to maintain it. With a managed Kubernetes offering, all you have to worry about is your apps and making sure they’re secured. Multri-region high availability is also pretty easy to achieve using Cilium to peer your regional clusters.
Perhaps, can’t disagree with you at the scale you describe. However, this scale is far from where most companies are. For these smaller companies, it’s like going duck hunting with ballistic missiles. These software solutions are built for massive scale, and this is where they shine. For small deployments, the user might utilize a few percent of their capabilities, but have to learn oceans more, just to comprehend what it’s all about.
Key is, keep it simple. Always.
A year ago, I would’ve agreed completely with you, this is also the same time I started researching for the project at work, played around with k8s and k3s in my homelab, extensively. Now, after I’ve built our own system, with all the bells and whistles (that we needed). I can add/remove nodes anywhere I want, it scales by itself if needed, shuts down things no longer needed, builds and deploys when needed from our own repos, can even use leftover resources from iot nodes at our customers, and more.
Now, nearly a year later, with 70-90 hrs work weeks soon done, I’m happy, I know it’s secure, I know it works, I can add any functionality I wish in any place I want, because I made it. I think, many companies could benefit from that approach, rather than taking the, in my opinion, easy way, and grab a product off of the shelf. Nomatter how delicious it looks and sounds.
Line T005 should be
T005 1
How would you bring up with a supervisor that they’re using incorrect terminology, or mixing up definitions without coming across as rude or insubordinate?
“hey, that’s actually not correct.”
Be polite.
Be professional and like dynamic_warrior says, tell them it’s wrong. If they still won’t listen, I would probably ask if he/she would hire a mechanic to put a roof on their house, or something along those lines. Then again, I’ve been fired from jobs for saying things like that, even had one throw office supplies after me as I left.
Edit: I see it like this, I’ve been hired to solve a problem, if someone prevents me from doing this, I will confront them. If they keep getting in my way, I’ll spend my days elsewhere, and they can hire a puppet to do the job, which I will tell them. Took me 20 years, but now I have the job of my dreams. Was worth it.
Depends on what they’re mixing up, to be honest. If it’s something like referring to Linux as “Unix servers” I scream internally and the fire of rage almost consumes me but people aren’t going to change. If they’re saying queue for bus or stack for queue then yeah, fundamental flaws in the language would lead to poor architecture, I’d pause and explain the difference.
If they have such a thin skin that they can’t “Oh, dang, sorry!” and move on then sabotage their career and pour sugar in their gas tank or plant cocaine in their car/house (I know a guy)