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.

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.

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.

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.

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.  

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.

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.

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.

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 "