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.
AWS Fargate has worked really well for me. And only required an afternoon to get working. I've spent weeks learning kubernetes and still don't know enough to not hit rough edges.
I found the opposite to be true. With javascript I never saw the package.json not work for the other developers on the team; with go, half of my team can't successfully update vendoring for no apparent reason.
Commands frequently error with messages that are completely worthless.
Go seems to have made up it's own path syntax with things like "...", and commands like "go test foo/bar" will fail with an error message that gives no clue as to the problem, but work fine with "go test ./foo/bar". Why?
What's the command to see if any of my dependencies have a CVE against them? Oh, there isn't one. What's the command to prompt me to pull in a new version of my dependencies? Oh, there isn't one.
This is a language that has made some promise about backwards comparability, but every release seems to break how things are built, and you have to fiddle with bizarre environment variables like GO111MODULE to find the incantation to make things happy again.
This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head:
Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.
Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.
Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.
Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.
To answer the question: what would a language look like if you put it's designers in a time capsule for 20+ years and had them make a language that was uninformed by all the language advances and learnings they'd missed out on.
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.