Part 6 of 8:The next level of cloud is stateful-design VS stateless-design
I imagine the present-day physical networks operated by today’s telcos are comforting in their known-ness (even during those times when physical networks are frustrating in their limitations, anyone who has gone through a messy migration has reason to say, let’s just stick it out with the old stuff a little bit further, I get it).
In their sixth VNF ebook “Go Cloud Native”, Ericsson says, very gently, Dear Customer, while we understand that you’d like your new virtual network functions (VNF) to be backwards compatible with your existing physical network, it’s just not gonna happen. And then they go into the here’s-why.
The biggest reason why of course is that they are completely different environments. The whole notion of optimising existing physical network applications to run on cloud is just not a thing. Not possible.
The other reasons have a lot to do with skill-set and methodology – the who you have on your developer team, and how they work, and of course what they do is very, very different. Maintaining the old infrastructure while you develop the new are two distinct, parallel enterprises. Yes, that’s expensive. ( check out part 5 in this series for more on this topic )
Cloud-native development is pretty well established by now, but the specific requirements designed to meet telco nine nines reliability do raise the stakes a bit. Ericsson’s general design principles are worth reading – the ebook lists them all out – and you’ll note a lot of emphasis on modularity. By assembling applications from individual, highly-modular micro-services, Ericsson creates some serious efficiencies.
Let us not forget, this is a high-stakes, one-direction, resource-intensive endeavour where winning is essential. But modularity is also really cool, because it involves a lot of pattern analysis – where are the simpatico elements between nodes, and how can those similarities be leveraged?
The next level of cloud is stateful- vs stateless-design. To loosely paraphrase Ericsson, a stateless VNF is purely transaction oriented, requests are immediately replied to, no internal state engine required.
A stateful VNF allows the system to utilise information from prior interactions and creates replicated secondary environments as backups. Most VNFs will operate both, though state-optimised design is going to do more of the heavy lifting when delivering real-time performance.
It’s helpful that the ebook puts classic aspects of cloud infrastructure into telco context, from distributed infrastructure to continuously evolving software and test/fail/recover.
In particular, read-in to the reminders on what makes a DevOps environment succeed. You’ll need the speed it delivers, but you have to purpose-build the team in order to get true continuous delivery (raise your hand if you’ve ever been to a completely pointless stand-up…) and you absolutely have to adopt automated testing.
I’m sure you like me want to see 5G deployed to a mobile antenna tower near us tomorrow-ish, so please jump in and join the conversation I’m doing my best to lead, post your thoughts and feedback in comments, follow me on Twitter and join the conversation there, wherever you are connected with me – join in and have your say.
As I mentioned earlier, there’s a complete series of eight ebooks from Ericsson, which break the transition down step-by-step. I recommend you grab all eight of them and consume them at your own pace, in bite-sized chunks to avoid choking – this is a long-term strategic play, you’ll need your strength. Grab your copy of all eight free NFV eBooks from Ericsson here => ericsson.com/nfv
That’s it for part six in this eight-part series, thanks for reading, and I’ll see you in part seven.