today I would like to provide you with an article written by Emmanuel Forgues – my friend and system engineer on hyper converged systems. This article is a translation from the original one in french :
After he wrote the french one, we thought an english version would be relevant, and here it is :
To survive today, a company faces a challenge: the balance between development time and market demand. It is not possible to wait 6 months to come up with an application. The release of a new OS version (Android, IOS, Windows) requires immediate reactivity under the risk of facing potentially heavy financial penalties or just miss a new market. However, we should not confuse speed with haste when marketing departments are pushing, especially in a weak economic context. An example of the crippling effects of not considering this balance was the mobile application deployed urgently, to inform the French public about any terrorist actions. This application, developed at the request of the French authorities (SAIP), was developed in 2 months by a team of 15 engineers only started working a few hours only after the attack in Nice took place.
The new convergence and hyper-convergence solutions provide companies with the rationality of an infrastructure to face the challenges of DevOps. The major publishers have different approaches but should eventually be able to integrate a broader range of technologies into a single offer.
The unnamed problems encountered in business:
Two technical entities participate in the development of all the companies relying on IT.
On one hand, the development team (DEV) which produces IT solutions both for internal or external use, and, on the other hand, the operation team (OPS) which provides DEV with the necessary tools and maintains them. We see that their goals are often contradictory within the same company, in fact their alignment is a strategic and economic challenge for IT departments.
For convenience we will speak of DEV for Development and OPS teams for Operational teams.
Where is the brake between market demands and technical services? Why are DEV not reactive enough? The first answer: because they are hamstrung by overly rigid infrastructure, inadequate service catalog and physical or virtual infrastructure without the capacity of “programmability”. Why are OPS not reactive enough? It is likely that they are not sufficiently involved with the DEV teams to meet their expectations.
Obviously the physical and virtual infrastructure has to change to become more programmable. At the same time the DEV should be able to program infrastructure and OPS must be able to understand and control the interactions of DEV with the infrastructure. In short, the difficulties between DEV and OPS are as follows:
“DevOps” is the necessary balance between these two teams. DevOps is the concatenation of English words Development and Operation
The vast majority of analysis highlight that the years 2016-2017 would be the beginning of a massive adoption of PaaS (Platform as a Service), the DevOps and Docker container.
- According to IDC : 72% of companies will use PaaS
- Dzone : 45% of people are evaluating or already using Docker
- RighScale : 71% of companies announce multi-cloud based IT strategy.
A “Platform as a Service” (PAAS) is a “cloud computing” service providing a platform and a necessary environment for developers with the benefits of the “cloud”.
This type of services includes :
- rapidly scalable environment without big investment and maintenance costs;
- user-friendly web interface which can be used without complex infrastructure knowledge;
- flexibility to use in different circumstances;
- highly collaborative environment;
- access and data security is handled by the services provider.
Today, the question of the deployment of existing applications is still valid. But soon we will have to ask the question of the deployment of future applications (container / Dockers). The Docker technology will allow the execution of services on any server of the cloud infrastructure.
Unlike a VM (a several GB Virtual Machine), the container (a few MB) does not carry OS. The container / Docker is lighter and faster to start, move, duplicate (as with any other routine maintenance actions).
Consider a company that has sharply increased resources for urgent strategic development (banking, development companies, etc). With a traditional solution to VM, you must have provisioned a large number of VMs on hold and start to make them available. It is therefore necessary to have at the same time the required infrastructure to support the start of these environments: CPU, RAM, storage, I/O and disk I/O network, etc.
By eliminating the OS, containers consume 4 to 30 times less RAM and disk. In this case a few seconds are required to start applications. Containers / Dockers are for the applications what virtualization was for the servers in the 90s.
Today container usage makes development easier by automating integration. Continuous integration automates source code updates from DEV, QA, pre-prod and production.
We highlight the problem of the start of production of these containers which cannot be done by IT staff as network control, security, storage, backup, supervision and are not properly integrated into the programming and configuration Container. Therefore, the containers will be a software response to DevOps as used by DEV consuming infrastructure, while being under the control of OPS.
For enhancing integration, publishers already offer complet solutions which manage load balancing, failover management of resilience, encryption, etc.
According to Datalog, Dockers adoption was multiplied by 5 in 2015:
The Container Dockers will quickly bring all their advantages as a DevOps solution!
The problem at stake is therefore the DevOps:
According to Gartner, DevOps will exceed the stage of niche in 2016 with 25% of very large global companies who will have adopted it and a market of $ 2.3 billion. According to IDC, in France 53% of companies have committed widespread DevOps approach to all their developments.
In the face difficulties, companies go though to transform their traditional infrastructures into an agile enough solution, cloud providers can offer the implementation of DevOps with their scale-out approaches and offers of economies of scale.
The implementation of DevOps requires looking at several issues: structural, organizational, resource, etc. For the CIO, who is responsible for the technical answer, it is a nightmare to implement an agile infrastructure with the current traditional equipment. He has to manage both complex environments, multiple servers (storage, computing, networking, security) as developments Services (Multiple databases, WEB portals, software developments like Python, C ++, the libs and other APIs, supervising applications and performance analysis). Containers technology and overlays networks provide relevant responses to network problems, in the case of the administrator of these services anticipate their arrival. Everything has to be realized in record time in difficult conditions as external market pressure, the internal pressure of marketing and with limited budgets. Once it is all in place, it will finally take maximum advantage for all applications to interact with each other properly while being able to manage rapid migration needs. And for sure, all of this without impacting the entire infrastructure.
- number of physical or virtual servers
- several development services
- ensuring stability and interactions face of increasing complexity based on the number of servers and services
- implementation time which tend to be increasingly short
- strained budgets
- ensure the ability to migrate to another environment to another, making sure to respect the three previous points
- growing market pressure (marketing in the company)
- ensure the evolution of acquisitions over several years
Excluding traditional solutions, two major trends on the market meet these needs:
- Build / assemble for a Specific “Workload“: the main players being DataBase Oracle Exadata Machine (Hyper-Appliances).
- Integrate all storage, computing power (computing), the network, etc in a solution that can start multiple workloads (convergence solutions and Hyper-convergences as Nutanix (http://www.nutanix.com) , Simplivity (https://www.simplivity.com) VCE (http://www.vce.com), …) Today these technologies can support the existing workloads but should also anticipate any future workloads.
Infrastructure (Hyper-)converged and integrated systems have the greatest potential to integrate into a solution of DevOps. They offer all the benefits of being expandable, standard able of IT, programmable, etc.
Some players of the market offer in their solutions, all or part of the set of interesting building blocks for DevOps:
- flexibility of resources availability (storage, CPU, RAM, …) with solutions of (hyper-) convergence.
- Availability of necessary applications with Dockers solutions or containers and applications for rapid availability.
- rapid availability of a work environments via a Web portal: 1-Click.
- reduction of complex and costly skills in infrastructure teams
- total infrastructure outsourcing to no longer bear the direct costs
Today, compagnies like VMware, CISCO and Nutanix companies able doing the provisioning of VMs as well as containers, Simplivity up to date is capable of doing it quickly for VMs only, (but I expect to see this company changing their strategy soon). VMware is able to have a single OS to support multiple containers already simplifying the management of this OS. Nutanix is able to provide their storage to the containers and has acquired Calm.io for DC automatization. Nevertheless it will have to change the product to be able to deploy existing applications as it is already able to do for the future applications. All these companies show an amazing ability to avoif creating bottlenecks and serenely address their future.
Today these editors can meet the companies needs to simplify the infrastructure by removing servers as SAN or eliminate the Fiber-Channel, simplify backups and enjoy the DRP (Disaster Recovery Plan) in more acceptable conditions. In a second phase it will be important to take better advantage of this infrastructure to deploy or move the full environments. Finally, these same players will then be able to fully meet the needs of DevOps.
Today these players are competing in the infrastructure market but the main battle has already moved to providing applications with the associated necessary infrastructure (SDDC). Some of them are already positioned on the infrastructure while at the same time positioning themselves in the software layers. When looking at the margins they practice one may see that they are similar to those of the software companies (85%). All these companies may offer simplification but some also expect the optimization of these infrastructures (VCE, Nutanix for example).
The winner will certainly be the one who will manage to provide a single integrated solution and be capable to deploy both applications of today (Exchange, etc.) and tomorrow’s applications (Contrainers / Dockers). The remaining question is : who will offer the first a “SDDC – all in a box ” solution, able to contain all these needs, and when ?
My sincere thanks to my wife Elena Forgues for her patience and to my friends David Dubois , Eric Fourn and Yan Pradeau (writer, author of Algebra, Allia Editions) for proofreading and advices.