Grow your own moustache!

It is done! I finished my Master study. The defence was held on April 26 and the thesis got published today. For those inclined in reading this kind of literature, here is my thesis: A Scalable Heterogeneous Software Architecture for the Telecommunication Cloud. It is an actor model based framework which can deploy on any cloud and be written with any programming language.

Let me tell you it is a big weight removed from my shoulders. In retrospective I would do it again. However I would not take two courses in the same session. Also I would have started the writing of the thesis and verified it with my thesis director earlier. But now it is done. On the bright side, I think what I have learned in the process really helped improve the end result the research done by my team.

I could not resist long and had to learn something new. Something has been on my back list for a while and I decided to give it a try. But let me put a little bit of context here. Four or five years ago I went to course about innovation in Stockholm. One of the exercises went as follow. In teams of two we had to point randomly in magazines and pick pictures and sentences, and give sense to them. I don’t recall each individual element, but I think we came up with a sentence going like this: “You have to grow your own moustache”. I still recall that sentence because out of the randomness of the sentences and images we picked we ended up with such a profound revelation!

It might not look like it, but “Growing your own moustache” is a really good metaphor for a lot of things in life. I will just show one of those things. As following a course and learning is, growing a moustache is a decision you have to make. Once that decision is made, it will take time, you cannot have it grown over night. Two people won’t grow the same moustache and it won’t grow at the same pace. When you learn, you might struggle more than someone else, but in the end, no matter the struggling, what you have learned is personal, what you retain depends on your background and how the moustache grew… everyone will get its own, there is things you can do to shape it the way you want, but some things you cannot control or change.

That being said, this exercise and many more went a great deal to start a friendship. The course I am following now is from an advice from that friend, Andreas S. who told me about it. So Andreas told me about that book which guide you through the process of building a computer. You start from Nand gates and build a computer from them, an OS, a language and eventually the Tetris game. It happens that the guys who wrote the book made available that course on Coursera: Build a Modern Computer from First Principles: From Nand to Tetris. It is a two parts course and the first part is available now. I finished the first part. Last week I completed the assignment for week five where you have to build a CPU and Memory and assemble them as a computer. This week I completed the 6th week assignment to write an assembler for that computer. It is all simulation, but you know it could work for real if you had the patience to build it physically as in the previous weeks we built every elements leading to this, from the Nand gate. Two transistors and a resistor and you have a physical implementation of a Nand gate. You would need a s**t load of them to build an actual physical version of it, but you get the full understanding with the course. By the way, someone did such a computer from individual transistors. You can get a view of it in this video.

When I did my bachelor degree (in electrical engineering) 25 years ago, I covered a lot of what is shown in this course. But still some pieces were missing. We built/simulated logical gates and from there went to Register and ALU but we didn’t assemble them as a CPU and a Computer. Other course showed us assembly and compilers but it was not linked in a coherent chain. That course bring you from the basic Nand gate up to writing a Tetris game will all the steps in between. You can be a perfectly good software engineer without knowing how a computer is built, but there is a lot you can gain by understanding it. Making it yourself ensures you have a deep understanding of the whole process. I recommend that course to everyone. Thanks Andreas!

Advertisements

Cloud-based Telecom Software Architecture

It has been two years since I started this journey of defining a Software Architecture for the Telecom domain in the Cloud. There are challenges in providing a Telecom platform in the Cloud you will not generally find in the IT world. Two years ago my team was tasked to look in the future and see to what extent the Cloud Programming Principles could be applied to the telecom world. We started from a white sheet and look at the potential building a small proof of concept prototype. Last year Ericsson unveiled its Software Model. You can find a video on YouTube on the Ericsson Software Model. You can also read the Ericsson Software Model press release. We looked at how our approach was supporting that model as well as taking it as a form of requirement specifications as what a Telecom Cloud platform should provide.

The Ericsson Software Model promotes a number of concepts which we looked at while developing our cloud-based software architecture:

Virtualization: The Ericsson press release states that “network evolution is increasingly driven through new software functionality with application virtualization”. With our research we wanted to go further and look at it from the angle of an application natively built for the cloud not solely virtualized. Thus the software architecture we propose is built for the cloud. Since from the point of view of a telecom vendor, telecom application should be deliverable on any operator owned cloud platform or mix of platforms it became obvious that the need to provide an hyper-heterogeneous cloud architecture enabling software to be deployed independently of the platform without having to rework it was a must.

Upgrades: The Ericsson press release also mentions the importance of easy regular upgrades. Building our research approach as a cloud platform we looked how far we could go with this. We came up with principles that allow upgrade of network software for a single subscriber, or even for a single service instance of a subscriber. Thus we could upgrade a network in a staged fashion while keeping an eye on key performance indications and instantaneously go back to a previous version if anything goes wrong. The high granularity of our upgrade approach means fewer risks while upgrading which enables more regular upgrades.

Better Resource Utilisation: The Ericsson Software Model video states better resource utilisation as a driver for the future. Virtualization helps in that matter, however since the scalability increments would still be in the thousands of subscribers at a time, it limits how small a network function can become. In the context of the Networked Society where billions of devices are connected, it becomes obvious that the usage patterns will be multiple and non-obviously predictable. Our highly granular approach allows for efficient resource utilisation since only the software processes are instantiated on a need basis anywhere in the cloud of available resources. Hence free resource can be used for any service scenario and are never tied to a specific one.

Performance: The Ericsson press release states that the Ericsson Software Model “builds on the software performance benefits by making it simpler and faster for operators”. Since our research approach is based on a cloud deployment it became obvious we needed to address availability. As such we build in our architecture ways to allow the application to cope with availability issues, being able to be deployed or migrated anywhere in the cloud if servers crash or becomes unavailable. These facilities are built to be transparent to the application thus making it simpler to the application developer and consequently to the operator as well.

Predictability: The Ericsson Software Model video states the need for predictability. Our approach also allows for a high degree of observability which is important to provide a predictable network and eventually to have a self-healing system.

First to Market: The Ericsson Software Model video states the need for operators to quickly have new functionality available to the customers. For this to be possible we need to look at the development cycle from the start and developers needs build their software based on software independency concepts if they are to deliver it as quick as possible. The software independency is built-in our approach and we think this is a necessity if a platform is to allow rapid development.

There would be much more to say as some more principles made it in the architecture, but if you think those are important principles I invite you to read the two papers we submitted to the S2CT.org conference and should shortly be published. We defined software architecture and build a proof of concept which address those business needs and could become a software platform for the future telecom products. The papers describe at a high level view of the architecture as well as some results from the proof-of-concept.

Preliminary versions of the papers are available on arXiv.org: Hyper Heterogeneous Cloud-based IMS Software Architecture: A Proof-of-Concept and Empirical Analysis and Micro Service Cloud Computing Pattern for Next Generation Networks.