As readers know, I have been thinking a lot about serverless lately (along with all other forms of technology deployment and management, since it is what I do professionally). Recently, I came at it from another angle: network latency. Two weeks ago, I presented at LinuxCon/ConainerCon Berlin on "Networking (Containers) in Ultra-Low-Latency Environments," slides here. I won't go into the details - feel free to look at the slides and data, explore the code repo, reproduce the tests yourself, and contact me for help if you need to apply it to your circumstances - but I do want to highlight one of the most important takeaways.

Last week, I had the pleasure of attending LinuxCon/ContainerCon Europe 2016 in Berlin. Besides visiting a fascinating historical capital - there is great irony, and victory, in seeing "Ben-Gurion-Strasse" - or "Ben Gurion Street" - named after the founding Prime Minister of Israel in the erstwhile capital of the Third Reich. And while I had many a hesitation about visiting, the amount of awareness, monuments and memorials to the activities of the regime in the 1930s and 1940s was impressive.

What is the basic unit of application deployment? Two related trends have changed the answer to this question: DevOps Containers For many years, the tasks between engineer and operator were cleanly, if painfully, split: Engineer builds and delivers a package of files to deploy and run Operator deploys and runs those files in a production operating environment In the early years, the package of files consisted of a directory with a ream of paper and instructions.

Since the dawn of software, more or less, companies wrote their software in a process that went something like this: Product defines the specifications. Architecture designs it. Engineering/R&D builds it. Quality Assurance (QA) tests it. If it passes, it is scheduled for release; if not, goto #3. The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "

It has long been known, at least among experienced technologists, that the best people are worth ten times the "just" really good ones. I rarely see numbers to support this contention - which is somewhat surprising for someone as data-hungry and -driven as I - but I have known it since my earliest days in the technology business. The best people are the best because they absorb more, see more, are more creative, and can put these together to grasp the future and deliver results in a way that most others simply cannot.