1,920 karma · joined July 27, 2014
So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. It is not easy.
It wasn't the voice that tipped my grandma off. Just that I do not drink. So that was close.
Between tools that provide Spaced Repetition learning, to websites that are basically textbooks, to youtube videos both meant to teach and others that are native media, and finally people who curate all these materials, this is way better.
Maybe have a separate record for "this person voted" and another record for "1 vote for X", with encrypted references back and forth? Then you could at least verify that there are an equal number of both records, that all the identities are valid and only used up to once, and tabulate the final results. It would still be possible for someone who didn't vote to have a false vote logged, but that is a more narrow attack.
I haven't actually seen a customer use Windows Containers in production yet, but with them becoming more stable I suspect we'll see more of it in the next year.
You integrate a "service" by creating and linking a library that implements the entire service, including data access. Now try tracking down everything accessing the "service" database, or rolling out an upgrade to the "service".
Or are you saying that if they paid more, already employed applicants would jump from another company, leaving a job opening at their current company? If this is the case, it still means that there are fewer qualified candidates then openings, and no amount of raising pay will (in the short term of ~4 years) mean there are enough qualified candidates.
At a minimum, supporting infrastructure (power/networking/internet/etc) will eventually fail even with backups. On top of that, no mainframe is going to work when under water (flooding) or on fire (remember the delta outage?).
I learned a lot about catching all the different bad things that can happen, adding prerequisite checks, rolling back changes automatically, etc. In the end, a tool like Puppet/Chef/Ansible would have taken a fraction of the time to develop scripts for.
Containers have definitely lessened the need for mutable configuration management, but they are still useful in the 90% of environments that are still working in a past decade.
It sounds like you are claiming that it is impossible to out build housing demand. This cannot be true. There is a finite population of people that want to live in any one place.
The big things for our customers isn't just support, it is stability. When you build your systems on RHEL 8 (just released), you will get 10+ years of support and patches for that system. Those changes are all guarenteed to be binary compatible, so the risk of patching ever impacting systems is low. If there is a critical security vulnerability (say Heartbleed in openssl), Red Hat will backport the fix to every supported version of RHEL. That means you get the security fix without (1) having to upgrade the entire openssl dependency and risk breaking something else and (2) without pulling in newer changes that might have their own vulnerabilities.
Going along with the stability, vendors can QA their products against RHEL as a known target.
Last reason for now, if you are in an industry with any kind of compliance requirements, like FIPS, Red Hat jumps through the hoops to get the certification. That makes RHEL the only option in many environments.
We could have bypassed this by having a single pool of shared Envoy instances for ingress, but at the time we wanted to avoid the complexity of multiple teams managing a single Envoy configuration. In the next year we'll hopefully switch to Istio, which will help with the multi-tenant configuration management.
Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1).
For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.
There is a way to respond with an error code when a server receives a request for the wrong domain, but it seems like a bad idea to depend on it (because it means lots of failed requests that could be avoided with better certificate management):
A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request (see Section 9.1.2).
Our current load balancer doesn't support HTTP2 end-to-end (and we are dong gRPC), so we are load balancing TCP connections to the individual instances. And for certificates, we would use SANs to reduce the number of certificates being requested.
Put those two together, and browsers will assume that the first connection they make to serviceA.example.com can also be used for serviceB.example.com. Oops!
TLDR, certificates for HTTP2 need to be unique to each endpoint that terminates a browser connection.