UPDATE: There are new videos from the Tokyo OpenStack Summit (2015) on the OpenStack Information Page. --PX--
In case you missed it, I put up a new page to document some seminal OpenStack videos for your convenience.
I will try to curate these videos going forward so that they represent a cross section depicting the current state of OpenStack as well as introductory content for neophyte OpenStack Admins and Operators.
Please feel free to reach out to me if you feel I have omitted anything. This is the first version and it will most definitely evolve from here.
Sep 25, 2015
Aug 26, 2015
OpenStack: the Open Source IT Transformation Tool
I've noticed one thing that has stood out about OpenStack and that's that everyone thinks of it as open source software. Well, it is at its core, but I'd like to think of it as more than just that. Over the past 2 years, I've worked with customers who were launching new revenue streams, reinventing their business model and implementing DevOps methodologies and philosophies. So, you ask me how I think of OpenStack? I think of it as an open source IT transformation tool.
OpenStack is definitely an open source software project complete with the challenges of open source development: it's organized into projects (e.g., Nova the compute project, Neutron the networking project) which have developers that are focused on developing for that project. Releases occur every six months which means that the feature set is ever changing and improving. This means that companies that publish distributions need to keep up with them and support published versions for a period of time.
The growth of OpenStack has been interesting to watch. The number of commits have increased 10000% between 2010 and 2015. While they seem to be plateau-ing, OpenStack is seeing more and more adoption, particularly in private clouds where about half of these clouds are OpenStack based. That's not to say there aren't other high level use-cases like distributed storage for CDN-like activities, multi-site clouds or public clouds (though, admittedly, the economics of building a public cloud can be prohibitive). The OpenStack Architecture Design Guide provides additional information on these use-cases.
Given all of the above, it's easy to see why OpenStack is viewed simply as open source software. But, what they neglect to consider is what it means to deploy OpenStack within the organization:
OpenStack is definitely an open source software project complete with the challenges of open source development: it's organized into projects (e.g., Nova the compute project, Neutron the networking project) which have developers that are focused on developing for that project. Releases occur every six months which means that the feature set is ever changing and improving. This means that companies that publish distributions need to keep up with them and support published versions for a period of time.
The growth of OpenStack has been interesting to watch. The number of commits have increased 10000% between 2010 and 2015. While they seem to be plateau-ing, OpenStack is seeing more and more adoption, particularly in private clouds where about half of these clouds are OpenStack based. That's not to say there aren't other high level use-cases like distributed storage for CDN-like activities, multi-site clouds or public clouds (though, admittedly, the economics of building a public cloud can be prohibitive). The OpenStack Architecture Design Guide provides additional information on these use-cases.
Given all of the above, it's easy to see why OpenStack is viewed simply as open source software. But, what they neglect to consider is what it means to deploy OpenStack within the organization:
- Bimodal IT: Gartner and other IT analyst firms have been promoting a framework that differentiates between legacy IT and the new IT ("Mode 1" and "Mode 2" in Gartner's lexicon, respectively; the difference being that Mode 1 was primarily concerned with the stability and longevity of systems whereas Mode 2 is more concerned with agility and rapid iteration). OpenStack is a Mode 2 enabling tool: it helps organizations shift their IT operations to a more dynamic model and facilitates the adoption of DevOps and PaaS.
- Transformation: Adopting Cloud is not an easy undertaking. It takes much planning to deploy it, certainly from a project perspective, but also from a governance and management perspective. The ability to manage and administer the environment is not innate in IT ops teams that tend towards Mode 1 operations; rather they require a significant will and desire to change and adapt to Mode 2 operations. OpenStack catalyzes this transformation, making it easier to adopt DevOps philosophies and PaaS deployment projects.
Apr 2, 2015
What is Going on at HP?
HP is adjusting its cloud strategy:
- The PTL for TripleO (OpenStack on OpenStack), the OpenStack installer, stepped down (the new PTL is from Red Hat);
- The hardware dedicated to TripleO testing and development has been repurposed;
- New releases of Helion with Eucalyptus.
Clearly HP is betting that Red Hat can do a better job of developing TripleO so that they can refocus their resources on other projects and initiatives. Given the news of new integration features with Eucalyptus, it's obvious we can look for a stronger hybrid cloud play against VMware and Microsoft.
Of course this begs the question of what the longer term strategy will be and whether HP will stay the course with open source or fork parts of it to maintain proprietary control over the integration points with other HP software products.
Time will tell.
Feb 24, 2015
The Cloud Value Chain
Consumers of cloud computing have clamored for a more unified approach to the services they use, be it IaaS, SaaS, PaaS or some other cloud based service. The knee jerk response is to federate services. While the approach is sound, allows seamless access across services and would in theory provide some modicum of security, this does not necessarily mean that they are provided by the same cloud services provider (CSP) leaving the consumer to manage relationships and SLAs with multiple CSPs. One possible solution is for CSPs to be a one-stop-shop that allows customers to create value by building up the stack, so to speak.
OK, it's a cheesy graphic, but we all understand that software (SaaS) is built on programming platforms (PaaS) which are run on infrastructure (IaaS). Clearly the graphic is not drawn to proportions because the SaaS market has outstripped the IaaS market. An inverted pyramid wouldn't cut it either because PaaS is a smaller market than IaaS. (Maybe an hourglass shape... But I digress.) A variant would be a more Application Service Provider (ASP) model where software is installed on an IaaS-based instance and offered for the use of customers. This latter variation is not strictly speaking SaaS but is a reasonable hand drawn facsimile.
So now we have a stack based on software created by software vendors or by the open source community on which value can be created. CSPs add value by tying the three service models together and offering them transparently to customers; CSP customers add value by using the tools to write apps and programs that their customers in turn use. Hence a cloud value chain. This, of course, does not take into account value added by cloud brokers or aggregators.
The interesting bit is what happens when the app is written and then launched. The current typical development cycle sees a dev team working to create an app and then making the architecture fit the app. This is backwards and I have lived it firsthand through cloud RFPs. This is because there is a gap in the knowledge and understanding of cloud computing among developers and their management. Schools generally don't teach students to write programs with cloud computing in mind. They teach them to write stand alone apps and programs that can be run on individual servers or, more often than not, in VMware-based virtual machines--AKA, the application service provider model.
The ASP model is inefficient because it relies on individual servers (whether virtual--no this is not cloud computing--or physical) to deliver the service and defeats the purpose of cloud computing: the flexibility to acquire only those resources necessary to meet demand.
In a perfect world, customers would acquire a SaaS seat via some self-service portal; the app or program would automatically create an instance or partition for that customer; and the app or program would be written on a PaaS to make it somewhat self-aware: that is, capable of making use of APIs to scale IaaS according to demand without mucking about with middleware. This raises the ugly spectre of vendor lock-in, but then, if you like the service, it meets your needs, and is flexible as you need it to be, why would you move?
Pause------------------------------------------Before we get any further, let's keep in mind the classic pyramid diagram of cloud computing:
OK, it's a cheesy graphic, but we all understand that software (SaaS) is built on programming platforms (PaaS) which are run on infrastructure (IaaS). Clearly the graphic is not drawn to proportions because the SaaS market has outstripped the IaaS market. An inverted pyramid wouldn't cut it either because PaaS is a smaller market than IaaS. (Maybe an hourglass shape... But I digress.) A variant would be a more Application Service Provider (ASP) model where software is installed on an IaaS-based instance and offered for the use of customers. This latter variation is not strictly speaking SaaS but is a reasonable hand drawn facsimile.
Unpause----------------------------------------Let's say one such CSP has launched a cloud computing service that offers these services to customers (say IaaS, PaaS, and SaaS to keep it simple and avoid getting into any sticky discussions about cloudwashing).
So now we have a stack based on software created by software vendors or by the open source community on which value can be created. CSPs add value by tying the three service models together and offering them transparently to customers; CSP customers add value by using the tools to write apps and programs that their customers in turn use. Hence a cloud value chain. This, of course, does not take into account value added by cloud brokers or aggregators.
The interesting bit is what happens when the app is written and then launched. The current typical development cycle sees a dev team working to create an app and then making the architecture fit the app. This is backwards and I have lived it firsthand through cloud RFPs. This is because there is a gap in the knowledge and understanding of cloud computing among developers and their management. Schools generally don't teach students to write programs with cloud computing in mind. They teach them to write stand alone apps and programs that can be run on individual servers or, more often than not, in VMware-based virtual machines--AKA, the application service provider model.
The ASP model is inefficient because it relies on individual servers (whether virtual--no this is not cloud computing--or physical) to deliver the service and defeats the purpose of cloud computing: the flexibility to acquire only those resources necessary to meet demand.
In a perfect world, customers would acquire a SaaS seat via some self-service portal; the app or program would automatically create an instance or partition for that customer; and the app or program would be written on a PaaS to make it somewhat self-aware: that is, capable of making use of APIs to scale IaaS according to demand without mucking about with middleware. This raises the ugly spectre of vendor lock-in, but then, if you like the service, it meets your needs, and is flexible as you need it to be, why would you move?
Subscribe to:
Posts (Atom)