Accelerated software development brings with it particular advantages and disadvantages. On one hand, it increases the speed to market and allows for fast, frequent code releases, which trump slow, carefully planned ones that unleash a torrent of features at once. Continuous release cycles also allow teams to fine-tune software. With continuous updates, customers don’t have to wait for big releases that could take weeks or months.
Embracing failure without blame is also a key tenet of rapid acceleration. Teams grow faster this way, and management should embrace this culture change. Those who contribute to accidents can give detailed accounts of what happened without fear of repercussion, providing valuable learning opportunities for all involved.
To read this article in full or to leave a comment, please click here
Google and Cisco take the top 2 spots.
In this post we’ll have a look at how to automate a typical BGP setup. This is where configuration may get particularly messy especially in presence of backdoor links and complex routing failover policies. However, as I will show, it is still possible to create a standard set of routing manipulation policies and selectively apply them to the required adjacencies to achieve the desired effect.
Continue reading
Nerd Knobs (or as we used to call them in TAC, knerd knobs) are the bane of the support engineer’s life. Well, that and crashes. And customer who call in with a decoded stack trace. Or don’t know where to put the floppy disc that came with the router into the router. But, anyway…
What is it with nerd knobs? Ivan has a great piece up this week on the topic. I think this is the closest he gets to what I think of as the real root cause for nerd knobs —
Greg has a response to Ivan up; again, I think he gets close to the problem with these thoughts —
A somewhat orthogonal article caught my eye, Continue reading
CloudFlare constantly tries to stay on the leading edge of Internet technologies so that our customers' web sites use the latest, fastest, most secure protocols. For example, in the past we've enabled IPv6 and SPDY/3.1.

Today we've switched on a test server that is open for people to test compatibility of web clients. It's a mirror of this blog and is served from https://http2.cloudflare.com/. The server uses three technologies that it may be helpful to test with: IPv4/IPv6, HTTP/2 and an SSL certificate that uses SHA-2 for its signature.
The server has both IPv4 and IPv6 addresses.
$ dig +short http2.cloudflare.com A
45.55.83.207
$ dig +short http2.cloudflare.com AAAA
2604:a880:800:10:5ca1:ab1e:f4:e001
The certificate is based on SHA-2 (in this case SHA-256). This is important because SHA-1 is being deprecated by some browsers very soon. On a recent browser the connection will also be secured using ECDHE (for forward secrecy).

And, finally, the server uses HTTP/2 if the browser is capable. For example, in Google Chrome, with the HTTP/2 and SPDY indicator extension the blue lightning bolt indicates that the page was served using HTTP/2:

This server isn't on the normal CloudFlare Continue reading
A few days ago I had a nice chat with Christoph Jaggi about private and public clouds, and the mistakes you can make when building a private cloud – the topics we’ll be discussing in the Designing Infrastructure for Private Clouds workshop @ Data Center Day in Berne in mid-September.
The German version of our talk has been published on Inside-IT; those of you not fluent in German will find the English version below.
Read more ...Here’s a quick whiteboard session of the differences between traditional and cloud native web applications.