October 2016 – NimbleMind

23/10/2016

Let it crash

As functional programming paradigm becomes more and more broadly recognized,interest in functional languages (Scala, F#, Erlang, Elixir, Haskell, Clojure, Mathematica and many other) increases rapidly over last few years, it still remains far from the position that mainstream languages like Java and .NET have. Functional languages are predominantly declarative and based on principles of avoiding changing state and eliminating side effects. Several of these languages and frameworks like Scala/Akka and Erlang/OTP also provide new approach to handling the concurrency avoiding shared state and promoting messaging/events as a mean for communication and coordination between the processes. As a consequence they also provide frameworks based on actors and lightweight processes.

Fail-fast, on the other hand, as an important system design paradigm helps avoiding flawed processing in mission critical systems. Fail-fast makes it easier to find the root cause of the failure, but also requires that the system is built in a fault-tolerant way and is able to automatically recover from the failure.

Fail-fast combined with lightweight processes brings us to “Let it crash” paradigm. “Let it crash” takes fail-fast paradigm even further. The “Let it crash” system is not only build to detect and handle errors and exceptions early but also with an assumption that only the main flow of the processing is the one which really counts and the only one that should be implemented and handled. There is little purpose in programming in a defensive way, i.e. by attempting to identify all possible fault scenarios upfront. As a programmer, you now only need to focus on the most probable scenarios and the most likely exceptional flows. Any other hypothetical flows are not worth to spend time on and should lead to crash and recovery instead. “Let it crash” focuses on the functionality first and this way supports very well modern Lean Development and Agile Development paradigms.

As Joe Armstrong states in his Ph.D. thesis, if you canʼt do what you want to do, die and you should not program defensively, thus program offensively and “Let it crash“ Instead of trying focusing on covering all possible fault scenarios – just “Let it crash“

However, recovery from a fault always takes some time (i.e. seconds or even minutes). Not all kinds of languages and systems are designed to handle this kind of behavior. In particular “Let it crash” is hard to achieve in C++ or Java. The recovery needs to be fast and unnoticed for the processes which are not directly involved in it. This is where functional languages and actor frameworks come into the picture. Languages like Scala/Akka or Erlang/OTP promote actor framework, making it possible to handle many thousands of processes on a single machine as opposed to hundreds of OS processes. Thousands of lightweight processes make it possible to isolate processing related to a single user of the system or a subscriber. It is thus cheaper to let the process crash, it recovers faster as well.

“Let it crash” is also naturally easier to implement in an untyped language (e.g. Erlang). The main reason for this is error handling and how hard it is to redesign the handling of exceptions once it is implemented. Typed languages can be quite constraining when combined with “Let it crash” paradigm. In particular, it is rather hard to change an unchecked exception into checked exception and vice versa once you designed your java class.

Finally “Let it crash” also implies that there exists a sufficient framework for recovery. In particular, Erlang and OTP (Open Telecommunications Platform) provides a concept of supervisor and various recovery scenarios of the recovery of whole process trees. This kind of framework makes implementing the “Let it crash” much simpler by providing a foolproof, out of the box recovery scheme for your system.

There are also other benefits of “Let it crash” approach. As there are now each end-user of your system, and each subscriber is represented as a single process, you can easily take into use advanced models like e.g. finite state machines. Even though not specific to Erlang or Scala, the finite state machines are quite useful to understand what has lead to the failure once your system fails. Finite state machines combined with a “Let it crash” frameworks can potentially be very efficient in for fault analysis and fault correction.

Although very powerful and sophisticated, “Let it crash” did unfortunately not yet gain much attention besides when combined with Scala/Akka and Erlang/OTP. The reasons are many, on one side (as explained above) the very specific and tough requirements on the programming languages and platforms but also the very fact that only the mission-critical systems really require this level of fault tolerance. In the case of classic, less critical business systems, the fault tolerance requirements are not significant enough to justify the use of a niche technology like Erlang or Scala/Akka.

“Perfect is the enemy of good” and mainstream languages like Java or .NET win the game again, even though they are inferior when it comes to fault-tolerance and supporting “Let it crash” approach.

This work excluding photos is licensed under a Creative Commons Attribution 4.0 International License.

16/10/201603/02/2020

A successful dumb pipe strategy – learning from Iliad

Faced with the inevitable dumb pipe fate and commoditization of the telco business the last couple of years, several large telco operators started pursuing vertical and horizontal integration strategies. Horizontal, by expanding into other markets or consolidating. Vertical, by expanding either into downstream side of their value chain or into other verticals, in this way reinventing their business.
On the other hand, many newcomers often don’t fear becoming a dumb pipe as much and take slightly different pathway by optimizing their cost base, challenging established operators and this way fighting for their market shares.

France’s Iliad with their Free/Alice brands is currently the 2nd largest broadband operator and 3rd mobile operator in France challenging the old incumbent operator Orange (France Telecom). Both Iliad and Orange provide a wide range of bundled services to their customers (Triple/Quadruple Play) ranging from FTTH, VDSL, ADSL, landline and mobile telephony to TV. The other two major competitors like SFR and Bouygues also use similar bundling strategy to provide full Quadruple Play spectrum of services resulting in a lower total cost to their customers as well as increased ARPU for the operator.

Iliad’s network investment strategy has been initially focused on broadband Internet access services (ADSL and later FTTH) and their main revenues originate from Fiber/ADSL. Iliad however also provides other services primarily TV, VoD most of it bundled and free of additional charge to the subscribers. In 2012 strengthen Iliad further their market share by acquiring from a small ADSL operator from Telecom Italia – Alice and this year trying to acquire assets from CK Hutchinson and VimpelCom to become Italy’s fourth mobile operator.

The strategy that gave Iliad foothold in the telecommunication market was originally to use unbundled ADSL access from incumbent France Telecom. By doing that Iliad could achieve much higher margins than their competitors like Alice who did not have the same focus on unbundled ADSL and used much more expensive not unbundled ADSL access.

High prices and high margins on ADSL made it possible for Iliad to provide their bundled VoIP service practically for free (free local, long distance) as well as to provide hundreds free TV over ADSL channels. The only services that Iliad charged customers for in addition to ADSL were basically certain international calls, paid channels, VoD over ADSL as well as subscription VoD. Consecutively with their low cost structure Iliad was able to provide the most affordable basic ADSL-VoIP-TV bundle on the French market without compromising the performance of their ADSL. This combined with their comprehensive offer on the content side was basically what made Iliad so successful in tough French telco market.

Further when looking at Iliad’s fiber investments, by using sewers Iliad managed to bring the cost of fiber in Paris to a much lower level even comparable with ADSL. Iliad’s investment in FTTH is important for the future both to overcome the limitations of VDSL/ADSL as well as due to that the competitors have FTTH and FTTN/VDSL in their product portfolios. By doing FTTH investments at much lower cost than the competition and reusing the sewers Iliad gained a competitive advantage which neither Orange, SFR or Bouygues had. This is in a way an extension of their ADSL strategy where they also concentrated primarily on bringing the ADSL costs down and not just on achieving the economies of scope. Iliad has further used a similar strategy for expanding into the mobile market.

Summing up, by doing large infrastructure investments at lower costs than competition Iliad hopes to beat the competition on price/performance and gain larger market share. Lower cost and higher margins compared to the competition make it possible for them to bundle some basic VoIP and TV services at no additional charge. Iliad’s hope is that by doing this they can earn money later on advanced services.

Although very successful so far – Iliad’s low cost/dumb pipe strategy has also some weaknesses, e.g. lack of control over the content that might lead to their strategy falling apart in face of a strongly vertically integrated competitor. Without creating a compelling value proposition for the subscribers e.g. in form of an ecosystem and getting more control over the content Iliad is bound in long run to compete basically on price. The strategy of bundling more and more services at a lower price than the competition is a way of staying one step ahead of the competition. However it may not be sufficient without having more control over the content. On the other hand, there is a hope, since new technologies like IoT are expected to provide some new growth opportunities also for dumb pipe operators.

This work excluding photos is licensed under a Creative Commons Attribution 4.0 International License.

06/10/2016

Big Data in the cloud – avoiding cloud lock-in

In our previous article we looked at different approaches to introducing Big Data technology in your business – either as a generic or specific solution deployed on premise or in cloud. Cloud gives obviously very good flexibility when it comes to experimenting in early stages when you need quick iterations of trying and failing before you find the use case and solution, which fits your business needs best.

Cloud lock in

However in your try and fail iterations you will need to focus to not to fall in another pitfall – the cloud vendor lock-in or simply cloud lock-in. By cloud lock-in we mean using vendor specific implementations, which only a particular cloud supplier provides. A good example here could be Amazon Kinesis or Google Big Query. Using this specialized functionality may seem to be a quick way of implementing and delivering your business value however if your cloud provider chooses to phase out support for that functionality your business may be forced to reimplement parts or whole of the system that depends on it. A good strategy against lock-in is particularly important for established businesses although while for startups with relatively thin software stack this isn’t such a big deal since the switching costs are usually stil low.

Open source to the rescue

Open source software has a great track of providing a good solutions to reduce vendor lock-in. It has helped fighting vendor lock-in for decades. In particular within operating systems Linux has played an important role in fighting the vendor locking. Taking this into the Big Data world it does not take long time to understand that automation and in particular open source automation tools play important role in avoiding cloud lock-in. This could for instance be achieved by deploying and running the same complete Big Data stack on-premise and in the cloud.

Using automation tools, like Chef, Puppet, Ansible Tower is one of the strategies to avoid vendor locking and quickly move between the cloud providers. Also container technologies like Docker or OpenShift Containers make it possible to deploy the same Big Data stack, either it is Hortonworks, Coouder or MapR across different cloud providers, making it easier to swap or even use multiple cloud setups in parallel to diversify the operation risks.

What about Open Source lock-in?

Listening to Paul Cormier at RedHat Forum 2016 (Oslo) last week one quickly could get an impression that the cloud lock-in can simply be avoided by promoting Open Source tools like Ansible Tower or OpenShift Containers. These solutions effectively help turning the IaaS and PaaS resources offered by the Big Three (Amazon, Google and Microsoft) as well as other cloud providers into a commodity. On the other hand critics of Open Source could say that by using this kind of solution you actually get into another kind of lock-in. However the immense success of Open Source software over last 15 years shows that lock-in in case of an Open Source system is at most hypothetical. It is easy to find a similar alternative or in absolutely worst case scenario to maintain the software yourself. Open Source by its very nature of being open brings down any barriers for competitive advantage and the new ideas and features can easily be copied by anyone, anywhere and almost at no time.

This work excluding photos is licensed under a Creative Commons Attribution 4.0 International License.