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”?

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.

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.

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.

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 "

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 "

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.

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.

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.

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.

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.

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.

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 "

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.

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.

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.

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.

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."

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, "

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 "

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.

Over the last week, I have had several discussions about the challenges to successful outsourcing. One person was dealing with manufacturing products in China; another was managing outsourced server maintenance and operations; yet a third had a financial technology management service provider. In all the cases, the question was the same: how do you know when it is good to outsource, and how do you make it succeed? Successfully outsourcing anything is far beyond the scope of a single article.

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.

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.

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.)

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.

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.

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.

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:

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.