What is “cloud-unnative”? It sounds like a tongue-in-cheek term promoting architectures that do not fit into the cloud, but it is not. Actually, I have spent much of my career helping companies get their architectures into forms that distinctly are cloud-native, much of it long before the term “cloud-native” existed. Many cases make perfect sense not to go into the cloud. The design principles, however, can be enormously helpful towards operating more efficiently and reliably, within or outside the cloud.

Is the cost of cloud a “trillion dollar paradox”? Legendary venture capital firm Andreesen Horowitz thinks so, based on their blog post from late May. The above article has been making the rounds for several months, causing a lot of teeth-gnashing and lining up of parties on either side. Is it evident that cloud puts “pressure … on margins (that) can start to outweigh the benefits, as a company scales and growth slows”?

Every pundit under the sun has their theories about how the “world will change” post-Corona. Personally, I have never liked airy pronouncements about how “NOW it is different.” I prefer more measured responses, like Ben Thompson of Stratchery, who has said in his articles that the responses to Corona would accelerate existing trends. I do, however, think that one trend will reverse direction, and that has a major impact on markets: supply chains.

Inception When the cloud-native world really got under way, especially the open-source part of it, much of what we used to do (and, likely, most companies still do) in custom and proprietary ways became standardized: defining workloads defining storage defining dependencies defining policies defining placement defining replicas load balancing rollout strategies packaging status many other things The tool to do this, of course, began with docker, which addressed, primarily the packaging and workloads part, but grew to Kubernetes as a basis for the rest of it.

Thoughts on KubeCon North America 2019 In late November, I spent several days at KubeCon/CloudNativeCon, for the fourth or fifth time. It certainly has grown over the years; San Diego’s conference was oversubscribed at 12,000 attendees. In the somewhat snarky words of a friend from the Linux Foundation, “this feels a lot like the OpenStack conference at its peak.” I am hopeful that it doesn’t go down the same path.

Yesterday, I had the privilege of one of my many discussions on technology direction with Josh Mahowald. Our conversation turned towards why it is that so many interesting and enabling pieces of software have been built on top of Kubernetes. As Josh put it, there is an explosion of higher-level services and tooling. This will be the first in a series of posts examining what Kubernetes really is (ok, an API), where it fits in the history of technology, and why it has enabled this kind of “explosion”.

Why do I need both GitHub/GitLab/Bitbucket and JIRA/PivotalTracker/etc.? Over the last several years, while working with companies that regularly deliver software, I have seen three basic patterns in use: Git-All-In: These companies, normally founded by engineers, run all-in on git platforms like GitHub/GitLab/BitBucket. The Issues tracker and Pull Requests/Merge Requests (I will stick with “PR”, but no offense to GitLab) are the primary tool they use to track activity. As they grow some, they use the various “project”, “kanban” and other organizational features added to these platforms, but the primary method for interacting with daily work and knowing their state is the Git-based platform.

How do you run a great conference? I spent the first three days of this week, Monday March 4th through Wednesday March 6th, attending and speaking at QCon London. In my case, I spoke about LinuxKit, a toolkit for composing lightweight, minimal and optimized runnable operating system images. Those who know my focus on technology operations might wonder why I gave a talk on so deeply a technical subject as composing operating system images.

Serverless? Containers? Who will win??? In the week of aws reInvent, when 45,000 or so people are descending on Las Vegas, and two weeks before the big cloud-native conference in Seattle, the question of “which is the future, serverless or containers?” seems to be the “debate du jour”. For example, take last week’s debate: I am going to posit a different position, one which, in the true spirit of compromise, leaves everyone equally unhappy:

A few weeks back, I wrote an article on my observations on KubeCon/CloudNativeCon. A number of people asked that I follow up with similar observations about DockerCon. Last week, I had the unexpected pleasure of attending DockerCon in San Francisco. I say unexpected not because I did not expect to attend, but because I did not expect it to be so pleasurable. Indeed, I fully intended to cancel my ticket, until I was asked by several colleagues to attend with them.

What is Kubernetes? According to the home page: Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. On that basis, Kubernetes has matured and evolved, becoming not just “an open-source system”, but the system for orchestrating containerized applications. By extension, it is the system for orchestrating any dynamic, self-healing, rapid deployment application. In October 2017, Docker threw in the towel on Docker Swarm and made Kubernetes its default (and apparently soon only) orchestration system.

Two weeks ago, I attended KubeCon/CloudNativeCon EU 2018 in Copenhagen. The sheer size of the conference was astounding. Over 4,000 people attended.. In addition to the sheer size, the professionalism of both the conference itself - audiovisual, presentation, organization and administration - and the sponsor booths was very impressive. I have always enjoyed Linux Foundation events, very warm and friendly, but a little, as they say in Yiddish, “heimish”. They contrasted with the professionally run conferences you could attend put on by other organizations.

Yesterday, I worked with a colleague to determine costing for their newly deployed kubernetes cluster on AWS (Walmart must not be a customer...). The math was mostly straightforward: Get cost of instance by size, multiply by number of instances and 720 hours per month; Add EBS block storage; Add ELBs; Add data traffic out; Add S3 storage. Repeat for each environment, and you have your answer. By far, the biggest cost line item is the first: instances.

Earlier today, I had the pleasure of speaking with Stuart Hasking, a colleague from my financial services IT days, and currently a strategic consultant at TESM. We were discussing the challenges in making changes in a technology environment, when he shared a great line that summarizes the issue perfectly: "It's about the carbon, not the silicon." Most people view technology - deploying servers, designing networks, writing software - and especially complex large-scale distributed technology, as hard.

In the technology world, selling new products is hard. Selling to enterprises is even harder. Small companies were (relatively) easy. They took a little bit of handholding to get your SaaS/software/hardware configured "just right" for them, but most of what they wanted pretty much fit into the offering anyways; it was "on the truck." As you expand up-market into larger customers, customization demands increase. They need: Integration with their (unique) login system Special compliance controls Unique flows and processes Added manual approval steps etc.

Yesterday, I published an article asking, "Did Docker Declare War on RedHat and CoreOS?" I received several responses pointing out market-related developments. A number of people said they know that Docker did not intend to "declare war" on CoreOS and RedHat. Docker simply was developing its tools that they needed anyways and advanced their market. With the change in CEOs this week at Docker, highly unlikely they would start a war immediately before changing.

Yesterday, at DockerCon, Docker Inc announced open-sourcing its LinuxKit toolkit to build Linux operating system images. LinuxKit (the platform that has been rumoured as Moby for over a year) provides a relatively easy-to-use toolkit for building immutable operating system distributions. Normally, an operating system is a platform that you change on a regular basis. Sure, the core itself - the kernel and modules and basic tools - are changed only when you upgrade or patch your operating system.

I find it interesting when the same conversation happens with two different people in the span of just a few days. In the past week, I had almost the exact same conversation twice, with two different people at two different companies, about culture and acquisitions. In both cases, they had initiated the topic of conversation. The following is a common pattern: Company Small is founded to bring a product to the market.

As every successful CEO (and VP) will tell you, recruiting great people is their top priority. Sure, they need revenue, and deliverables, and to manage funds, and a million other things. But great people are how you get these things done. In a competitive market, firms look for original ways to find and hire great people. Engineers, in particular, are in very high demand, and firms look not only for new ways to find them, but also exciting ways to appeal to them.

In my world of technology operations, two major themes recur again and again (redundantly): Incentives Litmus Tests I have written about incentives extensively on this blog. In short, as the saying goes, "you get what you measure." Don't expect extra customer handholding if you measure your support team by time spent on issues or minimizing average ticket time. Sure, you need to operate cost-effectively, but the key word is "

A few weeks ago, Amazon Web Services held its annual AWS re:Invent conference. Unsurprisingly, they announced, yet again, a slew of new services, all meant to ease adoption and management of technology services. Yet, something felt a little amiss: https://twitter.com/avideitcher/status/804418718994407424 Not only are SaaS firms getting nervous, but plenty of large firms, as well. As Benoit Hudzia pointed out, many on-premise software giants, including Oracle/PeopleSoft and SAP, should be getting nervous (but perhaps are not):

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.

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 in LinuxCon/ContainerCon Berlin, I attended a presentation by Luca Bruno of CoreOS, where he described how kubernetes, the most popular container orchestration and scheduling service, and rkt integrate. As part of the presentation, Luca delved into the rkt architecture. For those unaware - there are many, which is a major part of the problem - rkt (pronounced "rocket", as in this) is CoreOS's container management implementation. Nowadays, almost everyone who thinks containers, thinks "

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.

Containers, the management and packaging technology for applications, are useful for many reasons: Packaging is simpler and self-contained Underlying operating system distribution becomes irrelevant Performance, therefore density, and therefore cost, is much better when working without a hypervisor layer To my mind, though, one of the most important elements in any technology is how it affects culture and incentives. For example, MVC development frameworks are helpful for many reasons, but the most important is that it encourages (and sometimes forces) a cleaner way of thinking about and building software.

It has become commonplace to forecast that Uber, Lyft and other ridesharing services are a strategic threat to car manufacturers. After all, if "everyone" uses Uber, why would they bother owning cars? The problem with that argument is that it assumes that "everyone" lives where Uber and Lyft are headquartered: in a dense urban area with very little parking, going to other places nearby where there is lots of traffic and very little parking.

Today, I had a very interesting discussion with Rich Miller, a consulting colleague who has been around the block more than a few times. One of the interesting points he raised is that Amazon's AWS pricing doesn't quite work for enterprises. Let's explore how it is a problem and why it is so. At first blush, Amazon's pricing is intuitive: use an hour of an m4.xlarge, pay $0.239; use 2 hours, pay $0.

Architecture determines capabilities. This is not new. Anyone who has planned and architected a new product, or has tried to retrofit capabilities for which a platform has not been architected, knows it first-hand. Yet, time and again, I come across products that have not been planned, and therefore architected, around reasonably expected capabilities. Sometimes I see these as a user. Last week, a client wanted to give me access to their Dropox Team account, so we could share information.

A lot of ink has been spilled (if that term still can be used in the digital age), on the coming driverless "revolution." Yet a much simpler "evolution" is long overdue for automative technology: the inside. Anyone who has replaced any component on a car - dashboard, door panel, side-view mirror, radio, engine part, or any component at all - is familiar with the swamp of wiring that snakes its way behind every panel on the car.

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.

For a long time, I have felt that SSL/TLS - the protocol that secures your communications with Web sites, mail servers and most everything across the Internet - is broken. It is broken to the point that it is fundamentally insecure, except for the most technically-aware and security-alert individuals, who also have the time to check the certificate for each and every Web site. SSL is supposed to provide three guarantees:

For the last few weeks, I have been trying to unravel the connection between the value of talent and open-source. Inevitably, some products have a high level of importance but few people who truly understand it. This creates high demand with low supply, increasing the value of those people. But that isn't special to open-source; it is true for any product with high demand + low supply. These just happen to be open-source.

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?

Earlier this week, a really smart architect and I were evaluating various methods for managing software code changes, bug fixes, releases and major features. We both were in agreement with the primary direction, a popular one in nimble companies. Have a primary "trunk" or "master" branch; Any commits to "master" automatically get built and tested and ready for production (and possibly deployed); Any changes occur on "feature branches", temporary parallels streams of development that eventually - hopefully sooner rather than later - merge into "

Can robots replace burger-flippers? How about lawyers? Tools have been around for thousands of years, making a human job faster and easier; try banging a nail in without a hammer. Machines, complex combinations of parts that are either human-operated or human-started, have existed for far less than that. With a Gutenberg press, you can print hundreds of copies of printing with just 1-2 people operating the machine. A washing machine will wash your clothes after you just press the right buttons.

Sometimes I am amazed by open source software... even as I contribute to it. The largest repository of public open-source projects, GitHub, has over 35MM repositories in it. Granted, some large percentage of those are private, and therefore closed-source, but even if only half of those are public, and by all accounts it is much more heavily weighted towards open, the numbers are in the tens of millions. Add in other source hosting locations like BitBucket and sourceforge, as well as privately hosted sites like GNU Labs' git.

It seems every day there is another article about how "vulnerable" the Internet of Things (IoT) is. Here are two choice excerpts from the last year: "Hackers Remotely Kill a Jeep on the Highway," Wired, 21st July 2015 "Security Researcher Claims to have Hacked into Flight via Entertainment System," CNN, 19th May 2015 While these are major life-threatening issues - one cannot compare a malicious actor disabling your iPhone while you are on it with someone talking control of your car going 110 kmh down the highway, let alone a plane flying at 35,000 feet and 600 mph!

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 "

After more than twenty years working in many companies, many of them as a consultant often dramatically improving operations, I have received a blessing and a curse: Blessing: I see improvements and benefits potential almost everywhere. Curse: I see improvements and benefits missed almost everywhere. The other day, I spent six and half hours in a hospital emergency room (ER) with a family member. Fortunately, everything is fine, and they are healthy.

Over the last few month, I was reminded - twice, painfully each time - about the impacts of good vs. bad software design choices, especially the impact those choices can have downstream. Ironically, it is not only - or even mainly - the creators and primary users of the software who are impacted, but others unforeseen at design time. Installing an Operating System Anyone who has installed an operating system on their laptop or server - or even smartphone - is familiar with a series of questions, choices and answers, as they configure the operating system.

Is hard return on investment all there is? In exploring business (and tech) projects, we have a tendency to think about the immediate, quantifiable ROI. Yet, there are times when the soft costs or other benefits outweigh any measurable ROI, and sometimes are even worth a negative ROI... in the short term. This was highlighted to me again yesterday. A colleague of mine is heading up a project to move tens of thousands of VMs from on-premise to the public cloud.

For the last year or so, my various news feeds have been filled with dire warnings about the "Rise of the Robots." Apparently, the advances in robotics - hardware and software - are now beyond relatively simple home vacuums, and are poised to become the new drivers and waiters, gardeners and barbers. Simon Wardley has argued that they even could replace higher-intellect roles, such as CEOs. Many are worried that this is an economic disaster in the making, as millions of blue-collar and possibly white-collar jobs could be at risk.

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.

In the last article on serverless, I referenced the old ad in the New York City subways for a trade school. Their tagline was similar to, "technicians will always be needed, because things always will break." We technologists are familiar - intimately - with fixing broken things. Sometimes, it is our own software, devices or infrastructure; other times, it is someone else's. Either we have become responsible for it, or we need it to work under certain circumstances where it simply fails.

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.

One of the hot words over the last few years has been "Bimodal IT". I won't go into a complete definition - let's leave the people who make much money off of the idea to explain it. The short form is that some technology activities are more traditional, sequential and driven by a focus on safety, while others are more innovative, agile and driven by a focus on new risks.

A few days ago, I had a conversation with a friend of mine who told me something shocking: a particular cloud company's gross margins on cloud products are below -40%. That is not a typo, it is minus 40% or worse. Essentially, the company is doing one of: burning investor money; running down their own cash reserves; borrowing from banks or the market; or subsidizing from other business lines. Whatever the method they are using to stay afloat, they are burning quite a hole.

The great strength of technologists is that we innovate constantly, always looking for a better world. The great weakness is that we sometimes fall in love with the solution, the technology itself, without regards to its applicable value in the real world. How do we determine if a given solution really has a chance of being adopted? The two biggest determinants of a solution are usefulness and usability. Usefulness "

I used to hate taking long day flights. If I had to spend 12 hours in the air from New York to Tokyo, or Zurich to Bangkok, or Tel Aviv to Newark, I preferred overnight flights. Even since the advent of on-demand entertainment, personal video screens and portable devices like the iPad, those flights just seemed to last forever. So most of the time I would fly overnight. However, the timing didn't always work out, and overnight flights tend to be significantly more expensive than all-day flights, often much greater than 50% more.

Where will VMWare be in 5 years? For many years, VMWare was practically synonymous with virtualization. It provided multiple virtual servers on a single physical server, with a great feature set, good (for its time) management interface, and enterprise customer support. Lately, VMWare has been under threat, primarily due to 2 factors: Public Cloud: When deploying to the public cloud, customers don't just wash their hands of managing compute hardware, storage and network.

In the cellar of Westminster Abbey in London, lies a lovely little café called the Cellarium, with all of the architectural design and feel of the Abbey. Of course, as it is in the heart of London, it has good tea as well. Earlier this week I was privileged to have a fascinating and wide-ranging discussion with Adrian Colyer, which led to 2 provocative questions: Will Microsoft open-source Windows?

Yesterday, Vala Afshar tweeted out the following https://twitter.com/ValaAfshar/status/706678404884652032 ... to which Paul Graham of YCombinator fame responded: https://twitter.com/paulg/status/706710881652965376 I beg to disagree with Paul, but not how you would expect. One of the valuable intellectual behaviours one learns from studying Talmud is to analyze a situation from all directions, teasing out all potential logical explanations, no matter how strange or absurd they appear at first. If all of the following is true:

I love tech. Despite an MBA and a decade of consulting and running a start-up or two, deep down, I always will be an engineer. One of the most important lessons I learned as a young engineer 20 years ago at Morgan Stanley - courtesy of Guy Chiarello - is that the technology is only the means, not the end. Understand the finances, the market, even the politics if you want to do something with technology, even just inside a company, let alone outside.

This morning, I paid a visit to the American Citizen Services department of a US Embassy, for passport-related services. Anyone who has been there knows that this is not exactly an efficient experience. You need to make a reservation online in advance The security makes TSA look like a luxury hotel: no bags, no backpacks, no phones, no earphones, no Kindles, no food, no drink. You only are allowed your documents, wallet, keys and printed material.

There is an old (obviously) English saying, warning people not to be "penny-wise and pound foolish." As the main British currency is the pound, 1/100 of which is a penny, someone who is penny-wise and pound-foolish is someone who refuses to invest a small amount now, leading to a much greater cost later. No matter how often I come across companies being penny-wise and pound-foolish, I never cease to be surprised by it.

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.

When at the Container Summit, I heard a great (if somewhat perverse) line from Jacob Groundwater of New Relic. I liked it so much, I tweeted it out immediately: If you want people to drive slower, don't give them an airbag; put a spike in their steering wheel! While a rather morbid image, Jacob hit on a core truth: if you make dangerous activities safer, people will do more dangerous things.

Yesterday, I had the pleasure of attending Container Summit NYC, arranged by the great folks at Joyent. The first speaker, Dave Bartoletti of Forrester, gave a broad overview of cloud computing - private and public - and container adoption. One of his themes was the methods by which companies adopt new technologies, particularly cloud and containers, and the benefits they gain. New technologies enable new ways of operating. While some technologies simply make it easier or cheaper to operate in the same way as before, most enable new methods, new processes, new ideas that previously were difficult or impossible.

Are ad blockers good or bad? Does it depend for whom? Advertisers and content Web site owners are up in arms over ad-blockers. A report from August 2015 suggested that the industry lost $22 BN in revenue in 2015 due to ad-blockers. Yesterday I visited a news site on my phone - I believe it was Forbes - and it refused to show me the page until I turned off the ad-blocker.

A few weeks ago, a colleague showed me a technology that was fascinating in and of itself, but the strategic ramifications are even greater. For those of you who are technically inclined, look at these links: https://hub.docker.com/r/microsoft/dotnet/ https://hub.docker.com/r/microsoft/aspnet/ https://github.com/aspnet/home These are, respectively, the Linux docker images for running Microsoft .Net and ASP.Net apps, and the open-source repository. This is quite cool technically. After all, apps compiled for platform A, especially tightly closed platforms like Microsoft, usually aren't meant to run on platform B!

I have been pondering this article for quite some time, then came across a great similar quote from Bryan Cantrill: "Don't just reboot it, goddamn it! Debug it!" Since Bryan always is a great speaker, watch it here. Time and time and time again, I come across companies and people with systems that are misbehaving. Time and time and time again, people suggest "why don't we just restart/reboot it?" What these people really are suggesting is, "

At the risk of kicking someone when they are down, let's look at... GoPro. GoPro recently reported slower than anticipated sales, laid off 7% of their staff, and had their stock hammered (down 14.5% in a day). BusinessInsider did a straightforward if nice job showing their absolute revenue and relative year-over-year growth for the last 5 years. While total sales numbers are nice, the growth numbers aren't pretty.  

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.

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 "

Poor founders and CEOs; we really should have some sympathy for them. The sheer amount of information they need to know is mind-boggling. Everyone starts out with one area of expertise. For most startup founders, it is technology; for some, it is product or marketing. You quickly need to learn sales, and technology, and marketing. Then comes HR - since you need people to grow - and finance becomes important very quickly.

Yesterday, we looked at how the market values Yahoo, and tried to understand why a company with $6.3BN in net assets, and another $31BN in a fairly liquid equity investment is valued only at... $31BN! Interestingly, Daniel Morris pointed out an article in CNBC from September which argued that the issue is taxes. Essentially, Yahoo's investment is encumbered by a potential tax bill. If an when they liquidate it, the tax bill will be enough to wipe out the rest of Yahoo's assets.

According to several articles I have seen today, notably this Wall Street Journal report, Yahoo's Board of Directors are considering a sale of Yahoo's core Internet business. For quite some time, Yahoo has been a troubled company. To many people, it doesn't matter. But to those of us who enjoyed it as one of the first major Internet search sites, it is very sad to see. Marissa Mayer was brought on board to fix the company.

What does selling clothes to Macy's have to do with selling software, and cloud services, to enterprises? Everything. Earlier today, I was speaking with my brother-in-law, entrepreneur and consultant Kevin Pearl. Before starting a firm to improve capture of billing time for attorneys, accountants and consultants; before serving as a turnaround consultant; before building a firm that sold software to manage venture capital portfolios; Kevin ran a firm that sold clothing to large well-known clothing retailers.

Steve Denning has a great short article in Forbes, referencing Peggy Noonan on what Steve Jobs had to say about why big companies fail. The article is worth reading - actually, the entire Isaacson biography of Jobs is a great read - but here is the money quote: The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important.

In the last week, I have had several discussions with some really smart technologists, partially focused on what makes technology companies nimble and fast and, therefore, great. In the last article, we discussed hiring 10x people, and especially the way many great employees compound together to create up to 2 orders of magnitude faster companies. However, hiring really smart employees is necessary, but it is not sufficient. What these employees need is independence.

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.

In a world full of email, then SMS, then Twitter-based abbreviations for everything - ttyl, afaik, iirc, rtfm - do good, clean, clear writing skills still matter? Yes. Unquestionably, and without a second's hesitation, writing certainly matters, not solely for the pedantic nitpickers. Good writing skills greatly affect your business success. Secret of Success I once asked a very successful executive what he thought was the single most important factor in his success.

I have no idea why it surprises everyone. Every time some technology goes through the "hype cycle", or the sector as a whole goes through a "we're not in a bubble" bubble, inevitably, when the hype dies down or the bubble bursts, people suddenly "discover" business fundamentals. Often, it is not the people discussing it who discover it. Rather, they are the ones reminding everyone that the fundamentals count.

What are the three biggest impediments, or roadblocks, to fast product cycles, especially in the cloud? Incomplete Testing. If you are not 100% confident that your testing covers every known use case, you will be fearful of releasing. Actually, fear of the risk of deployment often is the "canary in the coal mine" sign that your testing is incomplete. The other sign is infrequent releases, defined in the Internet era as less frequently than every few days.

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.

Mark Twain attributed the phrase "Lies, Damned Lies and Statistics" to British Prime Minister Benjamin Disraeli, which suits the Prime Minister's known wit, although its provenance has been questioned. If Twain or Disraeli had lived in the days of computers and software, he probably would have coined the phrase as "Lies, Damned Lies and Performance Tests." Perhaps Twain's great novel of Americans touring the desolate Holy Land of the late 19th century might have been called, "

In a previous article, we invented "Conway's Corollary" - how design determines scale. Today, we will look at another case from the hottest technology of the last year: containers. When designing software - any piece of software - the most important criterion is not, "what features does it have," or "how well is it documented," although those are very important. It is not even, "how sexy is the user interface,"

When I went to business school, I worked closely with an incredibly smart woman with whom I shared a very similar method of thinking and mindset. When we would find the same responses to the same questions in the same manner, inevitably I would quote, "great minds think alike." She taught me that there is a corollary: "...but fools rarely differ." The great challenge in life often isn't to agree with someone, no matter how smart; it is to determine if you are both great minds thinking alike, or both fools who are not differing.

No, this is not about "White Hats" - security hackers who try to break into systems in order to strengthen them, as opposed to "Black Hats" - but really about what we can learn from white rats. In the last few weeks, I have helped solve a number of vexing problems on behalf of customers, both in technology and process. Each time I am asked how I do it, and each time the answer is the same.

With due respect to Manfred Mann's Earth Band, I just came across a great example of a business so blinded by their stale model that they cannot respond rationally to competitive threats: textbooks. Anyone involved in education, from students to professors to parents, knows that textbooks are exorbitant. There are several reasons for these prices: Market size: It is easier to sell 100MM Harry Potter hardcovers for $20 than a chemistry book that sells 20,000 copies.

Anyone who does Web-scale or information technology over the past two years knows containers. The primary reason is the success of docker in making not-so-new containers easy to build, deploy, manage and use. Personally, I think Docker containers are great. They provide a far more efficient level of isolation than VM virtualization, without sacrificing manageability. Docker itself, however, is a young company, and every now and then young companies, whose products are moving very quickly, make silly mistakes.

There is a famous saying, known as Conway's Law, which states that: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations It means that when your organization builds a system, its structure will reflect the organization that created it. If you have 3 teams - database administrators, system administrators and Web developers - then your system architecture will have 3 distinct components: databases, servers and Web UI.

Is your user management an afterthought? For most companies building technology systems, how to manage users - the process of creating, managing, grouping and linking accounts - is bolted on later. After all, you fully expect your users to spend the bulk of their time using your service, not logging in to or managing your service! So you use some reasonably standard user management library, and when you have to worry about groups and organizations, you sort of bolt it on.

The Prisoner's Dilemma is a famous model in game theory. I am far from an expert in game theory - although I did have the pleasure of meeting Prof. Israel Aumann, nobel laureate in economics and world game theory expert - but I can grasp, and sometimes explain, some of the basics. The Prisoner's Dilemma describes a situation wherein if everyone cooperated, they would have the best outcome. However, because they are prisoners and cannot coordinate with others, they make independently rational decisions.

Infrastructure-as-a-Service, cloud servers, whatever you call them, have been around for years. Amazon is the clear leader in the pack (and, according to Simon Wardley, is likely to remain so for a long time), with others like Rackspace, Google Compute Engine, and Azure picking up much of the rest (fortunately for them, the market is plenty big enough). Digital Ocean, a company I mostly ignored for a while, takes kudos for speed and simplicity, and rapidly have become my go-to option for quick servers.

In earlier articles, we discussed How to Outsource and When to Outsource. Today, we turn to when not to Outsource. At first blush, we expect not to outsource when our candidate does not meet at least one of the criteria for outsourcing listed in When to Outsource. Better Results: Your outsourcers can get you better results, improving any one or more of quality + time-to-deliver + cost without negatively impacting the others.

Although the title for this article might imply suggestions for Proctor & Gamble's IT department, instead we will address how badly code can "smell" and how and when to prevent it. In business as in software, the concept of a "smell test" is a base instinct for if something is a bad idea or implementation: if something smells bad, it probably is. One of my favourite technology bloggers, Adrian Colyer, wrote a recent article about a fascinating analysis of open-source projects, primarily Apache, Eclipse and Android.

What do Heinz Ketchup, QR codes and adult Web sites have in common? Apparently, everything. QR codes are those two-dimensional barcodes you often see on ads or consumer products. Just like regular barcodes encode numeric information, QR codes encode full text. They often are used to reference Web addresses, or URLs. For example, the following QR code, when scanned with a mobile phone app, will link to this site:

Friday I had lunch with a friend who does marketing for a pharmaceutical company. He described to me the process by which he manages major ads. "Ads are very expensive," says he. "First you have to develop the concept, which can be $10,000 or more. Then the production costs for the real ad are $100,000 or more. Finally, the actual costs to air the commercials easily can run $500,000."

When does a personal technology - a computer, a smartphone, a watch - "grow up"? There is a slow but continuous process I have observed with every new personal computing technology. Stage 1 - Child: The new technology provides unprecedented flexibility. It allows you to do just a few new things, but its real appeal is allowing you to do old things on the go. It does so by being a mobile accessory to, or child of, existing "

Yesterday, I had an enjoyable late evening conversation with a colleague of mine, a first-class information security and compliance consultant. We have collaborated on several projects in the past, and it always is a pleasure working with him (contact if you need one). One of the issues we discussed is why so many companies feel their infrastructure costs - both data centre and cloud - are too high. Of course, "

Pricing is one of the most important - and mysterious - parts of a business. Price too high, and you lose customers; price too low, and you leave lots of profit on the table. An entire price consulting industry exists, with great leaders like Patrick Campbell of Pricing Intelligently. One important rule of thumb is that input costs should almost never determine the price of a product. What your costs do is have two effects:

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.

I have always loved the contrast between companies that are quick and light, focused on doing the right thing, and are nimble in execution and change on the one hand, and those that must plan everything down to the minutest detail before beginning, execute on their plans precisely... and are thrown off balance by change. In my Wall Street days, I worked for two such companies. Both could be defined by "

Following on our review of Mary Meeker's Internet Trends report, today we will look at the "Re-Imagining" section. On slides 28-44, the report looks at business processes and how they have changed over the last several decades. Here are some salient examples: Document signing - ink-and-paper to DocuSign Physical payments - cash registers to Square Benefits - paper files and brokers to Zenefits As exciting as the enterprise space is, not one process is new.

This week, Mary Meeker of KPCB has released her "Internet Trends" report. I look forward to the release of this report. While I rarely can sit through a nearly-200-slide presentation, the insights in here always are thought-provoking and make it worth my while. I remember Meeker back in my Morgan Stanley days - unfortunately, I never had the privilege of working directly with her. If you have anything to do with the technology business, read it.

In earlier articles, especially here, we have discussed why great product management is crucial to a company's success. It is the role that is responsible for a product as a whole, the only one that aligns what the product should do, what features it has, where to offer it, at what price points for which packages. Yet many companies seem to do just fine for an extended period of time without product management, especially in the technology sector.

For a very long time, corporations treated their corporate networks as safe protected environments. The data and applications inside that network are: confidential and must be kept safe from unauthorized access (protect from loss), and crucial to business processes and must be kept accessible to employees (protect from denial of service). Over time, however, two trends have challenged these assumptions. First, more and more business-critical data has migrated to the Internet.

I have been impressed with Heroku for a long time. Their simple to use platform-as-a-service (PaaS) has made it incredibly easy for software developers to deploy applications lightly and cheaply, and then easily scale them up to production scale. As an aside, the very design encourages them to develop their software in a well-architected fashion; see "The 12-Factor App." Just as Amazon Web Services infrastructure-as-a-service (IaaS) EC2 abstracts away hardware, so a PaaS abstracts away the operating system, allowing software managers to focus on software.

One of the hardest challenges in business is knowing when to use an interim solution and when to start over from scratch. From a pure financial perspective, interim solutions almost always win out. I see this regularly in the software industry. The progress looks something like this: You (i.e. your company) write a piece of software. It is successful and useful and sells and grows. Over time, you add more and more features and capabilities, leading to a more useful but more complex product.

Knowing how to outsource a process is challenging enough, and requires serious operational management and help, but does not involve making strategic decisions. Conversely, knowing when to outsource is far more challenging, as it involves making decisions with imperfect information about the future. Caveat: Use this as a starting point, a framework, but do not use it as your sole decision-making process. Get serious help; we are here. The Why There are only two reasons why you should outsource something.

For almost all of computing history, we have interacted with computing devices via keyboard for input and printer, then screen, for output. Computers are logical devices, and require clean, defined logical statements to interact. Thus, we use precise text. Human interactions, on the other hand, are less precise but much richer. We interact via touch, sound and sight - both the precise written word and visual pictures. For most of human history, the overwhelming majority of people, upwards of 99%, were illiterate.

In business, there are two benefits that accumulate to large or diversified companies: Economies of Scale Economies of Scope Economies of Scale are the benefits of from doing more of the same. If you make 10MM laptops a year, your cost per computer will be cheaper than if you make 100,000 laptops per year. These benefits come from a number of sources: Purchasing Power: Since you are buying components for 100x as many LCD screens, you can negotiate better prices.

TrueCrypt was a great open-source encryption program. It created files that, when opened by the program, looked to your computer like an additional drive. Any files placed in that drive would be encrypted and protected from prying eyes. Why would you do it? To keep files protected on your computer. To send files securely from one person to another. To protect files that you might store in the cloud, for example, on Dropbox.

Which do you hire, developers or engineers? Nowadays, the most popular programming language is JavaScript, or, by its correct name, ECMAScript. Since "Eck-Ma-Script" is not a great marketing name except, perhaps, for a language for Ghostbusters EctoPlasm, it is not surprising that everyone still calls it JavaScript or just "JS". Whether this is a good thing or not, and whether JavaScript is the worst or best language invented, is not a topic I am too interested in.

I often notice the incredible value of great product management. Unfortunately, it is something many experienced people do not get, simply because it is the one area of a business, and especially a startup, that cuts across the company. Every other group has a clear line of responsibility: Engineering builds the product. Marketing defines who will buy it and drives awareness. Sales sells it. Customer support supports it. Finance manages the cash, P&L and balance sheet.

Sometimes, you build marketing collateral for a market that is completely unexpected. And while on the way, it teaches you, once again, why Steve Blank, Eric Ries and Co. are right: everything you rationalize and think about is only an opinion about the way the market will react to it; facts exist only in the real world. I have a friend who is a very experienced technology consultant, Reuven Lerner.

Last week, Flipkart, India's largest e-commerce firm, and its fashion subsidiary Myntra, announced that they shuttered their mobile Web sites. According to the article, which has a good analysis on zdnet, their desktop Web site is still active, but they are considering shutting that down as well. Indeed, if you go to flipkart.com or myntra.com from a desktop browser, the site works just fine. Change your User-Agent to iOS or Android, and you get a link to their platform-specific mobile app.

Yesterday, I read an article which claimed that 30% of people have never backed up, while the overwhelming majority are way behind on backups. In the early 1990s, about a year into my very first job out of college at a large global financial, I ran the server backups. Yes, in retrospect, I wonder what they were thinking giving that level of responsibility to the inexperienced kid I was. Either way, it was a great learning experience.

When do you buy? When do you build? This question of "buy vs. build" is at the heart of many a debate in companies, not only inside engineering teams, but between engineering, product management and executives. Fact #1: Engineering is Hard Engineering is very hard. Despite the enormous advances over the years, and the number of system tools and development frameworks and languages, every one of which is touted as a "

This morning, Adrian Colyer posted his morning paper on a "functional programming." Most readers of this blog are not deep into different programming paradigms, so I will give a very short layman's overview here. For those who are comfortable, jump ahead a few paragraphs. (For the real experts, please do not nitpick on the details; the point is only to give an overview, not to debate the fine points.)

Once in a while, we come across a perfect example of how everyday technology can improve our understanding. It is not radical new technology, like nanoparticles fighting cancer, but great usage of tools that are widely available. Understanding Math I earned my Bachelor of Science in Electrical Engineering many years ago. While I did well at my alma mater, like most people, I struggled with visualizing complex mathematical principles. Sine waves are easy to draw and see, but start doing more complex forms, then head into Fourier Transforms, and even the smartest get lost.

There is a belief in startup-land that you have to be younger than ___ to successfully innovate. To some extent, that is driven by the youth of the founders of a few highly successful companies like Facebook and Twitter, magnified by the adoring media coverage they get. And yet, even when I was back in my 20s and 30s, there was a nagging presence in my head that said, "

Passwords are insecure and annoying. I get that, I have written about it, and I experience it. So lots of companies and organizations are working on replacing passwords with something that is both more secure and more convenient. For example, Twitter's Digits service. Other approaches, like 1Password's password manager, make passwords easier to manage and auto-generate, so they simultaneously can be more secure and more convenient. Then there are "

Late last night, Hunter Walk, of HomeBrew Seed Stage VC, tweeted out the following: This shouldn't be too surprising; people and businesses buy the machine once, but the K-Cup refills are bought over and over again. This is why Keurig has been so intent on keeping machine users buying their coffee, by any means necessary. A year ago, I wrote how I found a mention in their annual report about digital rights management (DRM) to force Keurig machines to accept only "

Two months ago, I posted an article about a United Airlines series of failures that, if not so painful for their paying customers - and their employees too - would be laughable. Yesterday, I had the pleasure of reading an interview with the legendary Gordon Bethune, who turned around Continental Airlines in a single year, from a loss of $600MM in FY1994 to a profit of $225MM in FY1995.

Two weeks ago, we argued that, in the face of competition (and there is always competition), "Premium Pricing Just Doesn't Last." At the same time, there always will be premium priced products - Tesla and BMW, Apple Watch Edition, Oracle - but the question is how long these can maintain significant market share? A smart commenter, amelius, raised a fascinating point. Amelius compares premium pricing for substitutable products to restrictive licensing for software.

About five months ago, I looked into the "Not-So-Simple SIM Card." In short, I called for the abolition of the SIM-to-carrier-to-number tie. For those who never change carriers or travel, this doesn't matter much. You get your phone, you go to your carrier store - or a local retailer like RadioShack (RIP) or BestBuy - sign some paperwork, get a card, insert it into your phone... and never worry about it again.

After our article last week discussing the economics of moving into AWS vs. do-it-yourself (DIY), Jim Stogdill wrote an excellent follow-up about when enterprises aren't moving into the public cloud; Simon Wardley - whose strategic situational awareness mapping is in a category by itself and should be required reading for anyone responsible for strategy - continued with his input. In Jim's words, private clouds are like SUVs; they rarely make sense economically, but sometimes you buy them anyways because:

In one of our earlier discussions about cloud, an astute reader pointed out that one "downside" of public cloud, especially one like AWS, is that they make very few guarantees about your instances. While the system as a whole has service level agreements (SLAs), your particular instance does not. To quote: "If your instances go down you're going to have to deal with it" The underlying assumption, of course, is that you have better control over the level of availability of your particular instances and their underlying hardware, especially scheduled maintenance, when you control the entire environment rather than leaving it to a cloud provider like Amazon or Rackspace.

Do you have SLAs with your customers? Dirty little secret: they don't matter. All that matters is customer expectation in real time. You are running a service. You know that your enterprise customers are highly sensitive to availability, since they use your service to help them make money. Perhaps they even use you as part of their customer-facing platform. Nonetheless, you know you cannot provide 100% availability, even discounting planned maintenance.

Yesterday's article on the short life span of premium (and especially ultra-premium) pricing led to a robust discussion on Hacker News. In the article, I used Amazon Web Services (AWS) as an example of a company that actively tries to cannibalize itself. A smart commenter pointed out that AWS pricing, while falling continually, has nonetheless fallen more slowly than Moore's Law, according to which equivalently-priced capability should double roughly every 18 (or 24) months.

If there is one truism in the technology market, it is that premium pricing just doesn't last. If you are first to succeed in a new market - which is distinct from first to a market - then you often have a premium price product because you are the "first" and often the "best". The problem is that it just doesn't last. No matter how good your IP (Intellectual Property, like patents, not Internet Protocol), eventually competitors catch up with "

The browser is the single most ubiquitous piece of software on the planet. Nearly every computing device has at least one one. Because of its ubiquity, and its use across multiple applications from open (Google "how much does a banana weigh") to private (browser-based email) to secure (office applications or banking), it is also a source of many risks. This article will dig a little deeper into issues of browser security and privacy.

For years, people I have known in the VC business, as well as entrepreneurs who have been funded by VCs, have discussed the 7-2-1 rule. For every 10 investments a VC fund makes: 7 will fail - "dogs" 2 will hang around, perhaps returning the initial investment - "zombies" 1 will be a great success - "superstar" This formula is why VCs are willing to take such risks; they expect many companies in their portfolio to fail.

What do you do when you want to move towards more rapid deployment, perhaps as close as possible to continuous delivery, but the culture and incentives push against it? This is the exact issue I have had at several clients over the years. When brought in to improve their operational performance, I found that, with all of them, a major issue was instability due to deployments. The flow looked something like this:

How did Lenovo do something so inane as fundamentally breaking their customers' laptop security by installing Superfish? What is Superfish, and what is wrong with it? I have often asked clients to consider, "what business are you in?" The right answer is not, "to make profits", or "shareholder return", because those are bland, meaningless statements. Every business wants to make profits and return value to their shareholders. Peter Drucker said, "

What does a great daily paper by a smart thinker have to teach about good product management? About a week ago, I came across Adrian Colyer's great "Morning Paper". I have no idea how I missed this before. The "Morning Paper" takes a look at some trend, research or paper in technology and investigates its impact on technology development and, of course, by extension, business. The Paper is not for the faint of heart or those without pretty deep technical background, at least from the editions that I have seen.

You are reading this blog on WordPress. It is not a secret; any technologist with experience managing WordPress can look at the page and see that it is run by WordPress. How does WordPress show you this page? Here is what WordPress does, simplified: Look at the requested address, showing right now in your browser's address bar. Translate that address into a specific article. Retrieve the text for that article from the database.

"We made a small change and it brought down our customers for 4 hours." - colleague "Network issues caused outage" - GoDaddy "A configuration error... caused days of downtime." - Amazon "Facebook was down... for 2.5 hours." - Facebook Every one of us has seen human errors cause significant, revenue-affecting, downtime. Our stability instinct always is to tighten up change control to try and prevent a recurrence. In a cloud environment, though, our agility instinct is to be as nimble and loose as possible.

The Internet has been abuzz for the last week about a hitherto little-known clause in Samsung's "Smart TV" privacy policy. The news was most prominently covered in the Daily Beast, here. The Daily Beast includes a link to the entire privacy policy, but the important element is: Please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party.

How you do deployment is very important, and the technologies you use can have a direct and immediate impact on your bottom line. It also can make your employees happier, which leads to better productivity and lower turnover. But how does deployment technology directly affect your bottom line? Let's look at one. Docker is a "hot new" technology for software deployment. If you are running a cloud or IT business, you might be wondering, "

Early in my career, when I did technology for a very large financial firm, we started with dedicated servers for each business process. It was an easy way to track costs, manage risks and allow each business unit to maintain control. Unfortunately, it was also an exorbitant way to maintain control. As servers became more powerful and disk cheaper, processes utilized less and less of their capacity. Even more than the costs of the infrastructure itself, the costs of the staff to deploy, maintain and support each piece of infrastructure could kill profitability.

Continuing our series on cloud services, especially our most recent one, "How to Do True Cloud", we now turn to the technology that enables true cloud services. This article will go more in depth than the previous ones; after all, we are discussing technology services. However, it will not go so deep as to lose the business-side executives. Indeed, any great executive in technology needs to hold to two principles simultaneously:

Now that we understand what the cloud is, the types of cloud services, the difference between true cloud and hosting, why true cloud matters greatly, and how it makes you nimble, the inevitable question is, how do we get there? Or, to use our question from our last article, how do we get to say, "YES", to the customer who offers us $500,000 - or $5MM - if we are ready to run tomorrow?

In our most recent article, we explored why "true cloud" really matters: it has a significant impact on: Your gross margins Your speed As a company providing technology services, as opposed to products like software, you cannot get cloud-scale gross margins and speed - and therefore valuations - unless you are operating as a true cloud. Today, we will look at a different set of advantages to running your service as a true cloud: how nimble you can be.

In our previous articles, we discussed what cloud is, the types of cloud services, and the difference between true cloud and "market cloud", or hosting. The big question is, so what? You are a software provider offering a cloud solution. Does it really matter if it is "true cloud", or just hosted? Isn't it just a difference in architectural design, a matter for your engineers but not your customers or your bottom line?

Having looked at the definition (and misapplication) of cloud, its key characteristics, and the various categories of cloud services, or fill-in-the-blank-as-a-service (*aaS), we now turn our attention to the important difference between true cloud services and hosting services that are marketed as cloud. This is crucially important to vendors and customers! While it may seem, at first glance, as nitpicking, these are very important differences. They will impact a vendor's short-term and long-term profitability, viability and responsiveness, and a customer's ability to rely on a vendor.

In the previous article, we discussed what the (terribly overhyped) word "cloud" means. Before we start to delve into the difference between "true cloud" and "we just call it cloud", let's look at the different major categories of "cloud" services available. As we discussed previously, cloud services replace: Expertise with consumption Capex with opex Fixed costs with metered prices Unsurprisingly, you can use that model with any technology you consume.

Cloud seems to be the biggest buzzword in the last few years. Every technology provider, every services provider, if they aren't natively "in the cloud", they are providing a version of their offering "in the cloud." Although the term "cloud" seems pretty clear to marketers - personally, I am convinced many believe it means, "we can charge more for this if we slap the word 'Cloud' on it" - the majority of people with whom I speak, from engineers and support staff through executives, CEOs and especially customers, do not have a real understanding of what the cloud is, and why it matters.

What does "mind the gap" - familiar to anyone who has ridden the London Underground, a.k.a. "the Tube", have to do with coffee and power? It turns out, quite a bit. Starbucks' largest metropolitan deployment outside the US - and the largest in Europe by far - is in London, with ~250 stores. Starbucks has become a very familiar English site, indeed. On the technology front, Starbucks has always been an early adopter and even a driver of new technologies:

In response to the Sony hack, in which not only valuable intellectual property, such as movies, was stolen, but also (previously) confidential emails, a number of experts have recommended increasing the usage of email retention policies. They go something like this: Email is confidential People put things in corporate email that they do not want seen outside the company Companies get hacked Therefore, we should limit the damage by forcibly deleting all emails older than some time period, say, 30 days The Wall Street Journal also had an article discussing the debate about email retention policies.

"The purpose of a business is to create and keep a customer." - Peter Drucker No matter how many times we say it, we forget it. We get caught up in operations, or competition, or marketshare, or share price. Yet a business, like a life, has a purpose: to create and keep a customer. I might add, "to keep that customer profitably satisfied." Earlier this month, a very well known Apple developer, one of the "

Recently, I had a conversation with a senior executive at a company about the firm's information security. The conversation, like others I have had, revolved around a sudden increase in interest in that security. To be clear, we are not talking privacy settings on Facebook (use them) or whether or not Snapchat pictures and messages really disappear (they don't). These people are seriously concerned about loss of data due either to security breach by bad actors targeting the company, or simple loss of data due to employee errors.

Today, we present the second guest post in the series by Ted Lloyd, editor of OnlineCISO. Yesterday, we explored why security spending need not be a bottomless pit, and how yesterday's tools, such as antivirus, can be evaluated using familiar risk management methodologies. Where then, should a business reinvest the funds previously allocated to antivirus solutions? Another analogy to the physical world can help to answer this question. Malware and variants are similar to microbiology in our physical world.

Today, we are honoured with the first of two guest posts in a series by Ted Lloyd, editor of OnlineCISO. Cybercrime has emerged as a multi-billion dollar business and spawned another mufti-billion dollar business to combat it. As 2014 closed, Gartner estimates that global spending on information security will top $71 billion representing a nearly 8% increase in spending over 2013. The trend and trajectory are expected to remain steady for 2015 as well.

Apple's philosophy for technology is, "just make it work." I had one of the early pre-iPod mp3 players. It was a great piece, lots of battery life, played every format out there at the time... and within a year I had replaced it with an iPod. Transferring music to this player and managing it was just an enormous headache. With iTunes and iPod, it "just worked". Fast forward to the year 2014.

I always get a kick when a long-storied company which is in decline tries to hook onto the latest, hottest market, thinking, "we will get into this market, and with our amazing brand, we will knock it out of the park!" This is the business equivalent of a Hail Mary pass... while throwing it off to the sides and into the stands, rather than down the field towards the goal line.

In the first half of this year, I noted that ReCAPTCHA was a lot like the "TSA of the Web" - an annoyance that is sometimes necessary to keep bad actors out and good (or, in the case of ReCAPTCHA, "real") actors in. I also noted that Google, itself, had publicized that it had broken ReCAPTCHA, rather than wait for someone else to do so. In that respect, ReCAPTCHA was lot more like the TSA - weak, broken, but good "

Bitcoin - and its focused leveragors and imitators like Ripple - have gained a lot of press and traction. The question that I keep coming back to is, what are they good for? I do not mean this in a cynical sense, but in a literal, "what is the best use case" sense? The answers I keep coming back to are two, and only two: Person to person payments International transfers I am, for now, ignoring the "

Probably the biggest story of the last few weeks has been the hack of Sony Pictures by North Korea (or the Democratic People's Republic of Korea / DPRK, naming convention courtesy of George Orwell). While hacks happen all of the time, this one is particularly notable for several reasons: It was directed by a state actor. The US Government officially responded and "named and shamed" the state actor, thus forcing itself to respond.

Safes. They are big, heavy, and make us feel, well, "safe" about our valuables stored inside. Historically, safes were controlled by a series of complex gears that only the correct series, or "combination", of dials would open. I loved the illustrations for gears and other mechanical devices in David Macaulay's "New Way Things Work". Digital safes, whether the professional variety of the home variety, were created largely for convenience. They are faster to open, easier to share (and change) codes, and required less physical space for all of the gears.

According to a New York Times article, the major JPMorgan Chase (JPMC) breach was due to a single entry point: a single server in its vast array of servers, one that either has access to confidential data or acts as a gateway to the internal systems, was not fully patched. Does one patch really matter? It depends on what that patch is. A "patch" probably is not the right word for this.

A friend of mine, an extremely talented pulmonary specialist, recently moved to Israel. Like many other expats who like living in one place but working in another, he is commuting. Unlike many others, he is telecommuting.... 6-9,000 miles. Through an interesting arrangement, my friend is working for a company that provides remote Intensive Care Unit (ICU) oversight during the night shift in US hospitals. My friend does a long shift during relatively normal working hours - for him - watching many monitors in his home office, as well as having voice conversations via phone and Skype with health staff in the ICU.

The Internet has been abuzz with the discovery by Dani Grant, a writer at BuzzFeed, that she had found an easy way to explore - and print, and use - lots of boarding passes from Delta, even those for other people and other airlines. When you ask for your mobile boarding pass, Delta sends you a URL to click and view your boarding pass QR code as well as all of the "

Most products and online services today revolve around four basic actions a user does with valuable data: create read update delete For example, if you are managing a customer in Salesforce.com, you are likely to create a new customer record, read it before the next time you call, update it with details of the call, or delete it if it is no longer relevant. In true techie fashion, these have become known by their acronym as CRUD activities.

In yesterday's article, we discussed what product management is, and why it matters so much to companies. It also is important to early stage companies, who, at least in theory, cannot afford either the extra head count or the founder's time. Actually, seeing how crucial product management is to getting product-market fit - as Steve Blank would say, that is the very essence of a startup - it probably is more important for early stage firms, since they have little to no wiggle room.

This article is not a list of companies that have great products or product management, enlightening as it might be. It also is not a list of companies with terrible product management, although I could compose a very long such list, and the stories would be very entertaining! Instead, this is a discussion of why product management matters, and how you get great product managers. The genesis of this article is a number of conversations and interactions I have had with companies over the last year or so, several of which have had great product management, while others have been sorely lacking in the field.

A few months back, I looked at the growing tide of making movies on mobile phones. I was referring not only to the typical home videos that we used to capture on a large home video camera, now on our portable phones, but semi-professional and even professional films on your iPhone or Android. Specifically, I was concerned with what this trend means for high-end camera makers. This week, I saw a short - all of 1:22 - fantasy film called DragonBorne, which was done entirely on an iPhone 6.

The productive actions we take as humans in society have not changed in many thousands of years, among them: Communicate Write Draw Calculate How we do these actions has changed, from stone tablets and steles to papyrus to parchment to paper to notepads to computers to smartphones. In the computer era, the write/draw/calculate - which often form the basis for many other activities - have been dominated by what has been called "

Financial trading houses are always looking for a market advantage, no matter how small. It shouldn't surprise us; when you are dealing in markets that move billions of dollars in short time frames, a few milliseconds of advantage can make all of the difference. Because trading firms are incredibly sensitive to any advantage - or more correctly to feeling left behind (it is all about the feeling, isn't it?), many trading centres and exchanges have very strict rules about what they will provide.

Last week, I was having lunch with an old friend. We worked together many years ago building some pretty cool technology at a very large financial services firm. Each of us has over 20 years in the technology industry. He has continued to manage infrastructure, and is doing some pretty impressive advanced infrastructure management. Both of us have seen the big company and the startup, and both of us have experience a broad range of technologies - consumer and business and enterprise; infrastructure and applications; hardware and software - and we both truly love technology and the changes it brings to society.

A short while ago, I was looking at buying an iPod for one of my kids. It was a pretty straightforward transaction. My kid likes music, while an iPod is great for carrying lots of music around and listening to it, especially on road trips. As parents, we encourage our kids to listen to music, preferably a broad and diverse selection. But I didn't. And the reason is smartphones.

In the previous article, I examined Microsoft's announcement that it will open-source .NET, its impact on customers, and its more important impact on Microsoft's business lines. In sum, I believe that Nadella may be trying to change the culture at Microsoft from one in which they depend on customers being forced to stick with its Windows line to one wherein Microsoft is driven by market forces to develop products and services that customers actively want to buy.

Yesterday, Satya Nadella, Microsoft's CEO, announced that they will release the core of .NET, the Microsoft application development platform, as open-source. In addition, .NET will be ported to run on additional platforms, primarily Mac OS X and Linux. For Microsoft, the ultimate closed-source and proprietary stack company, this is an earth-shattering move. Developers have long had a choice of platforms on which to write applications. Java and its variants, Ruby on Rails, Node, Python, PHP, lately Go and Dart, the list goes on and on.

Managing change is a process, something between a science and an art, taught in all respectable business schools and management courses. There really are 2 reasons for teaching it: Management: If you are managing a team, a division or a company, you need to understand the emotional and psychological blocks to change, and what it will take to get employees and partners to support change. Marketing: If you are responsible for marketing a product to consumers, or creating an entirely new product, you need to have a solid understanding of what inertia keeps customers in place and what it will take to change them.

One of the challenges customer support and sales agents face is the balance between efficiency and humanity. The more efficient methods of communication often are very impersonal, while the personal ones are expensive and inefficient. On the one hand, a business wants to provide its services as efficiently as possible. This usually boils down to 2 key elements: Cost: Having an agent at the customer's home or office is very expensive.

Evernote and its competitors have been quite successful at helping users keep track of information. A major use case is Web pages. You find a Web page you like, but want to keep later for reference. Perhaps it is a reference manual to your car; maybe it is an API for the development language you are working on; it might be 5 interesting articles on educational theory. Whatever it is, you have a need to hold on to certain Web pages and their context for some period of time beyond the next 1-2 hours.

Today, BusinessInsider - about whom I should write more, as their "Top Stories" have become more sales promotion and less news, and thus I look forward to receiving their updates less than I used to, but that is for another day - published a piece by Alyson Shontell about the future of mobile apps. In short, they see mobile apps migrating towards the Web, with native apps more like bookmarks or small content holders.

The SIM card in almost all of our phones is a tiny smartcard, a computer, that enables your mobile device to connect somewhat securely with a wireless carrier. In the old days of mobile, there were 2 major competing technologies - GSM and CDMA. Most of the rest of the world went GSM; the USA went mostly CDMA. Unlike GSM, which had a SIM card, and thus could have (unlocked) phones switch carriers simply by switching cards, Americans bought their phones from carriers, and closely affiliated the phone with the carrier.

Last week, we looked at PepsiCo and its channel strategy for Pepsi True. A third possibility did occur to me - unsurprisingly, since I spend the bulk of my time in the technology world - that PepsiCo envied SaaS. Let's look at 2 companies, PepsiCo and Salesforce (numbers as of this writing): PEP: Market cap of $139BN, revenues of $66BN, operating profit of $6.7BN, revenue multiple of 2.1, P/E of 20.

For most of the history of mankind, we have built specialized machines to do work: plows to attach to oxen, hoes to till the field, screwdrivers to turn screws, eye examination appartuses (I have no idea what they are actually called) for optometrists to, well, examine our eyes. Over time, as these machines have become more sophisticated, we have found that they could work better if some of the manual tasks were performed by computer.

So we have yet another attempt to succeed at mobile payments, courtesy of Apple Pay. However, Apple has a very long history of taking inventions and putting them together in just the right way that they finally are usable, and take off. As Tim Cook said on Tuesday, "every other attempt looked at it from the perspective of the business model, rather than the user experience." Given the many high-profile security breaches over the last several years, I would like to take a look at the security implications.

Apple, arguably, had its most important launch event in years yesterday. Beyond putting its smartphones back in play with the iPhone 6 and 6 Plus, competing on specs with LG and Samsung, not to mention Motorola (Motorola? When did they come back from the dead?), it launched in 2 new categories: Apple Pay - mobile payments, for which a follow-up article will be launched this week Apple Watch - a more convenient extension to your phone on your wrist Apple Pay has enormous potential, but depends entirely upon Apple's iPhone business.

I love technology. I had an Apple II as a kid, did engineering projects in high school, and have worked in and out of the tech sector for years. But as cool as the technology is, it is the impact on a business, and organization, a society that matters. This is a lesson many engineers forget, focusing on the solution rather than the problem, but it is the reason any of these advances have value.

A few weeks back, Fred Wilson wrote about his investment in Figure1, a social site for doctors to share radiology images - X-rays, MRIs, CTs. The hypothesis behind Figure1 is that doctors can share images "en masse" across the network, leveraging the knowledge of many doctors to analyze, and benefitting every doctor who submits an image for others to read, or can compare existing images to the one that s/he is looking at this very moment.

With respects to JRR Tolkien, whose writing I greatly enjoy (Peter Jackson's movies somewhat less), I have been thinking about the changes in the infrastructure of transportation technology since a visit to the San Francisco Cable Car Museum a few weeks ago. I recommend it for a great short visit. It has history of the cable cars and the 1906 Great San Francisco Earthquake & Fire, lots of historical pieces, and the mechanism that actually drives today's remaining cable car lines.

Apparently, Apple has decided to partner with IBM in selling to the enterprise, as reported by CNBC and the Verge. Apple is open to new distribution channels, i.e. IBM, to expand sales of its iOS devices into the enterprise. There are a number of striking elements and open questions about this partnership. Jobs vs. Cook It is highly unlikely this partnership ever would have taken place under Steve Jobs. Referencing Ben Horowitz who was paraphrasing the Godfather, an Apple employee was quoted only last week in the WSJ as saying that Jobs was a wartime CEO, while Cook is a peacetime CEO.

Two interesting events came to light in the last week for me. First, I am working on getting a company towards compliance with the Payment Card Industry Data Security Standards (PCI-DSS or just PCI). These are the standards that govern the technology and processes you use to protect data when you handle credit or debit card transactions. An auditor checks your questionnaire or audits your systems and people, "recommends" changes if necessary, and then issues a PCI certification, which must be renewed each year.

I definitely will not be the first oracle to see a rocky future for Oracle, nor will I be the last. But the last quarter's results, released on Thursday, are particularly troubling. In short: Oracle's enterprise on-premise software business - Oracle's core - is simply flat. It did $3.769MM in revenue in 4Q2013... and $3.769MM in revenue in 4Q2014. It hasn't budged. Sure, its expenses for those sectors may have gone down slightly, but for all intents and purpose, it is no longer a growth engine.

Does a good technology architecture matter for a technology firm? Perhaps the better question is, when does it matter? The technologies that have developed as a direct result of the IT developments of the 90s and the Web developments of 2000s - scaling out instead of up, commodity hardware, loose coupling, statelessness, noSQL, map-reduce, etc. - have all had a huge impact on what it costs and how long it takes to build, deliver and maintain software and services.

Just under a year ago, I wrote how Starbucks and Apple drove adoption of WiFi. I also wrote that Starbucks was considering adopting, in its coffee shops, one of the competing wireless inductive charging standards, PMA, and not alternatives like Qi. This is reminiscent of the old Beta vs. VHS wars in the 80s, and Blu-Ray vs. HD a few years ago. In the end, someone with enough weight and enough network impact selects one, and it locks it in.

In Mary Meeker's just released 2014 "Internet Trends" report, there is a very interesting trend which I do not recall seeing in her previous reports. From 2005-2014, over a period of 10 years - a decade of significant growth of manufacturing offshore outsourcing, although there is a small shift back towards domestic with the improvements in robotics - one major element's manufacture, perhaps the most important one, is now almost completely domestic: mobile operating system.

TrueCrypt is gone. For a good number of years, TrueCrypt was the de facto cross-platform volume/file encryption standard. Sure, each platform (Windows, Mac) eventually developed their own encrypted volume option, but it largely depended on trusting the encryption and security of the platform developer. As anyone steeped in the world of encryption and security knows, and Bruce Schneier did enormous amounts to popularize, the only encryption you can trust is open source.

Is Anti-Virus Alive or Dead? That depends on who you ask. Certainly anti-virus makers continue to make plenty of money. Symantec, the largest anti-virus maker, earned $2,109 MM in consumer revenue, with nearly 50% operating margin in that segment. $1BN in profit is valuable in anyone's book. So why is Symantec, of everyone, trashing anti-virus? In a recent WSJ article, Symantec's SVP for Information Security said, "anti-virus is dead... we don't think of antivirus as a moneymaker in any way.

ReCAPTCHA is one of those parts of the Internet that we love and hate at the same time. A Captcha is a distorted letter/word/number picture that we need to fill in when we first sign up for a service; ReCAPTCHA is Google's version, developed by several computer scientists and acquired by Google in September 2009. It looks something like this: We hate it because it gets in the way of our doing what we want to on the Web.

I love some of the old technology deployment phrases. According to legend, most of these - eat your own lunch, boil the ocean, etc. - came out of the heyday of IBM. As an example, I know of one company that moved from customer support software to customer support software as a service (SaaS)... and their first customer was their own customer support department. While I like some things about how this company and runs its SaaS business and disagree with others, their willingness to take the plunge themselves has two benefits:

Goldman Sachs estimates that Bitcoin could bring potential savings of $167.5BN per year in regular transactions, ignoring the much higher savings in remittances. Where did it get that number? And how will payment firms - Visa, MasterCard, AmEx - respond? GS's number is straightforward. Look at the following graph: If retail and ecommerce together are just under $11TN in 2013, typical processing fees are 2.5%-2.9%, and typical Bitcoin processing fees are 1.

Brian Krebs, the cybersecurity blogger who first broke the Target attack, has reported that the hackers who infected Target's Point-of-Sales (POS) systems, did so via their Heating/Ventilation/Air-Conditioning (HVAC) servicing company. Unlike a simple home, large-scale office facilities have complex HVAC systems. On the one hand, they want the optimal temperature, humidity and airflow in their facilities. On the other hand, they are acutely aware of the cost; it costs a lot more to air condition a big-box store than your local townhouse!

This article has been in formulation for a long time, and is the result of my own experiences in many places: corporate IT, software startups, services (cloud) startups, consulting, and many other places. It includes the input of many people whom I respect - although many disagree with some of my conclusions - including consultants, executives, founders and venture capitalists. How should you organize your technology team? This is a difficult question to answer, yet critical to your ability to succeed.

Traditional software development looks something like this: Product management defines the product specifications, gives it to technical leadership Technical leadership / architecture defines the technical specifications, gives it to the engineers Software engineering builds the product, gives it to quality assurance (QA) QA tests the product, sends it back to engineering to fix any failures, when passed gives it to operations Operations deploys the product, and maintains it in production While this process varies somewhat in steps 1-2-3 for agile development, creating more of a feedback loop, the essentials of steps 3-4-5 remain the same.

In previous posts, most recently earlier this week, I discussed the benefits of testing and how admitting you have a problem is the first step, the first success, on the road to victory. Anyone who has managed engineers knows that they hate doing three things more than any others: Wasting time Writing documentation Testing Despite growing evidence that creating automated tests first and only then writing code to implement your business need (test-driven-development or TDD) is very successful and leads to faster, more stable and more reliable releases - which means more revenue for the company and, from the engineers' perspective, fewer nights of emergency bug fixes - engineers instinctively hate writing tests first (well, after too), and will take any opportunity to "

What happened to Apple? Everyone either loves them and talks of their inevitable ongoing success, or loves to hate them, and talk of their impending implosion. Earlier this month, well-known Harvard professor Larry Lessig wrote an extensive article listing his travails with upgrading OS X, iOS and iWork all in the same week. Of course, upgrading everything at once is probably a bad idea, but Lessig admits it openly.

Here is a radical thought: Microsoft should kill Windows. No, not the cash cow on laptops and desktops, nor the ones that give great views from their Redmond, WA campus. Rather, as Microsoft continually fights and loses to iOS and Android in the mobile space of tablets and smartphones, it should release an operating system that shares nothing with Windows, not even the name. Inside the walls of Microsoft headquarters, this idea is probably heresy.

Yesterday, Benedict Evans pointed out that APIs seem to be suffering death; many well-known services (in the literal, not technical, meaning) are disabling or removing their APIs - Google, Skype, etc. At the same time, many other, younger services, seem to heavily promote their APIs. Facebook is not young, but it has gone through many iterations; Twitter has its API, although it has been known to get into battles with third-party services that use their APIs to compete with Twitter's own interfaces (shades of Apple?

Yahoo released their newly revamped Yahoo Mail, or Ymail, in the last week. It is good to see Yahoo putting effort into bringing life and energy back to its products like Flickr and Yahoo Mail. The market for mail is fairly close. Gmail is in the lead with 425MM, Hotmail following with 325MM and Yahoo taking a close third at 289MM. How can Yahoo steal market share from the first and second place players?

SnapChat was supposed to be a safe way to share pictures or text for a short (and controlled) time. You take a picture or send a text with your smartphone, set an expiry on it, and only the recipient can see it only for the time you set. After that, it is gone, lost forever. A few months back, some smart engineers proved that snapchat doesn't actually delete the pictures, and you can retrieve them.

I am a big advocate of open-source software. I believe that, along with Amazon Web Services, open-source has been the single greatest enabler of startups in the last decade or more. Amazon made it possible to launch an online startup for pennies on the dollar of what it cost in the 90s; I still remember startups that raised millions just to buy and run their Web servers. Nowadays, you do it for a few hundred dollars per month.

I read a fascinating article in today's WSJ, available here, about how AOL was the first Facebook, that really understood the value of community. Unfortunately, as they became a public company, a "Taliban" of MBAs came in, focused on short term profit and their own reputations, and killed the real long term value of AOL. In many ways, I can appreciate his perspective. Many companies have been killed by naive MBAs who think the formulae and theories they learned in business school can "

So Zappos was breached. It happens every day, certainly far more often than we hear about in the news, and, I suspect, more often than is reported to the appropriate law enforcement agencies, primarily the FBI cyber crimes unit (whose exact name escapes me at the moment). I have done a lot of work in the cyber security space, in financial and retail, internal corporate and external facing, including compliance with the card industry's official standard for cyber security, the imaginatively-named PCI-DSS.

Open-source, as discussed in the previous posting on network equipment, is a fascinating world. Perhaps the best intellectual and business promotion ever written is Eric Raymond's "The Cathedral and the Bazaar." There is no question that open-source has led to an upheaval in the world of business technology, enabled entirely new industries, and benefitted the overwhelming majority of individuals and companies out there, with few tears shed for those commercial vendors that have lost business due to open-source competitors.

Over the last two days, a mailing list of which I am a member had an interesting - and sometimes sharp - exchange (pun intended) about whether or not the mass availability and advanced feature sets of Web-based, corporate-focused mail services, like Google Apps for Your Domain, are a threat to, and possibly the end of, internally managed collaboration products like Microsoft Exchange. This article will provide a short analysis of the arguments in both directions and a framework for analyzing when CaaS, or Collaboration-as-a-Service, makes sense .

In dealing with e-commerce solutions over the last several weeks intensely (and the last several years in general), I have come to the conclusion that there are four different categories of e-commerce solution providers: gateways, processors, providers and promisers. In understanding these categories, as in all projects where you have a defined goal, it is important to understand what your e-commerce goal is. Most e-commerce occurs where the vendor wants to sell something to the customer.

So having gone through the above (see previous posts), there are basically two choices when it comes to implementing licensing schemes. Sell the upgrade. Many sales systems, even fairly primitive ones, support this. You create a separate SKU for each major release, and possibly for each minor, and a separate license key scheme for each major release (but not minor). The licensing ensures that different minor releases within the major release will allow cross-upgrades (or downgrades).

In the previous post we discussed implementing Option A: Sell the Upgrade. Now we will address Sell the Plan. Sell the Plan has a lot of appeal for ISVs, especially when you start to sell to businesses, non-profits, or any group that budgets. The benefits are: Predictable cash flow. The reality is that most individuals and organizations that have recurring charges simply keep on paying them. This creates more predictable cash flow for your ISV business.

As a follow-on to the previous post about licensing strategies for ISVs, I would like to discuss the nitty-gritty implementation details. It turns out that the open market has not been very kind to mISV firms, and have left with very few options, none of which provides the desired flexibilities. This post will discuss "Sell the Upgrade." A follow-on will discuss "Sell the Plan." So you want to implement sell-the-upgrade.

For the last several months, I have been involved with a particular very small ISV, almost a micro-ISV (mISV), as it prepares for growth. One of the key elements we identified is that its pricing model - unlimited free upgrades - is not exactly conducive to good revenues and profitability. Although it seems obvious, it needs to be stated, and for several reasons. Founders sometimes feel that to charge for upgrades would somehow offend existing customers.

Welcome to Atomic Energy! This is the CEO's blog, with thoughts and insights about everything that affects business, economy, society, policy and, of course, technology. Comments on any blog postings are always appreciated, and Trackbacks and Pingbacks are certainly welcome. I look forward to interacting with many of you. Avi