Optimising development and deployment of ... - ResearchGate

More documents

Recommendations

Info

2 provider’s end. PaaS offerings are appealing to a wide range of types of software developers, such as Independent Software Vendors (ISVs), Value-Added Resellers (VARs), System Integrators, but also in-house IT teams [1]. The model is theoretically applicable to applications and solutions irrespective of size or domain, but in practice, it appears to have gained widespread adoption especially in the context of enterprise software applications [2], primarily due to their inherent database-centric nature. Apart from the benefits that the model of PaaS brings for software developers, it also carries a great number of benefits for prospective PaaS providers. Most importantly, it ultimately enables platform providers to pursue the creation of valueadded networks and the development of entire business ecosystems around their platforms, in an analogy to the way current mobile phone platforms like iPhone, Android and Blackberry are operating. This, however, remains largely a vision for the time being. With a few exceptions (e.g. force.com [3]), the majority of today’s PaaS providers lack the required technical facilities to support this concept to its full extent. The reason is that the design of mature platforms to support this model in an effective fashion is a particularly complex and challenging undertaking for PaaS providers. CAST is an ongoing research project 1 that is investigating the challenges associated with this vision and aims to develop a commercial platform that can fulfil this objective. The project is seeking to define an approach for the design of a platform that pushes the envelope of configurability and customisability, ecosystemcentric extensibility and native multi-tenancy. In the rest of this paper we discuss the key challenges associated with the design of such a platform, briefly review the state of practice in the area of PaaS offerings relative to those challenges, and provide an overview of the CAST platform’s main concepts and architecture. 2 Platform maturity levels and the state of practice The technology space for PaaS offerings is currently evolving and undergoing changes as it progresses towards higher levels of maturity. As usually happens with concepts that gain wide acceptance before they are fully analysed and understood, the term PaaS has become rather overloaded. Broadly speaking, we can categorise the PaaS offerings available today in two basic types: technology-specific PaaS, such as Google App Engine, Microsoft Azure, Heroku and Engine Yard, and domain-specific PaaS, such as Force.com, LongJump, Zoho Creator and WOLF. Despite the widespread adoption of PaaS as a model, it might not be an exaggeration to claim that, at the moment, only a few of the technology providers that categorise themselves under ‘PaaS’ are actually supporting the concept of PaaS to its full extent, i.e. work with a vision to achieve a true “software platform effect” [4] and to support the creation of actual ecosystems around their offerings. To facilitate comparison between the multitude of offerings and supporting platforms for SaaS/PaaS that are available on the market, attempts have been made to 1 http://www.cast-project.eu
3 develop maturity models based on sets of key characteristics. The first attempt was by Chong and Carraro of Microsoft [5], who tried to define a maturity model for ondemand/SaaS offerings and their supporting platforms, along the criteria of scalability, multi-tenancy, and customisability through configuration. On the basis of these characteristics they defined a maturity model consisting of four levels: • Level 0 (ad-hoc/custom): No provision is made to serve multiple tenants 2 from a single instance of server software. A separate instance of server software is installed for each customer to be served, including any necessary customisations specific to that customer (such as custom business logic, data schema, UI forms). This is essentially the same as the traditional Application Service Provider (ASP) model. • Level 1 (configurable): Applications are possible to customise via configuration (i.e. without writing and deploying any custom code) in order to fulfil specific requirements of different tenants. This allows all tenants to be served by the same application codebase. However, a dedicated installation (code-wise identical) is still being maintained for each customer. This type of architecture is not considered multi-tenant since computing resources are still not shared among software instances. Server space/time must be provided for as many instances as the vendor has customers. • Level 2 (configurable, multi tenant): Applications can be customised solely through configuration, and a single instance of server software can serve all customers. Compared to the previous level, this allows for much more efficient use of computing resources. However, scalability remains a problem, because the only way to scale the application up is by moving it to more powerful hardware, at least for as long as this remains cost-effective. • Level 3 (scalable, configurable, multi tenant): Applications are featuring all characteristics of the previous level, with the addition of load balancing to address scalability. The number of servers and instances can be adapted to match demand, making applications scalable to arbitrarily large numbers of customers. Ried, Rymer and Iqbal of Forrester Research proposed an alternative maturity model for cloud computing application platforms comprising six levels [6]. • Level 0 in the Forrester model concerns cases where some form of software outsourcing is inaccurately being referred to as SaaS provisioning. By this the authors are trying to stress that the term should be used with due care to avoid overloading and misinterpretations. • Level 1 corresponds to the traditional ASP model, i.e. to Microsoft’s level 0. A separate instance of server software is installed for each customer served. • Level 2 in the Forrester model corresponds to level 1 in Microsoft’s model. It refers to applications which are customisable via configuration, such that the codebase can be shared, but where dedicated installations are maintained for different customers. 2 The term tenant refers to a whole customer organisation/company, not to a single user.
Page 1: Optimising development and deployme
Page 5 and 6: 5 • Challenges which are generic
Page 7 and 8: 7 platform’s governance infrastru
Page 9 and 10: 9 Every solution or customisation i
Page 11 and 12: 11 for implementing new custom clie

Optimising development and deployment of ... - ResearchGate

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?