For anyone interested in a more philosophical look at how this affects people, Byung-Chul Han has some great writings about how modern technological society affects the individual in books such as The Burnout Society.
For me, I find that I have to create the conditions for it and it'll naturally come along.
Taking the quarantine for example, I initially thought I would have an infinite amount of time to read new subjects and practice on topics I haven't for awhile, but I quickly found myself spending most of my time on video games. After adjusting my schedule of daily workouts, cooking, sleeping, and everything else I thought was mundane, my motivation to start reading one esoteric security topics and browse new open source projects came back up. Like what other posters are saying, you have to take care of the rest of your life first, both physically and emotionally, and then you'll naturally be creative and daring.
I've been looking at this for awhile and it's super cool! As a person who's used Terraform extensively and has ran into a lot of issues with it's declarative, non-scriptability (at least before 0.12), pulumi seems great. And it's also great its able to wrap any Terraform-compatible provider out of the box.
One question I have for anyone who's used it or the team if they're here is how they convinced their company to use it? Last time I checked pulumi was a small company with only 20M in funding versus hashicorp which was more established. What happens if the pulumi team runs out of money and we've moved all our infra onto pulumi?
Pulumi is great, but I gave up on persuading a company with a lot of existing terraform to move to yet another tool, and created a (pretty basic) DSL/library for writing terraform in python/c#, which can output to terraform. I could probably get permission to open source it if people are interested. *
As far as I can tell, you get more or less the same benefits as you would if you use pulumi (in the same ballpark).
* There are one or two tools for python/ruby that do this already, but having it in something with stronger typing has advantatages
I have found that the best way to use terraform is to let it be declarative and generate what you need as json (from some api or tooling).
Much less issues this way, and the json is actually what will happen with resources at a given provider. Once you start to use imperative stuff you lose a bit of predictability - your entire configuration is no longer declared, it just kinda looks that way.
Terraform should be thought of as an intermediate representation / compilation target, right? Let Terraform take care of actually interacting with the providers, and decouple that concern from how you decide what the infrastructure should be.
Pretty useful for design interviews and also a general overview. For a more in depth look would recommend the https://dataintensive.net/ book. It's a great deep dive into modern distributed computing and data architectures.
For cost, stackdriver works the best. Idk if they have a custom agent but Fluentd works great to ship logs to your platform of choice.
AWS cloudwatch is also good for cost but has much slower query speeds (the slowness makes me think it's not Lucene based?).
If you could splurge on hosted services, my favorite logging goes to datadog and it has all the other bits of observability built in for down the road.
https://landscape.cncf.io/ is usually my go-to if you wanna find best-in-class solutions to host yourself.
The thing that annoys me the most is that tech companies, mine included, will reimburse gladly books, but no one is ever allowed to be seen reading books at their desk on company time. Whereas being on hacker news, reddit, NYT visibly is okay. I've just started reading PDF's on my computer screen but I'd prefer a real book of the same thing most of the time.
Really? I’ve seen coworkers reading, but it’s rare. I occasionally encourage people to read at work. People tend to not follow through, since it’s often hard to find good books on niche subjects.
At one point I was in a reading group on Quantum Computing (we were working through some classic text book). I eventually stopped since I was bad at making time to do the exercises.
I think we can't really expect the opposite to happen. There's not an educational system out there that would actively try to delegitimize itself or the power structures it exists in.
That being said, Chomsky's works -- especially, Understanding Power and Manufacturing Consent -- are extremely helpful to understanding our current world. Even if the examples are out-dated, you can see the same things play out today as they did in the 80's. I would recommend them even if you don't align personally with his politics.
At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to.
We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for it, trying to upgrade versions via helm, and trying to debug authz policies took up a non-trivial amount of time. In the end, we got everything working but I probably wouldn't recommend it again.
It's funny that I was at kubecon last week and there was a start up whose value prop was hassle-free istio and the linkerd people stressed that they were less complex than istio.
I would go as far as to say I think the vast majority of people don't need a specialized service mesh. We unfortunately started with Linkerd and it actually is the cause of most reliability/troubleshooting issues. I don't think lack of complexity is actually a good selling point for it, because it's inherently more complex that not using a service mesh.
Istio may appear more complex but that's because it has a superior abstraction model and supports greater flexibility. We're beginning to migrate from Linkerd to Istio at this point. I had the same initial frustrations with podsecuritypolicy (and linkerd suffers from the same), but istio-cni solves the superuser problem, and I believe even the istio control plane is now much more locked down in the latest release.
However if I had my way I would be telling every team they don't need service mesh. We don't have any particular service large and complex enough to really take advantage of its sold features.
I'm also curious about this (author here btw). The majority of people we see coming to Linkerd today are coming from Istio. They get the service mesh value props, but want Linkerd's simplicity and lower operational overhead. Would love some more details, especially GitHub issues.
