For several years, the domestic IT-industry lives with an eye on the cloud. Evangelists of an alternative model of service consumption talk about new opportunities for users, but the cloud brings several problems that an IT manager will have to solve. Of course, this also applies to building applications within the cloud paradigm.
Certainly, the cloud offers several benefits to consumers. Firstly, it saves money on maintenance of IT infrastructure, which a company may not have or will be reduced to a minimum. Second, cloud applications can be accessed from anywhere in the network. Third, the cloud model allows users to shift the burden of hardware and software certification from the service provider to the service consumer in accordance with Federal Law 152 (“On Personal Data Protection”). At the same time, the process of creating software provided from the cloud changes significantly, depending on the type of service and tools available to the developer. In addition, there is the non-obvious but very acute problem of cloud application delivery and deployment on the user side. Wikipedia has a good definition of clouds, which is “a distributed processing technology in which computing resources and capacities are made available to the user as an Internet service”. The key terms in this formulation are resource and service.
Categories of services
Currently, the most common division of all cloud solutions into three categories: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).
IaaS is a service that abstracts the user from dealing with hardware resources. In the simplest case, any data center owner can sell their physical server resources. Although most often, of course, these services provide the functionality of virtual machine resources. Examples of such services are Amazon (EC2), Windows Azure (VM Role), virtualization from VMware, Parallels and others.
In essence, the IaaS model brings nothing new to cloud application developers – in practice, writing a program to run on a physical computer is not much different from an application to run inside virtual machines. This is not surprising, because virtual machines were designed to be completely transparent to the software that runs on them. Of course, there may be exceptions, and the developer can use some specific technologies provided by a virtualization platform to create more efficient software products. For example, a specific and optimized communication channel can be used to organize communications between programs – VMware Communication Interface, data storage media (Shared Folders or specialized data storage subsystems) or the product distribution format (Virtual Appliances), etc. And the more of these specific technologies are available to the developer as part of an IaaS solution, the more likely he crosses the vaguely defined boundary into the realm of PaaS solutions.
The distinction between PaaS and IaaS is not obvious, but extremely important. The term PaaS became widespread later than IaaS and is a logical development of the original ideas. Let’s imagine a developer writing a typical corporate or web application that looks something like this: a database, a web server, and an application server. The developer writes the application, buys three virtual machines, and runs the corresponding component on each of them.
When the application starts to live and grow, the number of users grows, and at some point, the capacity of one webserver may not be enough – you need to buy and run several servers, load balancing solution between which will be some load balancing solution (Load Balancer).
And after some time, the database server capacity may not be enough, and you will need to increase its capacity, for example, by allocating significantly more serious equipment.
The resulting system is good for everyone, but very expensive to run – most systems have inconstant load, and owners must pay to support the equipment needed at peak times. Clearly, it would be more efficient to dynamically scale the system depending on the current load and pay only for the resources used. How to solve this problem?
The creators of PaaS systems offered developers tools that can dynamically manage the parameters of the system. Hence, in fact, the term PaaS comes from – the provision of platform services as a service. Amazon Cloud Computing and Microsoft Azure, which provide similar functionality, can serve as vivid examples of such services:
- The ability to dynamically scale and distribute load.
- payment only for used resources.
- Specialized APIs for working with databases optimized for the needs of scalable applications and messaging tools.
- Content Delivery Network (CDN) services.
It is important to note the availability of APIs and development environments that allow (incidentally, at great sacrifice to the portability of the resulting solutions) to create applications that adapt to changing external conditions. Which, by the way, very often fall into the category of SaaS.
At the highest level of abstraction in the cloud stack are solutions of the SaaS category, providing application services directly to end users. Some of the best examples are Salesforce.com, Microsoft Office 365 and Google Apps. Some applications are created using the advantages of IaaS and PaaS, some are developed with their own infrastructure in mind – there are no uniform rules, and each developer solves the tasks based on the current situation. But a typical problem for independent software developers is organizing the channels to deliver their services. In this case we can deal with delivering a cloud application to a specific end user from within a company (from the corporate cloud) or selling the service through providers. This problem primarily arises because direct service delivery to users is not always possible, since intermediaries, such as service providers, are required.
Let’s consider the situation on the example of an abstract independent software developer. At the stage when it is necessary to deliver a service to the end user, such a company has to solve the problem of integrating its product into the provider’s infrastructure, hence the need to standardize and automate the procedures for deployment and renewal of the service in the provider’s infrastructure, plus billing. With billing, the IT department can calculate the cost of providing cloud applications for internal customers and be able to manage this cost. Now, there is virtually the only way to build third-party applications into the cloud infrastructure (private or commercial) – the APS application packaging standard. All service providers that support this standard are automatically enabled to deploy applications that are packaged in this format.
From a developer’s perspective, each of the three categories of cloud services has its own advantages and disadvantages.
Using IaaS is attractive due to the lack of need to build and maintain an expensive IT infrastructure, which at any time can be rented where there is a surplus of computing power and disk space, and in Russia such a service is no longer uncommon – the capacity of their data centers on a model IaaS sold system integrators. Another thing is the convenience of development. On the one hand it is convenient that creating applications in virtual environments is not much different from writing programs on a usual computer, on the other hand this freedom makes system architects do a lot of rough work: the absence of additional services such as database services or scaling tools within IaaS leads to the need to create them independently for a particular project. Clearly, in most situations, self-development will require more effort. In addition, it is not obvious that the resulting services will be effective when the load on the virtual application increases due to an increase in the number of users or the number of transactions.
PaaS doesn’t have the disadvantage of a lack of dedicated cloud services – it’s limited to a very specific toolkit that developers need to work with. Yes, working within PaaS will require some time to learn the platform, but it will make cloud development more technologically advanced and allow the experience gained in the process of creating one product to be transferred to other cloud projects. However, focusing applications (and therefore programmers) on one platform has an obvious disadvantage: when migrating to another PaaS system or extending the functionality of a service with options provided under another platform, it will not be possible to adapt the application on a new basis. It will either be rewritten from scratch or a bridge will have to be made between the two platforms in the form of an API. This, of course, reduces the main advantage of a cloud solution – the scalable performance and overall reliability of the service.
But let’s not forget the economic aspect of PaaS. As a rule, the platform tools include tools that help to dynamically scale the cloud depending on the load. The ability to quickly borrow and release resources makes PaaS a more cost-effective solution than IaaS, where virtual environments are always in use. Accordingly, the price of using a leased infrastructure is also constant, and for high-load solutions, where dozens or hundreds of virtual environments are needed, it is also high.
The most intriguing aspect is related to SaaS development, where the main thing is to properly organize the delivery of cloud applications to the client. It is clear now, that for enterprise solutions the delivery and installation should be automated – it is physically impossible to “worm” dozens of applications for thousands of internal clients of a corporate cloud manually by system administrators. Obviously, automation is the quality that should make the process of internal application delivery like the process in a public cloud. In fact, the internal business processes of commercial and private clouds are not very different. In both cases, the sequence of internal cloud business processes looks the same: “Selection of a service => allocation of resources for the service => delivery and installation of the service => billing of the service => possibility for the user to make additional orders => rejection of the service and release of computing resources. Therefore, the mass market demands standards that are created specifically for the commercial provision of cloud services.
Would you like to build your own cloud development? Contact Enkronos team today.