I would suggest that learning SQL (the syntax) isn't the crux--it's just syntax you learn over time based off need, just like learning python--what you need is motivation. I'd suggest watching this video to get a flavor of how much leverage using the database can give you: https://www.youtube.com/watch?v=wTPGW1PNy_Y If the database can make you more productive and more efficient and make your life easier, you now have incentive to use it more.
Another thing that took my use of databases to the next level, was using PostGraphile (https://www.graphile.org/postgraphile/). It takes a PostgreSQL database and provides a GraphQL endpoint for it. Use that as your only backend. You can use PostgreSQL row-level security to do access control (who can see or modify what). You can use PL/pgSQL to write business logic for higher level calculations. You can use constraints and triggers to do data validation. Each of these areas has an initially steep learning curve, and wonky syntax, but once you get over them you can implement many backends extremely quickly with them. And using PostGraphile where you only have SQL available (well, you can also add javascript extensions, but try to limit those) will be a great forcing function that will require you to scour stackoverflow and the excellent PostgreSQL docs to learn many of the useful corners of SQL you'd never learn otherwise.
A friend tried to send me a link to that blog back in June in regards to investing in cattle, and T-Mobile blocked it. Only noticed the missing message because the conversation didn't read right.
That's not been my experience at all. Have had to manually delete pods all the time. Is it possible that this was something fixed in newer versions?
Example case: DevOps pushed out a new version of Istio (without talking with anyone) and even though the container configs are referencing the new version of Istio, only half of the pods in the namespace got restarted, so we get paged because a number of services can't make any network connections with the other services. Had to manually delete all the pods, and then the new pods all came up with the right version of Istio and are able to communicate again.
On a side note: how is it at all acceptable to have a networking "mesh" that isn't backwards compatible? I can count on no hands the number of times that my fargate/lambda services couldn't communicate because half of my fleet is running a different version of VPC. Thus far my experience with Istio is that it has never added any business value (for projects I've been involved in), and only adds complexity, headaches, and downtime.
Back to the declarative thing: I'm fairly confident I've edited service configs, added service configs, edited the container image, and container environment variables, and never saw kubernetes restart anything automatically; had to manually delete.
As I recall, running "kubectl edit deployment..." doesn't do anything except edit the definition of the config. Instead, to have it take effect you seem to have to manually kill pods, and the new pods will come up with the edited config. If it were declarative, it should detect what needs to be changed, and automatically update accordingly. Same thing with editing a config. It's possible it was the funnel my local DevOps forced on me (and lacking needed permissions at every turn), but my experience was that if you removed deployments, configs, etc on the next deployment, nothing would be cleaned up and you had to manually remove. Again, that's not declarative.
In my experience Terraform and CDK are much more declarative; where you never issue commands to delete a pod or a load balancer or similar. Instead you describe what you want, and their engine figures out what it needs to add or remove or change to get to that state.
Agreed; I think a better analogy for Kubernetes is XML. So many wasted meetings about where to split up namespaces and should every last thing be an attribute or a subtag; none of that added business value. JSON took all those decisions off the table. And yes, huge industrials validly complained that JSON didn't cover X or Y or Z, but for most users JSON is a much better solution then XML.
Kubernetes reminds me a lot of XML; there are too many decision points adding unnecessary complexity for the average user's needs. Too many foot guns. Too many unintuitive things.
People keep on describing it as "declarative", which seems to be about as true as saying that Java is a functional language. Hopefully someday we'll have something actually declarative, and much more intuitive, something more like AWS's CDK.
I strongly suspect that Google didn't extend me an offer because one of my interviewers was insistent that a race condition could only be a bug and could not be used strategically, but with a electrical engineering background I could not let that slide. Unfortunately it didn't occur to me during the interview to pull up Wikipedia. I'd prefer not to work somewhere which requires dishonest agreement, so it's been for the best.
In high school I worked some janitor jobs; every week your cleaning up a very similar mess as last week, but the work can be fulfilling if you're striving to do an excellent job and achieve mastery.
That's one area that is soul crushing in software; the complete disdain for excellence and mastery. Nobody on the business side seems to care about creating master pieces. They want to throw half cooked spaghetti against the wall and see what sticks before throwing more spaghetti against more walls, and they strive to be the next facebook and have tens of thousands of employees throwing spaghetti.
Android has 10 year old bugs with thousands of watchers and instead Google is off trying to use Android in cars or televisions or probably tennis shoes. Maybe it's finally fixed, but for years AWS cloud-formation and CDK was unable to be used with a significant and critical set of AWS services and features. Instead, AWS is off creating toy RC cars and creating elastic-cloud-simple-machine-model-shift service, which are both missing cloud-formation bindings. If your the guy who actually cares about your customers, and is trying to fix these things, you're career has been repeatedly hit-and-run by everyone else making career moves and running off to make purpose-built block-chain gamified cloud-native social machine-learned pez dispensers.
And even if you can't find a job that will let you create excellence, using and learning excellent tools can be rewarding. Instead it seems like a downward spiral. There was a brief moment of sanity when the industry dropped all tangled complexity that was XML, but in general it seems like the industry is going from well crafted products like PostgreSQL, to half-baked databases like Cassandra CQL which apparently doesn't allow NOT NULL constraints. Once Java, C++, and Javascript all start to have fairly nice feature sets, it suddenly becomes hard to not find one's self stuck in jobs requiring the obtuse language go. And then there's helm, which seems to be trying to win at a competition to see if it's possible to make a configuration that's more brittle and convoluted then the old M4 based Sendmail configs of yore.
Why should I even bother becoming anything more then slightly proficient in any of these if they're going to be replaced with something even uglier and less ergonomic next year? What's the point of pouring my sweat and tears into a product for a company if the company is just going to strand it and rush off to build something else that it's going to abandon and rush off to yet something else?
You're right! But with my globe at home, and that site you listed, at the same angle I can clearly see part of India and Australia, it's weird that they don't seem to show up in this picture.
Another thing that took my use of databases to the next level, was using PostGraphile (https://www.graphile.org/postgraphile/). It takes a PostgreSQL database and provides a GraphQL endpoint for it. Use that as your only backend. You can use PostgreSQL row-level security to do access control (who can see or modify what). You can use PL/pgSQL to write business logic for higher level calculations. You can use constraints and triggers to do data validation. Each of these areas has an initially steep learning curve, and wonky syntax, but once you get over them you can implement many backends extremely quickly with them. And using PostGraphile where you only have SQL available (well, you can also add javascript extensions, but try to limit those) will be a great forcing function that will require you to scour stackoverflow and the excellent PostgreSQL docs to learn many of the useful corners of SQL you'd never learn otherwise.