Cloud based platforms catch on more and more as a running environment for web applications. What advantages, compared to the traditional “on-premise” infrastructure or classic web-hosting, do they offer? And what new possibilities (from the point of view of the web integrator) does cloud bring to the architecture of web systems using LAMP technology? These, and many other questions, will answer the first part of the new series.

Also, you should not miss the previous part of the article series about web integration – Putting Continuous Integration (CI) into Practice – Part 2. It is a must-read!

Virtualisation as a foundation of the cloud

In the last decade we have been witnessing gradual but more and more significant advancement of computer virtualisation in server, and later also in desktop environment. First, not very powerful server hypervisors¹ based on full virtualisation of the hardware incl. CPU, were followed by revolution based on implementation of the virtualisation support directly on the CPU level.

This significantly improved performance of virtualised systems, whose running costs went from dozens to single digit percentage values of the hosting processor power. Together with improvement of the concept of the peripherals virtualisation in the form of drivers closely cooperating with the host system allowed massive succession of this technology in a broad scale in both on-premise² environment where companies have their own server infrastructure available, and between infrastructure providers, who offer it on a rental base.

This, originally on-demand³ supplied virtual systems, gradually developed into complex cloud platforms with wide portfolio of services for running the applications. One of the most renowned in this field are Amazon Web Services (AWS) and Microsoft Azure.

¹ Hypervisor is a specialised software, or combination of hardware and software, which allows creating and operating of virtualised computers.

² On-premise is the way of running the solution, where the organisation has it under full control – typically, it’s run on their own infrastructure.

³ On-demand describes the solution operated on the infrastructure of the provider, to which the organisation has access via the Internet and usually does not have full control over it.

Models of operation in the cloud environment

Basic models of service, provided through the cloud environment, are following: IaaS – Infrastructure as a Service features basic directly from virtualisation derived service enabling to create and manage infrastructure consisting of:

• virtualised servers,
• private networks (VLAN – Virtual Local Area Network),
• specialised network components, typically:

— „load balancers“ – application switches, securing high accessibility of the given application service by transmuting requirements into cluster consisting of two or more virtual servers,

— network firewalls (optionally explicitly allow or deny access from public network to selected network services provided by the virtualised servers in the cluster),

— and application firewalls with the possibility of an active detection/prevention of security attacks in given application protocol („Intruder Detection/Prevention Systems“).

In case of IaaS remains the responsibility for the maintenance of the operation environment of the system of virtual servers, creating and maintenance of the application environment within it on the service user.

Configuration of the virtual servers, networks and network services is done via web-based administration console, or there might be API available to allow automation of such administration operations on another system’s level. Within the framework, the IaaS provider usually offers installation of pre-set images of number of different types/versions of operation systems, optimised for running in IaaS cloud (containing drivers for cooperation with hypervisor, used by the provider for server virtualisation – i.e. VMware ESX/ESXi, Xen/Citrix XenSource or Microsoft Hyper-V technologies).

In case of smaller cloud service providers is the IaaS offer often final. Compared to mentioned global players it can, in case of the given cloud is satisfactory for suggested solution, compete in more attractive price and individual local support.

IaaS services are charged on pay-as-you-go basis, where the price is given for computed unit per unit of time (typically combination of CPU and RAM, defined in so called type of instance of the virtual server over the period of one hour) or data unit (transferred or uploaded gigabyte for the network transfer, respectively data warehouse).

Base price can also be influenced by the installed operation system (i.e. in case of Windows Server includes the license fee payment), more powerful CPU architecture (as a standard, cloud service providers’ data centres use processors with the most favourable computing power/power input rate, but those are not the most powerful models) or more powerful repository type (SSDs, sometimes installed locally instead of a shared disk array).

PaaS („Platform as a Service“) offers an environment for operating web-based applications built on a particular application platform (i.e. PHP, .NET, Node.js or Ruby on Rails). In this model, the service provider takes full responsibility for needed infrastructure, consisting of IaaS instruments, operating system and application runtime environment software necessary for running of the application.

Service user obtains in the first place one or more interfaces for uploading the application into the environment (typically FTPS/SFTP, Git SCM, eventually API and/or CLI tool, including support for deployment management).

PasS gives the user reduced options of configuration of the application environment (i.e. language or framework options, insertion of expansion modules and adjustment options of the global configuration of the application environment, which can usually be adjusted through configuration of the application itself, when uploaded into PaaS).

PaaS as a service can also include manual or automated (threshold-parameter controlled) scaling, where, in combination with the load balancer, virtual engines securing processing of the application code depending on the current load are created and disposed of.

Same as in case of IaaS, the price unfolds from actually consumed sources including use of IaaS resources (type and number of instances of the virtual engines, warehouses and data transfers) and other PaaS specific services (i.e. automated scaling support and also preparedness for scaling in greater number of instances). Amongst PaaS platform belong Azure Websites, Google AppEngine, AWS Elastic Beanstalk or cloud platform Heroku.

SaaS – Software as a Service is a cloud layer of the highest level of abstraction and it means the supply of a working server software with clearly defined functions and interface.

In SaaS model are typically supplied data warehouses (SQL/relation and noSQL database systems), directory services (LDAP, Azure Active Directory), CRM or e-commerce systems. Falling into this model are also currently very popular cloud services Google Apps and Office 365 or, for example, on-demand versions of Atlassian company products (JIRA, Confluence). In this category also fall systems for content distribution (CDN – Content Delivery Network).

In SaaS model, the user primarily works with the web interface of the service, which offers the model of secure access to individual functions and data based on the user roles and groups with the possibility of management of the access and optionally also access of other software or cloud services via API, eventually by using of special CLI tools for maintenance and integration.

SaaS platform offers very restricted (or none at all) options of insertion of your own application code. In case of databases, this may be “stored” procedures or functions executed by the database engine, in other cases uploading of the code in the form of package (extension), which the given software allows to load up within the means of its modular architecture. Typically only in case the instance of SaaS is operationally completely separated from instances of other customers, otherwise only integration on different servers via SSI (Server-Side Include – entered on the server side) model or exclusively via code running on the web browser of the user (UI components coded in Javascript that are using accessible server API) is possible.

 SaaS services are usually charged depending on the on the number of user accounts, size of the data storage or number of parallel client connections or their total number per period of time, or combination of these parameters. Parameters can be usually changed at any time accordingly to the changing needs without having to interrupt accessibility of the service.

In all the models, the cloud platform offers possibilities that are, in traditional on-premise model, either completely missing, or their implementation requires great efforts:

• high level of security of the access to the network services and active protection against various forms of attack (network firewall, intruder detection/prevention system),
• high level of the data security (redundant multilayer storage, optionally also geographical),
• option of pooling cloud instruments in IaaS/PaaS model into virtual private networks and their connection with the network environment of the organisation (site2site VPN), creating of hybrid cloud environment and support while connecting the users into the cloud environment via site2client VPN,
• load balancer (incl. support of automated grading of cluster sources in accordance with given load parameters),
• and SSL offloading.

PHP application in the cloud environment

PHP based web applications and portals (or portals still operated in the traditional LAMP model) can be used in the cloud environment utilising all above mentioned models. The easiest is, if considering operational requirements, using PaaS, which offers support for operating of PHP applications, in combination with database in SaaS model. In this case the whole environment is created and further maintained via web administration, deployment of changes is executed using familiar tools (application code via Git SCM push mechanism, or by upload via SSH/SFTP, database changes manually or by script via database console).

Problems can arise, if the PHP application has special requirements on the application environment (i.e. uses specific PHP extensions, which are not available and it’s not possible to upload them into PaaS) or its framework isn’t suitable for deployment in cloud with automated scaling and “failover” mechanisms (typically uses local file system as a persistent storage). In these cases it is necessary to base either part, or the whole solution of operation of the application, base on the IaaS model (thus reduce the utilisation of the cloud platform on the virtualised server infrastructure), or to adjust the system framework of the web solution so that it’s compatible with the PaaS cloud.

While doing this, it’s important to take in an account , that the IaaS model, which is the closest to the traditional on-premise infrastructure, also suffers from infirmities of this approach, in particular it requires resources for the management of the operation system and application running environment, at the same time in case of requirements on high granted accessibility requires conceiving of cluster, by which it puts strain on the application framework equivalent to scaling mechanism, included in PaaS. It follows several recommendations for architecture of PHP applications, which are intended to be deployed in the cloud:

• Do not mix code and data – do not use file system for saving of persistent data, abstract all the operations with the data storage beyond the general boundary (this will allow to implement one of the available SaaS services) or work directly with the database abstraction of PDO type.
• Use actively all caching mechanisms that the chosen application platform/framework offers in combination with the chosen cloud environment (in the computing instances there will never be an excess of the computing power or operation memory; for caching you can use in-memory key-value of the database of the Redis if the platform offers this in the SaaS model).
• Expect serving static source files (stylesheets, pics, videos) from other absolute URLs – within the platform you will be able to utilise accessible solutions of CDN (Content Delivery Network).
• In case you would like to use relation databases, do not use SQL commands dependent on a particular database engine (with exception of cases, where you know up front, what type of database will be used in cloud); design the queries programmatically by the application code, using the library that will allow or use ORM tool.
• Do not use PHP extensions that are not available in the original setting in the PaaS model of the given cloud and it’s not possible to upload them with confidence additionally.
• Do not use libraries and frameworks that are written in conflict with the above mentioned rules.
• If it’s possible, avoid using server services that cannot be used in the selected cloud platform in the form of SaaS (i.e. exotic key-value databases or full-text indexers).

Costs calculation

Significant change introduced by the cloud platforms in all mentioned models is the pay-as-you-go service accounting system, i.e. interim payments in accordance with used up resources. Planning of the operating costs doesn’t necessarily require execution of the precise sizing for the expected peak attendance in the given period (usually number of years) and consequent purchase or lease of corresponding computing resources (servers and other network elements) not taking in account whether they will be fully utilised (not to mention the case when traffic exceeds expectations, requiring unplanned new infrastructure…).

In case of the cloud, the sizing is only indicative, it determines the estimated operating costs in the given time-frame (typically one month) depending on number of users of the web solution, that are supposed to be served in given response time. We can therefore ultimately calculate the cost of servicing a single user and include it in the entire business transaction, which uses the web-based solution.

This, together with guaranteed accessibility of cloud services (standard in models SaaS and PaaS, or in case of IaaS under condition of generating the cluster) and high level of security, are the main advantages of use of cloud as opposed to the traditional on-premise infrastructure.

In the second part of this article, you will learn about practical experience from deployment and scaling of CMS based on PHP software architecture (which has many specific characteristics)  into cloud environment Microsoft Azure.

You can now follow to the next part – article called: Architecture and operating of web applications in a cloud environment (Part 2).