About OpenStack for Service Providers
Posted by Paul Robers
In the last few places I have worked with service providers (service providers / telecom / managed service providers) from Iceland to Tokyo, and they all know that they are the undisputed leader (“800 pound gorilla” ) - a public cloud - goes to their liking. For a while they all tried to “pretend to be dead”, but the “gorilla” was all the same and she continued to run in their direction. During all my trips, I had no doubt about one thing: service providers must admit that something needs to be radically changed. How can they come to this?
Photo by Ryan Poplin.
Part of my work today is visiting clients to tell them what the OpenStack platform is, what its capabilities are, and whether they can integrate it with their infrastructure. One thing is clear: in order to get involved in the fight against public cloud vendors, a service provider needs to revise and refine its cloud services offerings, shifting its focus to software-defined technologies and automation.
If we look at the ecosystem of the public cloud, we will see that one of the most serious competitive advantages of the platform is its automation capabilities. Unfortunately, many service providers today use the old hardware and software infrastructure. I recently met with several service providers working on outdated infrastructure, which, regrettably, believe that automation is based on the speed with which their engineers are able to rotate in their seats. To compete with large public clouds in today's market, service providers are exploring infrastructures such as OpenStack to regain their proper architectural foundation.
From time to time I came across very sophisticated service providers who built their own clouds based on OpenStack. The conversation with them was approximately as follows:
Me: It's great that you work on the OpenStack platform. How are things going with her?
They: This is a nightmare! We spent weeks figuring out how to set everything up, and our engineers have to look for answers through IRC chat and forums!
Me: Wow!
I believe that many of you are the owner or tenant of your home, which requires basic care and maintenance. I am sure that most of you are not mechanical engineers or designers and have no idea how everything in your house is assembled and works. This is not required of us.
As for OpenStack, here you can draw an analogy with the house. OpenStack is based on many comprehensive open source projects that are linked through sophisticated APIs that even the most experienced infrastructure technical support engineers are fighting with. From a financial point of view, the choice of this path at the initial stage is likely to seriously affect income due to unattained business goals and failure to meet deadlines. With the do-it-yourself approach, many people start working with OpenStack and, as a rule, fail, which leaves a very unpleasant “aftertaste”.
The main business goal of any service provider is to help design and provide reliable hosting of customer applications. The key to success when working with OpenStack is to attract a vendor who has collected all the necessary code fragments and will provide the service provider with the enterprise level support he needs to run a business. Please entrust OpenStack technical support and packaging to a trusted vendor.
Today, OpenStack provides a framework through which customers can simplify heterogeneous technology infrastructures by abstracting and combining various software interfaces into one common infrastructure or API. The most important thing is to increase the efficiency of the data center (DPC).
From a network point of view, OpenStack currently provides integration methods with well-known devices such as F5 Big-IP, Cisco Nexus, Citrix Netscaler, and Arista switches (integration with more devices is expected). As for storage, everything from EMC, NetApp, Coraid and to Nexenta are integrated with OpenStack . For hypervisors, you can choose from options such as VMWare, KVM, Xen, and HyperV. A service provider can use a data center approach that is completely independent of the infrastructure and allow OpenStack to solve all complex problems.
According to the surveyusers at the OpenStack Summit in Atlanta, the # 1 business incentive to use OpenStack is the ability to avoid being tied to a single vendor platform. Service providers rely on working with partners in the production of hardware and software (software) who do not point fingers at each other when solving urgent problems. Service providers also need to be able to establish strong strategic relationships that will enable them to put into effect development plans for the products of a particular vendor. If such a relationship is not possible, it is extremely difficult for a service provider to succeed. OpenStack provides service providers with the flexibility to let them free themselves of vendors at any time and decide which combination of hardware and software will work best for them and their customers.
OpenStack includes about a dozen projects, but outside the kernel, some of the projects may be of more interest to service providers than others. For example:
In the past, I worked for Carpathia Hosting , a cloud-based enterprise service provider . Around 2009, I worked for a startup that provided VM lifecycle management solutions and capabilities similar to those offered by the OpenStack Heat project. In fact, I needed a way to describe my data center through some kind of conceptual design (blueprint) or code that I could save. Then I wanted to have the operational ability to programmatically instantiate new data center blocks from this blueprint. In other words, this startup provided a tool that allowed me to build a Data Center Class, after which I could instantiate new Objects. Very cool! Heat works the same way. This is a way to orchestrate your OpenStack environment with AWS Cloudformation compatible templates . I highly recommend using the Heat pattern every time you deploy OpenStack to achieve a high level of automation. You can find a good guide to Heat here .
All service providers need the ability to determine the amount of resources consumed and the period of their consumption. As mentioned above, if you use an environment that is independent of equipment, as well as incompatible types of networks and data warehousing, you need a single, unified method for tracking the resources used to simplify monitoring and management. Ceilometer is an OpenStack project used by service providers to provide measurement data that can then be integrated into a billing system. More information can be found in the documentation .
Many service providers use different (often complex and headache) ways to automate the assembly of their "clean" servers, but OpenStack now has the Ironic project , which will give them this opportunity with a single API. Some companies, such as Rackspace, have announced their intention to introduce their own version of Ironic called OnMetal. The value of this project is more than just a single API; service providers will be able to take advantage of all the features of OpenStack, including measurements, orchestration, block data storage, etc., on "clean" servers.
Ironic emerged from the Nova Bare Metal project, which was then phased out. At the same time, Ironic is still in the incubation phase, the team officially considers it “beta-stable” for the release of Icehouse and is still working on writing user documentation and is actively fixing bugs . The goal is to make Ironic available in the OpenStack Juno release, but this goal can be expanded. As for maturity, this is a project that needs to be monitored and started to be considered within the laboratory, but it is definitely not an industrial level project. In general, I am personally enthusiastic about this project and how it will affect service providers.
OpenStack is developing rapidly and will continue to do so. Both the OpenStack community and the vendors that are players in this segment are working to make it easier for customers to use all the key features, but there are still gaps.
One of the most significant problems is finding reference architectures that match your use case. If you visit any Summit, you will become a participant in fantastic meetings, but the bottom line is the question: “What architecture should I choose?”
Vendors contribute a lot of code, trying to make OpenStack work with their solutions, but, unfortunately, the gold standard that service providers might use seems to be missing. At the moment, the most common architectures seem to use Ceph for data storage, KVM as a hypervisor / compute node, while the standard network option does not exist.
Most services within OpenStack today can be protected by HA. Note that I used the word "majority". Many service providers today have customers using old or lazy applications that require a basic infrastructure to provide HA. The OpenStack platform does not currently provide a ready-made method for providing HA for the entire infrastructure; this was not the purpose of its design. To be more concise, OpenStack today does not provide HA for running Nova compute nodes: if the compute nodes themselves fail, their VMs will not automatically switch to other nodes. OpenStack uses the same approach as Netflix, relying on developers to integrate HA into their applications. An application that really runs on the cloud must be able to withstand any infrastructure failure.
The beauty of technology is that all problems can be solved. If the client requires HA, then it can use another hypervisor that provides HA by default, such as VMWare , which supports cool features like DRS. Clients who want to continue working with KVM can use, for example, Nagios or Zabbix to monitor the operation of these devices and even to automatically restart services.
This issue was discussed in more detail in the blog of my colleague Dmitry Novakovsky about the missing functionality in OpenStack .
Who needs billing? Just kidding. As mentioned above, today OpenStack presents the Ceilometer project, which monitors the resources used. One of the difficulties is that many service providers use their own billing systems and often these are completely individual solutions. In all likelihood, a large community will not take the risk and create some kind of official billing system, so it is best for customers to work with a vendor who wants to integrate with their existing accounting systems.
Service providers work in one of the most difficult verticals because of the big competition. From time to time, major technological shifts occur that allow the business to become more dynamic and efficient. OpenStack seems to be the best wave to ride in the future.
To summarize, we can highlight several key principles that a service provider needs to focus on.
1. Avoid binding to the vendor.
2.Actively apply automation and orchestration.
3.Do not try to deploy the platform yourself, this is a big headache, as a result of which you will get FrankenStack.
4. Collaborate with a vendor who is impartial to the hardware and software that helps you create a solution that meets your needs.
5. Go for it and deploy OpenStack!
Original article in English .
In the last few places I have worked with service providers (service providers / telecom / managed service providers) from Iceland to Tokyo, and they all know that they are the undisputed leader (“800 pound gorilla” ) - a public cloud - goes to their liking. For a while they all tried to “pretend to be dead”, but the “gorilla” was all the same and she continued to run in their direction. During all my trips, I had no doubt about one thing: service providers must admit that something needs to be radically changed. How can they come to this?
Photo by Ryan Poplin.
Part of my work today is visiting clients to tell them what the OpenStack platform is, what its capabilities are, and whether they can integrate it with their infrastructure. One thing is clear: in order to get involved in the fight against public cloud vendors, a service provider needs to revise and refine its cloud services offerings, shifting its focus to software-defined technologies and automation.
If we look at the ecosystem of the public cloud, we will see that one of the most serious competitive advantages of the platform is its automation capabilities. Unfortunately, many service providers today use the old hardware and software infrastructure. I recently met with several service providers working on outdated infrastructure, which, regrettably, believe that automation is based on the speed with which their engineers are able to rotate in their seats. To compete with large public clouds in today's market, service providers are exploring infrastructures such as OpenStack to regain their proper architectural foundation.
Do it yourself approach to working with OpenStack
From time to time I came across very sophisticated service providers who built their own clouds based on OpenStack. The conversation with them was approximately as follows:
Me: It's great that you work on the OpenStack platform. How are things going with her?
They: This is a nightmare! We spent weeks figuring out how to set everything up, and our engineers have to look for answers through IRC chat and forums!
Me: Wow!
I believe that many of you are the owner or tenant of your home, which requires basic care and maintenance. I am sure that most of you are not mechanical engineers or designers and have no idea how everything in your house is assembled and works. This is not required of us.
As for OpenStack, here you can draw an analogy with the house. OpenStack is based on many comprehensive open source projects that are linked through sophisticated APIs that even the most experienced infrastructure technical support engineers are fighting with. From a financial point of view, the choice of this path at the initial stage is likely to seriously affect income due to unattained business goals and failure to meet deadlines. With the do-it-yourself approach, many people start working with OpenStack and, as a rule, fail, which leaves a very unpleasant “aftertaste”.
The main business goal of any service provider is to help design and provide reliable hosting of customer applications. The key to success when working with OpenStack is to attract a vendor who has collected all the necessary code fragments and will provide the service provider with the enterprise level support he needs to run a business. Please entrust OpenStack technical support and packaging to a trusted vendor.
What gives OpenStack
Today, OpenStack provides a framework through which customers can simplify heterogeneous technology infrastructures by abstracting and combining various software interfaces into one common infrastructure or API. The most important thing is to increase the efficiency of the data center (DPC).
From a network point of view, OpenStack currently provides integration methods with well-known devices such as F5 Big-IP, Cisco Nexus, Citrix Netscaler, and Arista switches (integration with more devices is expected). As for storage, everything from EMC, NetApp, Coraid and to Nexenta are integrated with OpenStack . For hypervisors, you can choose from options such as VMWare, KVM, Xen, and HyperV. A service provider can use a data center approach that is completely independent of the infrastructure and allow OpenStack to solve all complex problems.
According to the surveyusers at the OpenStack Summit in Atlanta, the # 1 business incentive to use OpenStack is the ability to avoid being tied to a single vendor platform. Service providers rely on working with partners in the production of hardware and software (software) who do not point fingers at each other when solving urgent problems. Service providers also need to be able to establish strong strategic relationships that will enable them to put into effect development plans for the products of a particular vendor. If such a relationship is not possible, it is extremely difficult for a service provider to succeed. OpenStack provides service providers with the flexibility to let them free themselves of vendors at any time and decide which combination of hardware and software will work best for them and their customers.
Interesting projects for service providers
OpenStack includes about a dozen projects, but outside the kernel, some of the projects may be of more interest to service providers than others. For example:
Heat
In the past, I worked for Carpathia Hosting , a cloud-based enterprise service provider . Around 2009, I worked for a startup that provided VM lifecycle management solutions and capabilities similar to those offered by the OpenStack Heat project. In fact, I needed a way to describe my data center through some kind of conceptual design (blueprint) or code that I could save. Then I wanted to have the operational ability to programmatically instantiate new data center blocks from this blueprint. In other words, this startup provided a tool that allowed me to build a Data Center Class, after which I could instantiate new Objects. Very cool! Heat works the same way. This is a way to orchestrate your OpenStack environment with AWS Cloudformation compatible templates . I highly recommend using the Heat pattern every time you deploy OpenStack to achieve a high level of automation. You can find a good guide to Heat here .
Ceilometer
All service providers need the ability to determine the amount of resources consumed and the period of their consumption. As mentioned above, if you use an environment that is independent of equipment, as well as incompatible types of networks and data warehousing, you need a single, unified method for tracking the resources used to simplify monitoring and management. Ceilometer is an OpenStack project used by service providers to provide measurement data that can then be integrated into a billing system. More information can be found in the documentation .
Ironic
Many service providers use different (often complex and headache) ways to automate the assembly of their "clean" servers, but OpenStack now has the Ironic project , which will give them this opportunity with a single API. Some companies, such as Rackspace, have announced their intention to introduce their own version of Ironic called OnMetal. The value of this project is more than just a single API; service providers will be able to take advantage of all the features of OpenStack, including measurements, orchestration, block data storage, etc., on "clean" servers.
Ironic emerged from the Nova Bare Metal project, which was then phased out. At the same time, Ironic is still in the incubation phase, the team officially considers it “beta-stable” for the release of Icehouse and is still working on writing user documentation and is actively fixing bugs . The goal is to make Ironic available in the OpenStack Juno release, but this goal can be expanded. As for maturity, this is a project that needs to be monitored and started to be considered within the laboratory, but it is definitely not an industrial level project. In general, I am personally enthusiastic about this project and how it will affect service providers.
What is OpenStack missing?
OpenStack is developing rapidly and will continue to do so. Both the OpenStack community and the vendors that are players in this segment are working to make it easier for customers to use all the key features, but there are still gaps.
Reference architectures
One of the most significant problems is finding reference architectures that match your use case. If you visit any Summit, you will become a participant in fantastic meetings, but the bottom line is the question: “What architecture should I choose?”
Vendors contribute a lot of code, trying to make OpenStack work with their solutions, but, unfortunately, the gold standard that service providers might use seems to be missing. At the moment, the most common architectures seem to use Ceph for data storage, KVM as a hypervisor / compute node, while the standard network option does not exist.
High Availability (HA)
Most services within OpenStack today can be protected by HA. Note that I used the word "majority". Many service providers today have customers using old or lazy applications that require a basic infrastructure to provide HA. The OpenStack platform does not currently provide a ready-made method for providing HA for the entire infrastructure; this was not the purpose of its design. To be more concise, OpenStack today does not provide HA for running Nova compute nodes: if the compute nodes themselves fail, their VMs will not automatically switch to other nodes. OpenStack uses the same approach as Netflix, relying on developers to integrate HA into their applications. An application that really runs on the cloud must be able to withstand any infrastructure failure.
The beauty of technology is that all problems can be solved. If the client requires HA, then it can use another hypervisor that provides HA by default, such as VMWare , which supports cool features like DRS. Clients who want to continue working with KVM can use, for example, Nagios or Zabbix to monitor the operation of these devices and even to automatically restart services.
This issue was discussed in more detail in the blog of my colleague Dmitry Novakovsky about the missing functionality in OpenStack .
Billing
Who needs billing? Just kidding. As mentioned above, today OpenStack presents the Ceilometer project, which monitors the resources used. One of the difficulties is that many service providers use their own billing systems and often these are completely individual solutions. In all likelihood, a large community will not take the risk and create some kind of official billing system, so it is best for customers to work with a vendor who wants to integrate with their existing accounting systems.
Service providers, make it a reality!
Service providers work in one of the most difficult verticals because of the big competition. From time to time, major technological shifts occur that allow the business to become more dynamic and efficient. OpenStack seems to be the best wave to ride in the future.
To summarize, we can highlight several key principles that a service provider needs to focus on.
1. Avoid binding to the vendor.
2.Actively apply automation and orchestration.
3.Do not try to deploy the platform yourself, this is a big headache, as a result of which you will get FrankenStack.
4. Collaborate with a vendor who is impartial to the hardware and software that helps you create a solution that meets your needs.
5. Go for it and deploy OpenStack!
Original article in English .