Another tale of Execs bottom-up Blindness : SAP, Oracle, [Insert Software Giant here] vs AWS

After watching this year's AWS re:Invent show, I can help but have this strange feeling of “déjà vu”. AWS achieve to deliver exciting new product and solution that take the industry by storm. GreenGrass literally take my last year prediction and makes it reality. What’s even scarier is that, with GreenGrass, AWS achieve the feat of unifying #IoT and #DevOps under a common platform. 

But my feeling of déjà vu didn’t come from the GreenGrass announcement. It came from the Step Functions announcement. And it felt like a textbook repeat of what happened to Detroit's big three when Toyota took over the US car market: Another case of bottom up blindness.

Step is the natural next step in the evolution of AWS product portfolio. It nicely complement the serverless lambda product and allow to organise your server-less logic flow in a transparent manner. 

But what is more important is the implication of such release. Step allow you to create and coordinate complex workflow. Which is just a step off having a full blown ERP. It is actually even better than an ERP as Step allow you to coordinate any kind of distributed application. Allowing you to define business process workflows that blend seamlessly business logic and application logic. 

24 hours before the release of Step, I was mentioning on Twitter that AWS just needed a good process workflow service to open up the ERP business. 

@avideitcher Yep, but they are working their way up , DB / BI -> need job / task / process workflow , then you add CRM / ERP

— Benoit Hudzia (@blopeur) December 1, 2016

One day later, Step Function emerged and it won’t be long before we see emergent ERP like functionality hosted on Step / Lambda. This release sound like a swan song for the like of SAP or Oracle. However they had plenty of warnings. But like many in other industry they buried their head in the sand. 

With Step, AWS has now completed offering all the building block to develop a full blown ERP without the hassle of taking care of all the nitty gritty details ( scaling, resilience, deployment etc..). To name some of the main one: 

• Database : Redshift / Aurora / DynamoDB 
• Data Ingestion : Firehose
• BI : Quicksight
• Business process : Step + lambda 
• Mobile : AWS Mobile

SAP, especially, should have taken a hint when they announced the availability of their in memory database on AWS in 2012 and AWS announce Redshift DB a couple of day later. 

SAP , ORACLE , and many other are repeating the same error that other industry giant fell for:

Failure to master small product :

They are addicted to the revenue they extract from the fat margin of the top 20% customers ( think Nestle, CocaCola, Caterpillar, etc..). These customer deploy these massive ERP systems while smaller customer tend to be thrown upon because the margin extracted from them are not high enough. Sadly, like with the automotive industry, history repeats itself. The Detroit's big three lost to Toyota because they didn’t care to lose the small car market. Margin where small enough they deemed that Toyota could have the small car market share as long as they retained the higher end one. However by doing so Toyota gained a foothold and worked its way up the food chain while they lost market share. AWS is doing the same thing. It started with the infrastructure and is now on their doorstep looking at their crown jewel. By losing the smaller product mastery, they lose the knowledge necessary to deliver product for the companies that will become the giant of tomorrow. 

Failure to embrace cloud : 

SAP sold their hosting operation in 2009 to T-Systems. They literally sold out all their expertise that would help them transition to offer solid cloud solution. They have been left in the dust by the competition and are fooling themselves if they think they can catch up. Elisson on the other side is trying to fool its shareholder by promising to catch up AWS. However at the current rate of their infrastructure investment they will reach current AWS infrastructure size in FIVE YEAR !! 

Failure to simplify their stack :

Anybody who used an SAP or Oracle system knows how painful it is to deploy the simplest web service .. let alone an ERP system. Moreover, it is almost impossible to learn about the systems if you are not working for either a company that use them or the companies that produce them

Failure to learn : 

These software giant traditionally didn’t run their own systems. And to be honest, hardware and operational cost was often a fraction of the overall license cost. Because of that, it was easy to tell the customer to throw more hardware at the software problem. However, everything change when you start to offer your solution as a service. And SAP experienced this the hard way with their SAP Bydesign solution (discontinued in 2013 and revived a year later). Rumors was that the company was spending 7 euro to run the system for every euro it was getting from its customers.

However, they didn’t learn from their mistakes and change their approach to build, deliver, and run their systems. Look at S/4 HANA, even today you cannot run it on anything else than the humongous X1 instance. And this lack of learning seems to be widespread among the software giant industry. Surprisingly we are almost 5 year after HANA availability on AWS announcement and I have yet to see a customer running a production HANA on AWS. 

actually they don't us it for prod @jplsegers if you read the case study its only test/dev ... pic.twitter.com/m3hT7bU7au

— Benoit Hudzia (@blopeur) November 16, 2016

Because of these failures from bottom-up blindness, these companies easily fall prey of the Tower of Hanoï fallacy and as a result they cannot :

• transition to a new value chain
• acquire new technical skills/knowledge
• expand to new market and business model
• compete with ecosystem (cloud) natives
• manage revenue stream self cannibalization

Traditional software giants have feet of clay and AWS already chipped its way up to the knee without them noticing.

[Links of the Day] 31/08/2016 : Open Lambda and consensus algorithms

• Open Lambda : allow anybody to run a local lambda platform similar to AWS lambda or Azure Function.
• AllConcur : the authors propose in this paper a distributed system that provides agreement through a leaderless concurrent atomic broadcast algorithm. What is interesting is that the authors claims a 17x performance increase vs the leader based solution. However, there is a catch in there assumption : "We assume a model of reliable communication—messages cannot be lost (only delayed). This is a reasonable assumption if we consider a reliable protocol, such as TCP." I think that here we might hit a major issue as even with TCP we can have duplicated/ lost message. Paxos make not such assumption, Lets see if the idea can be adapted to an unreliable medium. 
• Flexible Paxos : in this paper authors provide a proof that majority agreement isn’t required by Paxos and the sets of nodes required to participate in agreement (known as quorums) do not even need to intersect with each other.

[Links of the day] 25/01/2016: Unikernel Debugging, Web Data mgmt book, Nano Lambda

• Unikernels are unfit for production : while i don't agree with a lot of the arguments ( and the lack of concrete data supporting them) one really struck : unikernel are really hard to debug. Unless you have a toolkit like Erlang where you can remotely login / debug unikernel are really a tough nut to crack when it comes to root cause analysis. Yes you can always "turn it on and off again" but this is just masking a problem that can come back and bite you hard later.
• Webdam : Web data management book that tries to cover the many facets of distributed data management on the Web. Really great read if you want to have a good overview of the web scale industry and the techniques used.
• Nano Lambda : the rise of the next PaaS stack is coming. I predict we will see more and more startup venturing in the Lambda platform field. However what they really need to work in is offering simple and intuitive tools to orchestrate and scale the system. The "simple" running lambda code will not be sufficient for long enough.

Links of the day 12/01/2016 : #devops for cynics, Probabilistic computing reading list, lambda conf vids

• MIT Probabilistic Computing Reading list : excellent list of probabilistic readings. Beware its really long but if you are interested in this type of technology its a must read to at least keep up to date. 
• Devops for cynics : small ebooks for those out there that takes everything with a grain a salt. 
• LambdaConf 2015 : playlist of all the talk at last year lambda conf

The rise of micro storage services

Current and emergent storage solutions are composed of sophisticated building blocks: dedicated fabric, RAID controller, layered cache, object storage etc. There is the feeling that storage is going against the current evolution of the overall industry where complex services are composed of small, independent processes and services, each organized around individual capabilities.

What surprised me is that most of the storage innovation trends focus on very high level solutions that try to encompass as many features possible in a single package. Presently, insufficient efforts are being made to build storage systems based on small, independent, low-care and indeed low-cost components. In short, nimble, independent modules that can be rearranged to deliver optimal solution based on the needs of the customer, without the requirement to roll out a new storage architecture every time is simply lacking - a "jack of all trade" without,or limited "master of none" drawbacks or put another way modules that extend or mimic what is happening in the container - microservices space.

Ethernet Connected Drives

Despite this, all could change rapidly as an enabler (or precursor, depending how you look at it), of this alternative solution as it is currently emerging and surprisingly, coming from the Hard Drive vendors : Ethernet Connected Drives [slides][Q&A].This type of storage technology is going to enable the next generation of hyperscale cloud storage solution. Therefore, massive scale out potential with better simplicity and maintainability,not to mention lower TCO.

Ethernet Connected Drives are a step in the right direction as they allow a reduction in capital and operating costs by reducing:

• software stack (File System, Volume Manager, RAID system);
•  corresponding server infrastructure; connectivity costs and complexity; 
• granularity which enable greater variable costs by application (e.g. cold storage, archiving, etc.).

Currently, there are two vendors offering this solution : Seagate with Kinetic and HGST with the Open Ethernet Drive. In fact we are already seeing some rather interesting applications of the technology. Seagate released a port of SheepDog project onto its Kinect product [Kinect-sheepdog] there by enabling the delivery of a distributed object storage system for volume and container services that doesn't requires dedication. Indeed there is a proof of concept presented HEPiX of HGST drive running CEPH or Dcache. While these solutions don’t fit all the scenarios, nevertheless, both of these solutions demonstrate the versatility of the technology and its scalability potential (not to mention the cost savings).

What these technologies enables is basically the transformation of the appliances that house masses of HDD into switches thereby eliminating the need for a block or file header as there is now a straight IP connectivity to the drive making these ideal for object based backends.

Emergence of fabric connected Hardware storage:

What we should see over the next couple of years is the emergence of a new form of storage appliance acting as a fabric facilitator for a large amount of compute and network enable storage devices. To a certain extend it would be similar to HP's moonshot except with a far greater density.

Rather than just focusing on Ethernet, it would be easy to see PCI, Intel photonic, Infiniband or more exotic fabrics been used. Obviously Ethernet still remains the preferred solution due to its ubiquity in the datacenter. However, we should not underestimate the need for a rack scale approach which would deliver greater benefit if designed correctly.

While HGST Open Ethernet solution is one good step towards the nimble storage device, the drive enclosure form factor is still quite big and I wouldn't be surprised if we see a couple of start-ups coming out of stealth mode in the next couple of months with fabric (PCIe most likely) connected Flash. This would be an equivalent of the Ethernet connected drive interconnected using a switch + backplane fabric as shown in the crudely designed diagram below.

Is it all about hardware?

No, indeed quite the opposite. That said, there is a greater chance of penetration of new hardware in the storage ecosystem as compared to the server market. This is probably where ARM has a better chance of establishing a beach head within the hyperscale datacenter as the microserver path seems to have failed.

What this implies is that it is often easier to deliver and sell a new hardware or appliance solution in the storage ecosystem than a pure software one. Software solutions tend to take a lot longer to get accepted, but when they pierce through, they quickly take over and replace the hardware solution. Look at the object storage solution such as CEPH or other hyper-converged solution. They are a major threat to the likes of Netapp and EMC.

To get back on the software side as a solution, I would predict that history repeats itself to varying degrees of success or failure. Indeed, like the microserver story we see, hardware micro storage solutions while rising, at the same time we see the emergence of software solutions that will deliver more nimble storage features than before.

In conclusion, I feel that we are going to see the emergence of many options for a massive scale-out, using different variants of the same concept: take the complex storage system and break it down to its bare essential components; expose each single element as its own storage service; and then build the overall offer dynamically from the ground up. Rather than leveraging complexed pooled storage services we would have dynamically deployed storage applications for specific demands composed of a suite of small services, each running in its own process and communicating with lightweight mechanisms.These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a minimum of centralized management relating to these services, which may be written in different programming languages and use different data storage technologies, . which is just the opposite of current offers where there are a lot of monolithic storage applications (or appliances) that are then scaled by replicating across servers.

This type of architecture would enable a true, on-demand dynamic tiered storage solution. To reuse a current buzzword, this would be a “lambda storage architecture”.

But this is better left for another day’s post that would look into such architecture and lifecycle management entities associated with it.

Links of the day 03 - 04 - 2015

Today's links 03/04/2015: NVM trends and loads of conferences - Hepix, CernVm, Lambda Days

• Emerging Non Volatile Memory (NVM) Technology & Market Trends: 2014 Report by Yole Developpement
• HEPiX workshop : lots of very good talk in there.
• CernVM workshop : ecosystem providing all the building blocks for a virtualized analysis environment for High Energy Physics experiments. 
• Lambda 2015 : Functional Programming Conference (26-27 FEBRUARY 2015)

Links of the day : 12 - 09 - 2014

Today's links 12/09/2014 : Lambda Calculus ,  Monitoring, #DeepLearning,  #BigData

• Lambda Calculus : Good intro in Lambda calculus and Functional programming.
• Deep Learning through Examples: Deep learning meetup talk / Screencast with Audio 9/11/14   
• Monit : small Open Source utility for managing and monitoring Unix systems. It conducts automatic maintenance and repair and can execute meaningful causal actions in error situations.
• KDD Retro: Google Knowledge Vault and Topic Modeling : Excellent Summary of KDD 2014 conference
• Also the all tutorials slides of KDD14 are here