In the industry, OpenStack is seen as very hard to implement. Considering this, I began to think that most people who deploy OpenStack try to bite off too a large chunk of OpenStack at one go, to implement it all instead of just what they need. OpenStack is a cloud management platform, not the hypervisor, so perhaps we can take some lessons from how we installed VMware products when we just started out. We still implement things using the same patterns for vSphere. We should revisit OpenStack with this history in mind.
One of the things we associate with existing IT infrastructure vendors is their determination to go it alone for a major portion of their businesses. Vendor each believe that their solution is the best. They feel that integrating with competing solutions is unnecessary. Oracle and Microsoft were the most well-known examples, happily attracting users with a locked-in architecture and using that dominance to stifle competition. VMware has also exhibited this trait. You may layer additional technologies on top of vSphere, but you cannot put another hypervisor under a VMware product. What we see in open source is a willingness to integrate with other solutions, even competing projects. We are seeing some signs of a change in VMware, but not the dramatic shift that Microsoft has made.
In part one of Cost to Build a New Virtualized Data Center, we discussed the basic software costs for a virtualized data center based on VMware vSphere 6.0, Citrix XenServer 6.5, Microsoft Hyper-V 2012 R2 and 2016, and Red Hat. If you missed that, please click here to review before continuing.
In the good old days (rose-tinted spectacles required), there was only one operating system in the stack. It took care of device drivers and file IO. There were many flavours of OS, depending on the period, from UNIX and Windows to OS/2 and MacOS, and many, many others. Over time, the selection of operating systems in the data center reduced down to Linux and Windows (there are still holdouts for others, for various specific reasons, but Linux and Windows hold about 90% of the OS market). There are many flavours of Linux, but all an app developer in the enterprise really needs to know is which OS they are targeting. More and more, even that level is too low down for the app developer who is looking more at the middleware to make the final decisions.
I have seen far too many definitions of the term DevOps. Everyone, including myself, has their own definition. Worse, I have seen even more interpretations of what “doing DevOps” means within enterprises. Here are a few examples of what some people think DevOps is:
- Automating infrastructure
- Building out CI/CD pipelines
- Writing Chef scripts
- Creating a new silo called DevOps
- Doing anything on AWS
All of the above-mentioned items are tasks that are common when a company embraces DevOps philosophies but by themselves are not DevOps. DevOps is much bigger than these specific tasks.
Automation and orchestration are two terms we are hearing more often, especially when discussing virtualization and cloud computing. As virtualization and cloud computing technology continues to mature, so have the automation and orchestration that are such an intricate part of the solutions presented from this technology. As such, an increasing number of products and services are built around automation and orchestration. This article focuses on the underlying technology as a prelude to discussing the different products. The information below should be of interest to anyone looking to expand their skillset to compete and excel in a technology world that is traveling full speed up into the clouds.