It’s completely anecdotal but contacting me the way nginx and parters will after I’ve received the free ebook will only do them harm. My department has never taken anyone up on the offerings, and if they don’t include a working unsubscribe link, then you end up blocked companywide.
The free ebook is a lot of good will though, and I’ll remember where it came from. So if it’s good it was a much better investment than whatever usage they’ll get from my email.
If you think your contact data (personal email and phone number) has no value, please share them here. You will probably get great value from it!
I agree that it's not exactly free because it has a value, just like your comment right now has one. However it doesn't represent a monetary loss from you (just like your comment right now), which I believe is what he meant by free.
If you believe your personnal email and phone number has a value higher than this ebook, than yeah, don't exchange them, that would be absurd.
But of course now we are definitely nitpicking on a philosophical level.
My point basically if someone says something is free, but requests your personal data in return, then that is not free.
Any effort to control the distribution of digital media on the internet is doomed to fail. It is not our job to prop up failed business models.
or should we just give you money because we feel sorry for you not realizing this ?
No, I am not getting it as “free”. That’s misleading at best and I personally think it’s disingenuous. We need to call out the cost of personally identifiable information.
Instead of getting frustrated, say you’re giving the information (book in this case) for the cost of being able to hold your personally identifiable email address for X period of time for Y purpose.
It’s not “free”, let your audience know and advertise it so.
As I said in the other comment, everyone can value their contact information themselves, but I guess that most people value them >0. And >0 is not free, otherwise the company would not have any reason to get them.
Step 2: completely transform your existing organization to be a matrix of agile teams with chargeback budgets aligned to resource use of shared services and collaborating on product lifecycles in scrum and kanban using full test coverage on both legacy and modern apps stored in asset-managed Docker containers in ci/cd pipelines triggered by Jira tickets deploying declarative immutable infrastructure and integrating an array of site reliability services that don't ship with k8s while adding policy and compliance enforcement with secret management and process auditing including in-line content filters using redundant services in multiple data centers without wasting resources or money
Step 3: document it
(I haven't read the book yet, so ymmv)
Then came orchestration. Swarm was a bit slow to get out the door and is still buggy. K8s on the other hand shot past like a lightning bolt. While it evolved quickly, k8s has to be the one piece of software that I dread to work with the most. Setting up a cluster seems nearly impossible without compromising important features. Configuration is overly complex and difficult to discover. None of the (many) tools seem to do what I want.
In the end, I begrudgingly chose Docker Swarm because I was actually able to create a cluster that worked. Mind you, there are still truckloads of bugs that have sat gathering dust for years that I continue to run into. At least with this solution I'm somewhat productive.
May the heavens have mercy on your soul should you attempt any amount of networking in a cluster.
If you can convince your organization to use GKE (Google Kubernetes Engine), your life will become simpler. Power of Kubernetes with none (almost!) of the pain.
Yeah, and for most of us it's a problem we don't actually have.
Use of these technologies seems aspirational to me. It's a kind of cargo-culting: as if using the methods of the software giants, will make your company into a software giant.
I want to coin a new term "SimpleOps": operations infrastructure which does not include complex components such as cluster orchestrators, service meshes, secret management, IAM, policy enforcement, telemetry processing engines, app tracing, and so on. If your app is simple, only use simple components and managed services.
You can still have DevOps best practices with very simple components, and it'll be easier to reason about, build, and run.
The sheer length of the sentence and the variety in vocabulary creates a rising, racing energy that forces you to stop and smile before you get to the end.
Beautifully written! I’m going to save a copy for myself.
That said, I'm running a few GKE clusters now with an 18-month old production codebase, and its kind of been a pleasure. That's a good portion of a million dollars in my pocket, no matter how the start-up fares after its done ;-)
Step 5: begin remediation to remove suspiciously hands-off automations that a few dozen humans could do and check manually instead
Step 6: lift and shift another past due application into your old hyperconverged private cloud because ITIL is looking pretty good right now
Step 7: git pull upgraded K8s, go to Step 1
/s (typical enterprise IT allergic reaction)
[•] Chief Fakery Officer
I don't recall last time I've put real info in these forms. Protonmail worked just fine.
* not really"
Even though I work in tech, I was excited that they were giving a way a print copy I could flick though easily, and bookmark, annotate or share.
EBooks have some advantages, but I still prefer print.
However scrolling through / flipping through pages to find something feels much more effective with a real book.
i tried doing the same with pdfs... and it's just not the same thing.
Expect to see lots of Nginx ads on Facebook, Twitter etc.
can't we stop calling confusing this with "free"?
Containers offer not much benefit if you're cloud native - you already have VMs and heaps of automation APIs.
When you have a large scale platform with millions of users and you need to add / remove / change services at some marketing teams whim
I don't have hands on experience with kubernetes and a quite a bit skeptical because of its supposed complexity. Would be interested in success stories though where kubernetes magic was the much needed secret sauce.