Why PaaS may not be a right choice for products?

Why PaaS may not be a right choice for products?

Platform as a Service (PaaS) definitely provides great benefits when it comes to rapid development and deployment capabilities. However, from an (product) architect’s point of view PaaS is more of a blackbox that can be used (only) in the prescribed way.

But if you want to make any changes to the way PaaS works then that’s something you will not be able to do. Let’s take some scenarios.

you want to include a particular third party UI control in your page to offer better usability.

you want to have control on the db design and the data architecture

you want to design the layers of your architecture

you want to use a different security framework (than the one provided by your PaaS provider)

you want to switch to a different cloud provider for economic reasons

you want to deploy your product as on-premise for large customers

Some PaaS providers support some of the above scenarios, but it’s very difficult to find a PaaS vendor who can support all of the above. Remember, the above list is a very short list of numerous controls/changes that an architect would like to do while designing/maintaining a product.

Products need a great level of flexibility and control when it comes to technical decisions. We have encountered several customers who have initially chosen the path of PaaS and at a later stage they realized their hands are tied from accomplishing some of the above mentioned scenarios. In some extreme cases customers had no choice other than to scrap the entire (PaaS) project and start it from ground up development – so that they get to make their own technical decisions. However, developing everything from scratch is going to take a significant amount of cost, time and effort.

Please click here to calculate the approximate effort required for building the basic building blocks.

While PaaS comes along with deployment management capabilities, it cannot be at the cost of the limitations enforced on the technical and business aspects of the product.

Cello is designed with the goal of making it an “Accelerator” and not a “Dictator”. Cello framework provides complete control and flexibility to the product architect to handle all the above mentioned scenarios. Click here to take a quick tour of CelloSaaS.

Let’s see how Cello handles the above mentioned scenarios.

Cello allows your product pages to be developed in any UI technology including usage of third party controls. Moreover, Cello pages, which comes out of the box, is also completely available for the developers to modify in order to suit their product look and feel.

Cello allows your product to consume any database including No SQL and in-memory databases. This way you will have complete control on the database design and administration capabilities.

Cello comes with a default multi-layer multi-tenant architecture. Architects have a choice of extending Cello’s architecture and build the product functionality. Alternatively, they can skip Cello’s architecture and design a new architecture for their product.

All the modules of Cello are designed to work in a plug & play model. This allows the architects to decide which modules they would like to use from cello and to what extent they would like to use it. For example, if a different workflow engine has to be used (other than the one provided by Cello) then it’s completely possible to integrate any third party software without any restrictions.

Cello is a cloud neutral solution. Therefore you can deploy/move your solution to any cloud provider and at any point in time. Cello does not have any other dependency and the only pre-requisite is Microsoft technology stack.

Since Cello libraries and APIs can be deployed in any .NET environment, it’s possible to deploy your solution as on-premise model. There are no restrictions from cello towards deploying it in a non-cloud environment.

As you can see, Cello brings in – both technical and business wise for ISVs. If you want to speed up your SaaS development and also want to retain the flexibility and control (for technical decision making) then Cello is definitely a better option compared to PaaS.

Following is the feedback from Gartner on Cello,

“The Techcello approach is likely to be ideal for companies -especially independent software vendors – that need to get to market relatively quickly with a multitenant SaaS solution and would like a substantial shortcut while avoiding lock-in to a proprietary application platform as a service (aPaaS)”

Janaki serves as the Director of Technology at Techcello. Janaki has more than 15+ years of software development experience. He is responsible for product engineering, support and evangelization of Techcello. Prior to Techcello, Janaki worked with Aspire Systems as Delivery Manager and Practice Manager focused on Microsoft Technologies and SaaS/On-Demand product development. He has worked with several ISVs and enterprises in building multi-tenant, cloud enabled products. He has travelled widely across the US and UK for working with various customers.
Janaki is an ardent cloud enthusiast and a prolific speaker at various cloud conferences including Interop, SaaS University, Cloud Connect and Euro Cloud.