A few weeks ago, I had the pleasure of meeting Pini Reznik, CTO of container consulting firm Container Solutions, in Berlin. It may appear strange that an independent consultant who spends a lot of time helping companies with development and infrastructure strategies, much of which over the last several years has involved containers, would tout another consulting firm's services. There is, however, plenty of work to do for all of us, and I am grateful for the thoughts and ideas they shared.

Serverless. Framework-as-a-Service. Function-as-a-Service. Lambda. Compute Functions. Whatever you call it, serverless is, to some degree, a natural evolution of application management. In the 90s, we had our own server rooms, managed our own servers and power and cooling and security, and deployed our software to them. In the 2000s, we used colocation providers like Equinix (many still do) to deploy our servers in our own cages or, at best, managed server providers like Rackspace.

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.

Why do customers agree to open-source work I do? In the past, we have discussed the benefits of open-sourcing your own software: Reputation Recruiting Contributions Recently, I had the pleasure of walking half an hour from a Tokyo train station with Matthew Garrett, who does some impressive work on core operating systems (pun intended; Mathew works at CoreOS). One of the thing I asked him is why a company open-sources its entire stack?

I loved the Tesla shareholders meeting, for the same reason I love it when VCs write posts about "all the investments we passed on and regretted later." Bessemer Venture Partners even has a page dedicated to its "Anti-Portfolio." Fortune magazine called the Tesla meeting, "Elon Musk Confessions: All the Stupid Things Tesla Has Done." In the meeting, Musk catalogued many "stupid" mistakes (his words), although at the time they probably appeared smart, if slightly crazy (a characteristic required by every entrepreneur).

From the Cambridge Dictionary of English: iota (n.) - an extremely small amount From the Wikipedia: Internet of Things (IoT) - the network of physical objects—devices, vehicles, buildings and other items—embedded with electronics, software, sensors, and network connectivity that enables these objects to collect and exchange data. As electronics get smaller and smaller, not just wearables like an Apple Watch, but even tiny full computers like the Raspberry Pi, the "

What do Docker containers have to do with Web browsers? Everything. Web browsers provide easy access to the digitized collective knowledge of the human race, political rants, serious applications and even silly kittens. However, it is important to understand why browsers became so popular, and such a success. Prior to browsers, networked applications existed. Mostly, they were client-server two-tier applications, but they were quite popular in business, and many home personal computer users had such applications.

For most of us - pretty much all of us - the way we use our operating system (OS) on our laptop is not that different from how we use it on our mobile or a system administrator uses it on a server: The operating system is installed to the local disk. Changes / upgrades are performed by installing files to the same disk and then rebooting. Software is installed and/or upgraded by installing files to the same disk.

The New York City Subway used to have ads above the seats for some trade school. The general thrust was, technicians always will be in need, because things always will break. What happens when employers no longer need to manage things that break? Ever since we have had IT, we have had servers. Ever since we have had servers, we have had systems administrators, or SysAdmins. I actually started my career as a sysadmin, recruited out of engineering school to run systems for CS First Boston.

At the Container Summit, I was speaking with a colleague at a booth, when a potential customer of his walked up and engaged in conversation. He asked an interesting question: How do I know if my software is ready for the cloud or for containerization? While an interesting discussion ensued about the company's technology, the most important points of the conversation were three key lessons: Just about any software or application can be containerized.

Earlier this week, I had breakfast with a colleague of mine from Rancher. Rancher is a great "orchestrator" for Docker containers. I have recommended and used them in production environments. Containers - one of the hottest technologies in the last year - is a much more efficient form of virtualization than traditional "hardware" virtualization (think VMWare or Xen), while providing a superior application distribution model. The challenge is that while the native Docker tools are pretty good for managing individual servers with containers, managing more than a few containers, let alone across more than a few servers, becomes impossibly complex.

A few weeks ago, "Lies, Damned Lies and Performance Tests," gave us a great example of how even a good performance test can be ruined through a few (seemingly) small mistakes. Today, let's revisit performance tests with an example of performance tests that I constructed on behalf of a client, as an example of how to do them correctly. Even good performance tests suffer from a paradox. On the one hand, you really want to understand how the product will perform in the real world, with all of its environmental conditions.

If you want to change technology that requires a change in process or, more seriously, culture, then you need to change the culture first. Get your people on board and then make the changes. Right? Perhaps not. Or at least not always. If your culture is flexible and open, people collaborate across groups and you are staying competitive, then, yes, change some of the culture to new ways of working, then adopt new technology that requires the different mindset.

As Ecclesiastes said, "there is nothing new under the sun." Last week, we explored how much of the innovation in the tech business is just retooling existing processes, while much innovation exists in the technology itself, which enables those businesses. It turns out, even in technology itself, sometimes the newest and most innovative item really is nothing new under the Sun (capitalization intended). Back in the late 1990s and early 2000s, before the growth of Linux, commodity servers and Google, we used to buy a lot of very expensive computer hardware.