Improving service design in the IaaS model
/ photo Juhan Sonin CC The
ever-changing requirements for cloud infrastructure lead to the need to develop new business models and create architectural solutions. This allows you to constantly increase the level of security and data manageability.
In our blog on Habré, we already wrote about solutions and services for managing data and organizing backups to the cloud of the IaaS provider.
Today we would like to touch on the topic of delivery and design of services in the IaaS model. We’ll talk about deployment models that drive the collaboration of all participants in the application development and delivery process.
Service design
Technologies and business processes only become more complicated every year, the volumes of processed data are growing. To maximize the use of company resources and increase user satisfaction, it is recommended to use the ITIL library. ITIL offers best practices for providing high quality IT services.
The approach focuses the organization on achieving its goals, as well as on the resources spent on their achievement. When building a strategy, a service provider should focus primarily on the goals of its potential customer. For this, it is necessary to clearly understand what role the provided IT service will play in the client’s business. This is where ITIL methodologies come to the rescue, helping to build a strategy, which is a fundamental stage of service design.
ITIL is gaining wide popularity among companies in various fields. Companies such as Hewlett-Packard, Boeing, IBM, Sony, Honda and many others work with ITIL. Forrester conducted a study by interviewing 491 participants in the itSMF (IT Service Management Forum). According to the data obtained , the methods proposed by ITIL increased the productivity of services in 85% of respondents, and 65% of respondents noted a positive impact on the reputation of the business. It is worth saying that Cisco joined the ranks of ITIL adherents . According to its experts, service design is a critical component of the cloud infrastructure.
It is the penetration of cloud technologies in all areas of activity thata significant impact on service design approaches. Service design is a serious stage, which includes eight points: design coordination, service catalog management, service level management, capacity management, availability management, service continuity management, information security management, and supplier management. Each of these aspects has undergone certain changes.
The task of adding a service to the catalog began to require a competent description of the cloud service so that the client did not have questions regarding its implementation. The same applies to service level management: in the service level agreement (SLA), such moments as the time to troubleshoot cloud infrastructure problems, compensations paid, guarantees provided, etc. should now be spelled out.
The next item is accessibility management. When migrating to the cloud, it becomes important for the provider to provide a high level of availability, as if the user had deployed their applications “in place”. For example, in the case of IaaS, it is necessary to ensure the availability of memory or processors ready to connect, as well as provide tools for monitoring resources.
As for the management of services, the manager must now take into account the possibility of a “fall” not only of the company’s site, but also of the cloud provider’s site. Moreover, organizations will have to study the solutions offered by service providers, research the market and seek compromises. With all this, one should not forget about the assessment of security conditions, confidentiality and data integrity.
The final element of service design is the supplier management process. It also underwent changes: there was a need to evaluate external services and monitor the quality of services provided. Importantly, an additional task was to establish trusting relationships with the supplier.
Deployment Models
In the current “cloudy” world, the processes that determine how infrastructure is delivered to end users by IT teams have changed. Red Hat employee James Labocki watched organizations from various business areas for several months , including telecommunications, finance, and transportation. During this time, he appreciated the mechanisms of interaction between teams with each other and managed to identify three main models for improving the design of the service.
Repeatable Deployment Model
In this model, a team of system administrators is responsible for the development and configuration of infrastructure elements, whose responsibilities include the allocation of resources for a virtual environment (virtual switches, storage, virtual machines, OS installation), the deployment of containers, and their protection.
After the infrastructure is configured, the team responsible for delivering the applications enters the work. The responsibilities of delivery specialists include deploying the services needed to run and run the applications correctly, configuring the application server cluster and setting up a database connection pool. The final step in their work is to deploy the application from a binary file to the repository.
In such a model, deployment of infrastructure is more often automated and only sometimes deployment and configuration of application server. Deploying an application from a binary file is not automated often.
This model is easiest to implement, however, the lack of connectivity of the development processes with the deployment, configuration and operation of the application itself makes it impossible to solve problems requiring fast delivery. In addition, such a model is not “bulletproof” because it is subject to the strong influence of the human factor at the application deployment stage.
Custom Repeatable Build Model
In this model, the system administrator team is still responsible for deploying and configuring the infrastructure: storage, network, virtual machines, and containers. However, this type of task is often automated using specialized tools. After that, the finished infrastructure is transferred in the form of an indivisible unit to the application delivery team.
Delivery specialists are responsible for configuring the application server and sending executable files to it - all this is also done using automation and configuration management platforms.
The model of customized repeated builds saves time spent on development processes, but requires special knowledge for bundling the source, preparing a working image and automating deployment. In addition, the model has a significant minus: the commissioning of one application takes several months, so this model may be unacceptable for large companies that run thousands of applications.
Prescriptive Repeatable Build Model
The virtual infrastructure in the prescribed recurring builds model includes storage, network, virtual machines, or containers configured by the system administration team. However, in this case, the configured infrastructure is not transferred to the application delivery team, but to the PaaS team, which provides PaaS services using the resources of the cloud infrastructure.
The development environment in the PaaS model is accessed using the user interface, presented as a self-service portal. Developers get a convenient interface for working with the service and access to the application sources.
This type of model is characterized by the highest level of standardization, which allows developers to quickly switch between the source code and the working application, eliminating all kinds of difficulties.
Conclusion
In conclusion, we note that the choice of pattern for your organization depends on many factors, among which stand out:
- Level of own skills;
- Uniformity of application development processes;
- Business requirements related to the application life cycle (in particular, time);
- Application architecture;
- The flexibility of management processes.
It is also worth saying that the speed and method of delivering the service to the end user in the IaaS model depends on many variables. However, one of the determining factors remains the choice of deployment pattern and the coordinated work of adjacent teams with each other.
PS Other materials from our blog on Habré: