Archive

Posts Tagged ‘continuous integration’

Startups: Want to launch new features hourly?

If you read sites like highscalability.com you will have certainly read about those big name dotcoms that deploy new features to production up to tens of times a day. For most startups bringing features to production is still a manual, at best semi-manual process. You have the odd start-up that has it all automated, but unfortunately this is often a signal that they have too much time on their hands which points towards more critical problems.

What if startups would not have to worry about how to set-up hourly feature deployment? What if they could get an open source solution that delivers them flexible and highly scalable continuous deployment in minutes?

What if Startups could launch new features faster than the top DotComs and scale almost as good?

If this sounds attractive to you or you know a start-up to whom it would be, then you should visit this blog post. Ubuntu has launched a beta program and if enough startups sign up, then they will build an instant and scalable open source continuous deployment solution for them.

What comes after SaaSification?

Fujitsu just presented SaaSification on Cebit. Existing applications can be easily brought to the Cloud and sold via App Stores and SaaS marketplaces. IBM is also working on SaaSification and even adds multi-tenancy.

What is next?

Everybody wants to have a full App Store or SaaS Marketplace, so SaaSification is the next step after launching your store. However converting a client/server application to the Cloud is only step 1. Step 2 is creating new services that are specifically built for the Cloud.

What does Built-for-the-Cloud means?

Application design is changing. Traditional Web applications are built on a LAMP architecture. New Cloud-Ready applications should be Big Data ready and should be looking at SMAQ architectures.

Cloud-Ready applications should also accept the new reality of APIs. Both for exposure as well as consumption. This means that applications need to be redesigned according to application slices.

So if SaaSification wants to be successful then it needs to add quick enablers for multi-tenancy, big data, integration with external APIs as well as API exposure, etc. This integration concept can be called iPaaS or integration platform-as-a-Service. iPaaS should not only focus on exposing or integrating APIs but on providing complex services by integration multiple SaaS solutions together.

Other enablers should be added as well. Basically 80% of a SaaS solution consists out of the same elements or tries to solve the same problems. These could all be provided via a SaaSification PaaS:

  • Blog – to describe the newest ideas.
  • Forum – for people to get answers from the community.
  • IT PaaS – where you run the actual business logic and UI. Data storage is assumed to be provided by the Big Data elements.
  • Portal and Mobile Portal – allows to quickly define the “static” content for the web and mobile site.
  • Deployment management – ideally continuous deployment or integration tools that allow fast feature by feature deployment.
  • A/B testing – allow new features to be deployed to subsets of users and check which version of a feature has the highest impact on the bottom-line. A/B testing was made popular by Amazon.
  • Automated testing – lots of testing can be automated but especially end-to-end and performance testing are the harder tests that should be focused on.
  • Configuration management – manage the version control of the code.
  • Metering and billing – be able to meter the resource usage by users, companies or any other element you want to meter and be able to bill users both for subscriptions as well as for usage, ideally with advanced set-up with overage, etc.
  • Marketplace listing and provisioning – automate the listing of products on the marketplace as well as the provisioning of new services.
  • Single sign-on & identity management – allow companies to use their own user credentials (e.g. SAML), authorization for third-parties (e.g. oAuth), etc.
  • Reporting and data warehousing – this can be part of the big data stack but especially being able to create ad-hoc reports for instance for A/B testing . Of course regular business reporting needs to be included as well.
  • ERP – accounting, resource management, etc.
  • CRM – sales and lead management
  • Operations & Maintenance – automation of back-ups, monitoring both for the performance and fault management but as well business monitoring.
  • Support – helpdesk, ticketing system, SLA management, etc.
  • Social integration – tools to add social aspects like Facebook apps, Twitter feeds, etc.
  • etc.

The idea is not that a SaaSification PaaS offers all these solutions by custom development. Instead the SaaSification PaaS should allow startups to assemble an ideal architecture by combining different solutions from different providers. For example you would be able to select the support solution you prefer, e.g. desk.com, zendesk.com, etc. and this solution would be completely integrated into the overall stack, e.g. CRM integration with help desk and fault management together with sign sign-on.

SaaSification 2.0 should focus on making sure that 2-5 people can start a new dotcom solution and focus on creating a killer service and not on building up yet another stack of solutions for configuration management, support, billing, etc. If a SaaSification PaaS can shorten the time to launch with months and reduce the needs to operate the solution with several people then startups will see the value. Instead of SaaSification PaaS a good term could be Incubation PaaS, to incubate SaaS solutions. Once the business model and solution is proven, there will be money to move to a custom-build stack but during incubation and crossing-the-chasm enterpreneurs should be able to focus on delivering value to their customers and not on re-inventing the startup wheel.

Follow

Get every new post delivered to your Inbox.

Join 328 other followers

%d bloggers like this: