Yes, Lori has been reading the Internet again. And what she's been seeing
makes baby Lori angry. It also makes this former test designer and technology
editor cry. Really, I weep at both the excuses offered for such testing and
the misleading headline.
I have read no less than two contrived comparisons of "HTTPS" and "HTTP" in
the last two weeks purporting to demonstrate that secure HTTP is inarguably
faster than its plaintext counterpart, HTTP.
Oh, if only that were true.
See, the trick is that both comparisons (and no doubt many more will follow)
are comparing secure HTTP/2 with insecure HTTP/1.1. From the aforementioned
comparison: "Plaintext HTTP/1.1 is compared against encrypted HTTP/2 HTTPS".
As we are all already aware, HTTP/2 itself is faster (by design) than
HTTP/1.1 for a variety of reasons that have absolutely nothing to do with
security. Multiplexing, ‘s... (more)
It was a Monday. I was reading the Internet. Okay, I was skimming feeds.
Anyway, I happened across a title that intrigued me, "Stateful Apps and
Containers: Squaring the Circle." It had all the right buzzwords (containers)
and mentioned state, a topic near and dear to this application
networking-oriented gal, so I happily clicked on through.
Turns out that Stateful Apps are not Stateful Apps. Seriously.
To be fair, I should really say that when a devops guy talks about
‘stateful apps' it is not the same thing as when a netops gal uses the term
‘stateful apps.' That's because the... (more)
The Importance of Licensing to Equalize Dev and Production
We’re all aware that dev/test != production environments. While the
software stacks upon which applications are deployed may be (and hopefully
are) the same, there still remains a whole lot of “infrastructure”
(that’s everything else) that isn’t the same. Routers, switches, security
devices, load balancers, caches, and other devices dedicated to ensuring the
secure delivery of applications to hungry consumer and corporate users simply
don’t exist in the dev/test environment. That’s particularly true as
organizations cont... (more)
I've been reading up on APIs cause, coolness. And in particular I really
enjoyed reading Best Practices for Designing a Pragmatic RESTful API because
it had a lot of really good information and advice.
And then I got to the part about compressing your APIs.
Before we go too far let me first say I'm not saying you shouldn't compress
your API or app responses. You probably should. What I am saying is that
where you compress data and when are important considerations.
That's because generally speaking no one has put their web server (which is
ultimately what tends to serve up respons... (more)
Sharding for Scale: In the App or in the Network?
Sharding has become a popular means of achieving scalability in application
architectures in which read/write data separation is not only possible, but
desirable to achieve new heights of concurrency. The premise is that by
splitting up read and write duties, it is possible to get better overall
performance at the cost of a slight delay in consistency. That is, it takes a
bit of time to replicate changes initiated by a "write" to the read-only
master database. It's eventually consistent, and it's generally considered an