Wednesday, April 17, 2013

Why PaaS Is The Future

In this article of the same name, Joe Masters he writes about his reasons for seeing PaaS as the future of most if not all web applications.  I will repost here with my Ollie>> comments injected.

-----------------------------------------------------------------------------------------

Platform-as-a-service will become standard for Web applications. It's time to evaluate your options and plan a migration strategy.

The vast majority of Web applications will eventually run on platform-as-a-service, or PaaS. The shift will be slower than to infrastructure-as-a-service (IaaS) because finding the perfect PaaS fit will take effort, and there's significant loss of control over hardware and software. Many IT departments will resist. But it will happen, so to help you evaluate options and plan a migration strategy, we sent out a questionaire with more than 70 factors to consider to major PaaS providers. You can download a full set of responses at ourInformationWeek PaaS comparison site.
The PaaS value proposition is simple: Bring your code, and we'll handle everything else for you -- Internet connectivity, power, hardware, operating system, software, monitoring, backup, restore, failover, scaling and more. IT can focus on writing code to solve business problems and leave the mechanics of infrastructure and operations to the vendor. In theory, you get a best-practices deployment, including security and business continuity, at a lower cost and better quality versus having your own staff do the work.
We say, "in theory" because these are still early days, and vendors provide so many different services -- with so many moving parts -- that it will take time to demonstrate stability to CIOs. However, we're convinced that PaaS is the future, and that companies that fail to consider it will be at a disadvantage.
Ollie>> We agree, at O4BO.COM we have assembled a single subscription offering that includes PaaS (Rapid Application Development, Infrastructure as a Service, Service Oriented Architecture, Context Aware Rules Engine, Enterprise Service Bus (combined to create an Integration Platform aka iPaaS, along with a suite of Open Source Software as a Service Applications.

The 7 Factors To Consider
A PaaS implementation requires two main elements: a platform and a service that runs the platform for you. For a PaaS vendor to be included in our comparison, it must both sell software or software-as-a-service for deploying Web applications and provide an infrastructure on which to run these applications. After all, if a vendor doesn't provide the underlying infrastructure in addition to the platform software, you're not getting the full value of PaaS because you lack "one throat to choke."Ollie>> We agree and we add iPaaS for even better value.
Report Cover
The full report accompanying ourPaaS comparison is free with registration. This report includes15 pages of action-oriented analysis, plus a link to our vendor matrix.

What you'll find:
  • Analysis and pros and cons of the three types of PaaS
  • Trade-offs for early adopters, and why caveat emptor applies
Get This And All Our Reports
Comparing PaaS vendors is more difficult than comparing IaaS or SaaS vendors because there are so many disparate elements. We discuss evaluation strategies in depth in our full report. Here, we'll walk through the seven major elements to evaluate when choosing a PaaS provider.
>> Programming languages and frameworks: IT generally has a preferred programming language, and providers that don't support that language are rarely in the running. There is one exception: proprietary PaaS, where the customer is buying based on other factors and is willing to use whatever language is required. The best example is Salesforce.com's Force.com, which uses a proprietary language but offers the upside of a robust ecosystem that can give application developers a big head start compared with conventional application development platforms.Ollie>> Observing this we offer options and will expand those options so you are NOT locked in to any proprietary elements.
>> Databases: Generally, PaaS database server support is similar to programming language support -- buyers come to the table with a preference. However, most modern application development is done in such a way as to ease migration to a different database server. Several PaaS providers also support so-called "next-generation" databases, such as Xeround, that provide an interface identical to a widely used database, like MySQL, but are offered as a service. It's important to verify the database security features offered by PaaS vendors to ensure that they conform to your regulatory and security policy requirements.Ollie>> As part of our Infrastructure as a Service on the IBM SmartCloud, we have images for all the major databases and have minimized the effort needed to choose.
>> Availability: After narrowing your list based on programming language and database support, the next defining criterion should be how comfortable you are ceding control over application uptime. To that end, we asked a number of questions around availability to understand what happens when servers and software fail. The service-level agreement is important, but SLAs almost never adequately reimburse a company for application downtime. The best IT can hope for from an SLA is that it costs the vendor enough revenue that the vendor shares some of your pain, and that it clearly defines vendor roles and responsibilities about the services it's responsible for.Ollie>> We agree and which was a key factor in our choice of IBM SmartCoud.
>> Security: Security and regulatory compliance are critical when selecting any infrastructure vendor, and PaaS is no different. Keep in mind that, for the majority of providers, multitenancy is a way of life -- PaaS vendors drive down costs and maintain high availability by spreading applications and data across a large number of shared servers. This makes PaaS most appropriate for applications and information that fall outside of regulatory oversight, although many vendors have ways to address common regulated scenarios such as storing credit cards.Ollie>> We agree and we have chosen Corent Multi Tenant Server for our true multi tenancy and offer the choice of storage model between shared everything  separate schemas and even separate encrypted databases.
3 PaaS Models
>> Services: Many PaaS vendors provide extra services through third-party add-ons. Examples include code repository integration (to launch applications from source code repository branches), caching services (to save database query results to speed application performance), logging services (to consolidate logs across all application copies) and payment services (to outsource acceptance, processing and storage of credit card numbers in a PCI-compliant environment). If an add-on is important, ask how the PaaS vendor handles support. No one wants to navigate interactions between the PaaS provider and services vendor.Ollie>> which is why we added iPaaS to facilitate integration not only between our own applications in the PaaS but our SaaS applications and extrnal customer applications or other SaaS application services like SalesForce.com
>> Customer care: PaaS vendors build layers between and around various services (such as application-to-database transactions) that necessitate a much closer relationship between developer and vendor than with other hosting options. Verify that availability is as claimed. Do experts respond to questions on forums in a timely fashion? Do the people staffing the phones have both a clue and the power to help?Ollie>> we have built a strong partner channel to provide a 7x24 coverage from the Ukraine, to the US to Australia and China and of course Hong Kong and the Philippines where we are located
>> Price: While cost is always important, select based on the above criteria and whether the PaaS model is more cost effective than other options such as in-house or IaaS. Include migration in your calculation if you already have an existing deployment. There's rarely much difference in price among comparable PaaS services. Get the best fit for language, database and add-on support, as well as security and availability.  Ollie>> our SaaS is open source and we pass that savings along to our subscribers and offer bundles that further reduce costs.
Also note that it's difficult to look at a PaaS price menu and translate that into your actual costs. If you have highly optimized application code, you might pay significantly less than someone with inefficient code. Similarly, the way your app runs on one provider may require that you purchase more units of service than on another, with no way to know before deploying the application. Fortunately, most PaaS vendors offer free trials. Take them up on it. Finally, ensure that you can port your application to a different provider in the event of price increases or service outages.Ollie>> Another thing we can do for ISVs is to take your single tenant licensed and installed software and convert it to true Multi-Tenancy, and then integrate it with iPaaS to offer an even richer solution to your customers at a small fraction of the cost of doing it yourself.
Ollie>> We would add one more factor.  While most PaaS vendors do NOT offer portability, we do.  We based our entire stack on Open Source and Portability, with only our Context Aware Rules Engine as our proprietary IP, everything else is portable and if you so choose we can deploy that stack on your own Cloud image so you can leave at any time if you so choose...the ultimate in portability.

Tuesday, April 16, 2013

How SaaS app portability planning can ease pricing, stability woes

From Tom Nolle who wrote this Article of the same name on Tech Target, it so perfectly matched our philosophy at O4BO I just had to acknowledge him with my own repost with my own O4BO related content as follows.  Ollie>> are my inserted comments.  I did not know Tom before I read his article and I contacted Tom about reposting his article in my blog and he was not aware of O4BO before he wrote the article and I contacted him.

---------------------------------------------------------------------

Application portability is always an issue in the cloud because competitive market changes can either create a new "best choice" or put a provider out of business. Most users accept that Infrastructure as a Service applications are fairly portable, and most realize thatPlatform as a Service application portability will depend on application features used.Software as a Service services are not typically considered in the portability discussion, because SaaS applications are owned by the provider and are not portable. In a strict sense, that is true, but portability planning can help users deal with pricing and business stability issues for SaaS providers, and can even help users migrate from a SaaS service back to a self-hosted version of the same application.
Ollie>> Completely agree and part of our original concept.
Tom NolleTom Nolle

Third-party application and SaaS benefits

A Software as a Service (SaaS) app that is based on a provider's own custom software cannot be ported unless the provider creates the option, which will virtually never be the case. Thus, where portability is a concern, a SaaS prospect should first focus on providers who host third-party software rather than those who develop their own. The software developers likely make hosting arrangements with multiple providers, so portability of this form of SaaS is relatively easy. It's also possible to buy a copy of the software for local installation, so "self-hosting" is an option in cases of provider failure or the loss of software support.
Ollie>> Also completely agree, and why we chose Open Source solutions for ERP, CRM, Web Content Management, Portal, ESB and more.  These solutions, being open source are COMPLETELY portable mitigating the risk for our subscribers.
The best sources for "portable SaaS" are the major providers (Microsoft, SAP, Oracle, etc.) of applications. Nearly all will offer SaaS, sign agreements with third parties for SaaS hosting or both. The key point is that wherever a SaaS service is built by hosting conventional application software, it's a good bet there will be multiple providers available offering the most popular options. Specialty vendors who offer vertical-market packages are less likely to attract multiple SaaS hosting providers, so a different approach will be needed for those.
Ollie>> Yes, and we also offer a full PaaS with Integration as a Service and Bring Your Own License such that any of these you may also want to integrated onto the O4BO platform can be done without worry. 

Pros, cons of IaaS instead of SaaS

The second option for SaaS portability is "self SaaS," the licensing of a software package and hosting of the package on a cloud Infrastructure as a Service (IaaS) offering to create what appears to be SaaS. The value of this approach is that the resulting service is as portable as a machine image, which can increase competitive choices for hosting. The negative side is that unlike SaaS, self SaaS still exposes the user to the cost of the software and the support of the entire software stack from operating system to application. This means self SaaS is an option for creating a cloud version of a given application, but not for reaping the full benefits of SaaS.
Ollie>>Also completely agree, which is why we chose to host on the IBM SmartCloud Enterprise, where we retain the option for our subscribers to have their own images as needed and still retain portability and out Integration as a Service and Platform as a Service features. 

DIY SaaS portability

Even these two options won't fully address SaaS portability issues. A growing number of users are integrating SaaS apps with other on-premises or cloud software to create orchestrated multi-component applications. One company combined Salesforce CRMservices with SaaS-hosted unified communications and collaboration to create a sales support application, for example. Here we have two SaaS components, and if either has to be changed, the whole sales support application is compromised.
Ollie>>Right on Tom!  When you consider that O4BO is designed to service the SMB with little or no IT staff, we do all the heavy lifting for you and offer a Rapid Application Development PaaS, along with Infrastructure as a Service and Integration as a Service that includes a Context Aware Rules Engine and an Enterprise Service Bus for just about any customization needed and often without low level coding. 
Portability planning … can even help users migrate from a SaaS service back to a self-hosted version of the same application.
One solution to this problem is proper selection of the application integration tool(s) used to build the higher-level application from its SaaS components. Many application front-end tools (Citrix, for example) allow users to customize the interfaces to the lower-level applications that provide data and processing. Changing a SaaS provider for one component means changing the integration definitions, but not the entire application. For this approach it's important to look for SaaS services that offer flexible application programming interfaces (APIs) that can be integrated easily. RESTful APIsare typically more easily integrated than service-oriented architecture/Simple Object Access Protocol APIs, for example.
Ollie>>Again right on Tom!  When we integrate an application, we take the Event API for that application, wrap it in a Service Layer and integrate that API with our Context Aware Rules Engine that has Event Handlers for the ESB as well as Drools, jBPM and industry standards based Event Handlers including SOAP/REST and more. 
When all else fails, SaaS integration and portability problems can be solved by customizing an application based on the SaaS APIs. A SaaS API appears to a developer like a distributed application component, and so it can be built into a program as such. To prevent this process from simply creating another portability risk, the best practice is to encapsulate access to all SaaS service APIs in a local class/object, and refer to that new object to access the service. That way, if it's necessary to change SaaS providers at some point, the local object can be modified to suit the API of the new provider.
Ollie>> Not only do we use a SOA component approach for our existing integrations but for any new integrations including external SaaS solutions like SF.com, NetSuite, Azure Apps, Google Apps, etc. 

SaaS vendors fostering portability?

All integration and encapsulation strategies for SaaS portability depend on there being functional correspondence among the competing SaaS providers of a given application. Obviously, if one provider of a unified communications/collaboration service offers video sessions and the other does not, no amount of interface integration will make up for the lack of functionality. Not all functional differences are that obvious, though, so before undertaking a SaaS integration or encapsulation project, inventory the available service providers and ensure that you build applications based on features that have general support.
Ollie>>OR....choose a vendor that will do all this for you and perhaps already has done this. 
Because SaaS services displace the largest amount of platform and infrastructure components, they offer the largest benefit case and are the most easily adopted by non-technical users.
Accommodating portability issues with SaaS is possible, but users must be aware that these accommodations will nearly always add to the cost of the project, reduce the field of SaaS providers available for consideration, and risk undermining some of the sources of SaaS savings. These disadvantages have to be weighed against the benefits of portability before any steps are taken, or the cure may be worse than the disease.
Ollie>>We are cost competitive with all the known SaaS vendors including SalesForce.com NetSuite.com and even the vendors of the Open Source solutions that offer hosted SaaS versions. 
About the author:Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @CloudAppsTT.

Ollie>> See http://www.o4bo.com and follow us on twitter @O4BO

Thursday, April 11, 2013

Founder of O4BO presents at IBM Conference in Hong Kong

This video http://tinyurl.com/cscrhey shows the presentation I made in Hong Kong to a conference on the IBM SmartCloud Enterprise which we use as our Infrastructure as a Service.  Shortly we will also have this video and the associated PowerPoint slide available on our web site.

There will also be a Case Study on O4BO published in DeveloperWorks and we will republish that case study here in my blog and on our web site.

Monday, April 1, 2013

Cost Calculator explained

Last week I shared a handy little TCO SaaS vs licensed on premise Calculator from our newest partner, SoftwareAdvice.

Andraya has given me an expanded explanation of that calculator to share with you.


Calculating the Total Cost of Ownership for Your Software


As Cloud technologies continue to evolve, more and more software buyers are seriously evaluating software as a service (SaaS) solutions against on-premise offerings. While there are many factors that influence which deployment model is best for any particular business (e.g., ability to manage IT internally and speed of deployment) the cost of the system is often a key factor. But comparing the true cost of a Cloud-based system against an on-premise system can be time-consuming and is often a complex undertaking.


For instance, most buyers understand that on-premise licenses are typically purchased with a large, upfront investment and SaaS licenses are purchased for a relatively cheaper subscription price. But many forget to consider the total cost of ownership (TCO) of their investment. That is, they don’t look beyond the licensing costs to consider how other factors such as the need to customize the software and integrate it with existing applications can influence the TCO of their software purchase.

Even then there are intricacies like maintenance and support and training requirements that can make creating an apples-to-apples comparison of the TCO on-premise and Cloud software difficult. If you’re not a seasoned veteran in modeling all these costs, comparing them can become overwhelming.

To help buyers ballpark the true costs of each software model, the Software Advice website created an interactive TCO calculator that software buyers can use to compare SaaS against on-premise software over a 10-year ownership period.

The calculator models annual and cumalative costs over this time period and shows buyers at which year of ownership the TCO of a SaaS system will equal that of an on-premise solution, based on user inputs. Although the data comes pre-populated with an example case, users can override every value to see the impact that changing any particular value will have on the TCO as a graph at the top of the calculator automatically refreshes after each update.

While the calculator is useful for getting you in a ballpark, it’s important to note that any business will still have to perform their due diligence to come up with an accurate figure that reflects their unique needs and situation. And there are several influencing factors (e.g. organic business growth) that no general calculator can accurately model. In any case, it’s worth checking it out to get an idea of which system seems right for your business. Check it out here.

Derek Singleton created the calculator and could best answer any questions. His email address is derek@softwareadvice.com.

____________________________

Aundraya Ruse
Editorial Coordinator