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.

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.

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.

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

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

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!

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.  

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

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

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.