Six requirements for enterprise-class OpenStack (part 2nd): Open architecture and Hybrid cloud compatibility

The full text includes three parts:

• The first part
• Part II
• Part III

In the first part of this series, I covered six requirements for enterprise-level OpenStack. Now, I'll focus on the next two main requirements: open architecture and hybrid cloud compatibility. Let's get started right away.

Demand 3-open architecture and reduce vendor lock-in

We've talked about building robust cloud control planes and cloud management systems. One of the most appealing features of OpenStack is the use of open source code platforms to eliminate vendor lock-in.

"No vendor lock-in" is Snake oil marketing tips (Snake oils salesmanship)

Have you ever been promised OpenStack to avoid vendor lock-in? No vendor lock-in is just an unrealistic idea-something that can be imagined perfectly but never realized. Any system, there is some kind of vendor lock. For example, some of you should have used the RedHat Enterprise version of Linux, a fully 100% open source Linux operating system, as the default Linux version of your enterprise. You see, RedHat is a form of locking. RedHat Linux is a specific version of Linux designed for a specific purpose. Using it, you will be locked into their specific reference architectures, packaging systems, installation/system boot, and so on, even if it is open source.

In fact, at many customers, I don't see much of the fear of locking, but more about "more locking." For example, a client who asks to remain anonymous, based on vendor lock-in considerations, has an opinion on using our block storage components, even if it is 100% open source. After further understanding, I found out that customers wanted to continue using their existing storage providers (NETAPP and Hitachi Data systems) and didn't want to train their IT team to use a new storage system. It can be seen that their concerns about vendor lock-in, mostly don't want to have more locks, rather than completely want to eliminate the lock.

Therefore, it is more important to understand the risks that your business can take. Turning to OpenStack, like the example of Linux earlier, means you can reduce some risk by training your IT team for new software, and support from multiple vendors for open source software.

In other words, OpenStack can certainly reduce vendor lock-in, but not completely eliminate it. So go for an open architecture and expect to reap an enterprise-class product.

Locking is always present, especially with enterprise products

I hope the lock doesn't exist, but it does exist all the time, as you read from the above. This means that instead of looking for a lock, it's better to see what kind of lock you can accept. An enterprise-level OpenStack version that provides a range of options through an open architecture. However, a real cloud operating system and enterprise products will not offer unlimited options. Why not? Because of that, the support model is unsustainable, and the individual product providers will eventually leave the field. Even large vendors do not offer all the options to all users.

If you want to build your own custom cloud operating system around OpenStack, you can do it, but that's not a product. It requires customized professional services. Just like those companies that have launched their own Linux distributions for a while, they bring a degree of disruption to the industry, ultimately harmful to industry and users. And it takes a lot of resources to do it yourself. You need a 20-30-person Python development team that is familiar with infrastructure (compute, storage, and networking) and that they need to devote their entire time to your own customized OpenStack. A team might look like:

So, ultimately, if you need an enterprise-class OpenStack-driven private cloud solution, you need to choose a vendor.

Requirement 4-Hybrid cloud compatible

Hybrid cloud is a whole new world. Most of the customers we've communicated with have realized that they need to provide the best tools to their developers. Different needs, different requirements, different ideas, complaints are not the same. Every business is unique. Some companies want to start with a public cloud and then move on to a private cloud for a while, some want to start with a private cloud, but also slow to adopt a public cloud, while others go hand in hand in two directions. RightScale's 2014 report has some very good investigative data to support this:

Let's see why your enterprise-class OpenStack-driven cloud OS provider Best has an excellent hybrid cloud story to talk about.

Hybrid Cloud First strategy

Each company needs a hybrid cloud-first strategy. This means that the hybrid cloud should be your first and primary requirement. Then, around the hybrid cloud, using a single, integrated regulatory model will bring you the best benefits. Ultimately, develop a process based on your application and requirements to determine what type of cloud each job requires. The following diagram highlights this process, but you know that each company is different so the data will not be the same:

Understand cloud compatibility and the role of enterprise-class private cloud in hybrid cloud

I've done a lot of compatibility, and the most painful thing is the compatibility between IPSec and VPN. Achieving compatibility between vendors is cost-intensive, often requires a lot of work, and often ultimately difficult to achieve a good result. And unfortunately, compatibility is often misunderstood, especially for public cloud/private cloud/hybrid cloud.

The challenge of hybrid cloud is how to solve the porting problem of the application. If you need a hybrid cloud of public and private clouds, whether the app is developed in a cloud, migrated between two clouds, or from one cloud to another, the portability of the app is a must. When you select an application and its cloud-native automation framework, and move them from one cloud to another, some of the key things must remain the same:

• Relatively stable performance
• The underlying storage, network, and computing architectures are consistent or approximate
• The automation framework you apply must be compatible with the APIs in two cloud
• In each cloud, the total cost of running the application (TCO) should be within 1/2-twice-fold range
• and behavioral compatibility, which means that non-API functions also need to match
• Support for compatibility with related public cloud APIs

The following table will help explain these requirements:

Of course, when you design your application, you also need to consider avoiding locking with specific clouds, such as avoiding reliance on IRules on HA/DRS,F5 on Dynamodb,vmware on AWS, and so on.
If you are unable to meet these requirements and are not able to get compatibility, the porting of the application will definitely fail. The performance of your app can vary greatly on different clouds, one of which is best on the cloud, some may lack functionality to make your app work, and if there is no behavioral compatibility, your automation framework may not work. For example, if there is a timer in the application, it assumes that the virtual opportunity starts in 30 minutes, but the virtual machine on a cloud has been up for an hour or two.

All of these issues must be addressed through hybrid cloud compatibility.

OpenStack requires a Reference Architecture

The Linux kernel requires a reference architecture. In fact, each Linux main issuer has created its own reference architecture, so we now have different branches of the Linux operating system. For example, there are redhat/fedora/centos branches and Debian/ubuntu branches. These pure x86 operating systems have their own reference architectures, and migrations within each type are relatively inexpensive to use. However, when the RedHat administrator goes to use Debian, he may be a little confused until he is fully aware of the difference. The situation with OpenStack is no different.

OpenStack, like most of its open-source compatriots, has no reference architecture. It's just the kernel of the cloud operating system. This is both its advantage and its disadvantage. Linux is the same. You can get Cray Linux for your supercomputer and you can also get Android for embedded ARM devices. Both are Linux, but there are different architectures that make the application impossible to migrate between the two. OpenStack is similar, and one day most of the OpenStack clouds are not compatible because each has its own architecture. Each cloud has its own architecture and is destined to become a opensnowflake (a variety of different styles of diamond rings inside the counter).

OpenStack-driven enterprise-class cloud operating systems require a common reference architecture. Only then can you ensure that each deployed cloud instance is compatible with other cloud instances. Currently, these reference architectures have not yet emerged. However, assuming that AWS and GCP have a single cloud Reference Architecture (what we call the "Elastic Cloud Reference Architecture"), it is hard to imagine that no OpenStack Reference Architecture would be very similar to this architecture.

To be more clear, there will certainly be multiple reference architectures in the future to stand out. I've also seen architectures in high-performance areas, as well as other industries such as the oil and gas industry.

Enterprise-Class Reference architectures

Ultimately, you'll want to bet where the OpenStack Enterprise Reference Architecture will land, but the current data shows that only one or two of the top 10 public clouds are based on OpenStack.

If businesses want agile, flexible, and multi-choice, it seems obvious that OpenStack needs to support an enterprise-grade Reference Architecture that is dedicated to building a hybrid cloud that is compatible with the ultimate winner in the public cloud world. This is just my personal opinion and it now looks like Amazon, Google, and Microsoft.

Enterprise-class OpenStack means an enterprise-class Reference Architecture that guarantees hybrid cloud compatibility and application portability.

The second part summarizes

Designing an open architecture that provides hybrid cloud compatibility is one of the current conclusions. There may be a debate about how to do this, but for the pragmatist, it is certain that there will be winners in the public cloud domain, and that the top 10 public clouds are already occupied by non-openstack schemes. We need to be prepared accordingly.

More importantly, when you expect an enterprise product, remember to ask for an open architecture.

in the next article, we talk about what it means to deliver an excellent, scalable, and resilient infrastructure for next-generation applications.

Original: The 6 Requirements of Enterprise-grade openstack,posted on April, by Randy Bias

Six requirements for enterprise-class OpenStack (part 2nd): Open architecture and Hybrid cloud compatibility