The Hitchhiker’s Guide to Telco Transformation - Part 3
A PaaS is a PaaS is a PaaS. Or is it?
So in the previous blogs in this series, we talked a little bit about how the transformation was taking quite some time in the industry, and the differences between the different as a Service solutions: SaaS, IaaS and PaaS. We also discussed some of the benefits of these different platforms, and how they are helping us along the path to transformation.
In this blog, I would like to delve further into the different PaaS products out there in the market. As many of you know, today it seems that every vendor is offering their own PaaS. Your first question might be, and rightly so, do you need to choose? And a second question might be ‘how should you go about doing so’?
For most of us vendors, transitioning our hardware to the new world of software requires a ‘transformer’ of sorts. We’ve found this transformer in the form of a PaaS. As I mentioned before, the PaaS provides more than just the storage and server infrastructure – it also provides a list of development tools upon which our software can easily run. And like in many other situations, we vendors feel most comfortable with our own software and equipment. What does that mean for you? Well it means that each of us, who want to play in the future software arena, have developed our own PaaS.
Why you may ask, because for each vendor it is easiest to be able to test in our own environment our own applications. In our own PaaS we can connect our own hardware to our own software and ensure that the application we are providing works as it should. We can easily manage the life cycle of these applications and provide the authentication tools which are needed. However, as the industry moves to multi-vendor networks I predict that like in many cases, a few of the best or most popular PaaS will prevail and the rest will need to ensure their applications are properly integrated.
So for now you don’t really need to choose a PaaS, you can use the PaaS provided by your network vendor. This, however will change in the future and you will need to ensure that the equipment and applications you want to use are indeed supported by the PaaS you work with. Cool you say? Well yes and no.
Cool because you don’t need to make a decision right now. And that is a good thing, because not all PaaS’ are created equal. Not so cool, because your time and resources are already thin, so trying out new ways of working wears out very quickly.
So how do these PaaS differ, one from the other? Well there’s a list of criteria that you might want to keep in mind when discussing PaaS with your vendors:
- Scale – one of the benefits of moving to a software environment is the agility of spinning virtual resources up or down, based on your use. Scale, and how much traffic your NFV can handle is an important aspect of the decision making process. That said, most PaaS should let you simply and easily scale up or down, per your needs.
- Framework Support – which languages, frameworks or tools are supported? Whether it is the ability to support specific languages (such as PhP or Python), or different DB tools (such as MySQL or MongoDB) make sure the PaaS of choice supports the tools and frameworks you work with.
- Openness – yes you’ve heard this word before from the industry. And here again the ability of the PaaS to simply and easily integrate south bound interfaces and APIs such as NetConf and Yang is pertinent to its ability to integrate and control various appliances and equipment.
- Multi-Vendor Support – while the previous criteria talks about incorporating equipment with open APIs and interfaces, a good PaaS will also support multi-vendor applications, VNFs and hardware. To enjoy the freedom of truly virtual networks, you must ensure that your PaaS provides full multi-vendor support.
- App Type Support – Does it support Stateful apps and/or stateless apps? While most service provider apps are Stateful (or monolithic) this will no doubt change in the future. This topic is so wide I will be devoting more time to discussing it in future blogs.
And the list goes on. But while the majority of the above criteria are a simple list or can be described in a 0, 1, or across a scale, the one aspect which makes all PaaS different from one another is the following:
- Operations Tools – Operations tools are those tools that are built to make your job easier. Yes the experience with using the PaaS (as opposed to previously configuring hardware via a set of CLIs) is what sets all the different PaaS apart. A good PaaS will provide an intuitive user interface which will allow you simply and easily set up new services in a matter of minutes by taking you though a wizard of sorts. The wizard will make sure to ask you a short, but comprehensive, list of questions which will ensure that the PaaS has all the information it needs to manage the application life cycle. When to spin up/spin down functions, questions of scale and authentication and security. All these need to be incorporated in the set up process – which for you should be ask easy a click of a button.
- The operations tools should include:
- App designer – an interactive GUI which will enable you to visualize a new service, function or app.
- TOSCA Support - Topology and Orchestration Specification for Cloud Applications (TOSCA) is a standard that can be used to enable the portability of cloud applications and related IT services for telecom operators. TOSCA is a data model that can be used by carriers for creating templates or data descriptions of applications and infrastructure for cloud services. It can also be used to define the relationships among these services, as well as their operational behavior.
Lifecycle manager – which automatically knows how to act in different situations across the application life cycle. For example, restoration paths and scale configurations.
For me at least, the operations tools are able to not only define how easy the PaaS is to work with, but is in fact the ‘Holy Grail’ in PaaS differentiation. A good PaaS is supposed to make your life simpler, so make sure you try it out. Don’t just take a vendor’s word for it.