OpenStack by the Numbers: Welcome Kilo!

As April 30th arrived, so did the next named release of OpenStack. Kilo is the 11th official release of OpenStack since its inception in 2010. Born of the with great hopes and minds at Rackspace and NASA, the widely known open cloud ecosystem continues to gain steam, awareness, and sometimes a little bit of criticism. Whether you’re using OpenStack today or investigating it for down the road, this is a good time to take a quick look at what went into the Kilo release.

By the People, For the People

Not even taking into account the corporate support and customer side of the equation, I always like to see how the developer and operations side of OpenStack fares as each release comes out. One thing that is undeniable is that the velocity continues to increase for OpenStack development, and the stability is also doing the same. The program list (aka project list…and probably both because that keeps changing) is widening with the official integration of Ironic, a bare metal provisioning project.

Features are growing rapidly also, with a lot of fixes and enhancements that have been wrapped into this release.

Juno in Review

How does 18,992 code commits sound? That’s pretty impressive if you ask me, and what is just as impressive is if you look at how we assessed Juno in the past here.

juno

So, with Juno in the bank, how about we look at how Kilo measured up by these numbers.

Kilo Kicking it up a Notch

As we took a look at the analytics from activity.openstack.org, the numbers were both impressive and telling. 21,125 code commits from 1,593 developers and a total of 1,839 submitters which covers code, documentation, and training.

kilo

Looking at Juno in comparison shows that we have a continued rise above a linear scale with the Kilo release. This is telling as we can see the velocity of development and the growth of the ecosystem which is increasing at each release.

If we look at the picture since the beginning, from 124,499 total code commits, 3,279 total developers, and 3,611 total submitters, it tells us that Kilo produces 16.96% of the total code in just the Kilo release alone!

openstack-all-time

Code counting doesn’t tell you success stories. What does show a positive story in these numbers is that they keep moving up and to the right. Increasing both on participation, fixes, features, and total growth.

OpenStack Kilo Presentation

As the launch press makes its way around, we will see a lot of good detail on features, advancements, and also on challenges. One thing I do appreciate about a lot of the OpenStack community is that they acknowledge that the challenges are real, and are being taken on as much as possible.

Here is a quick view of the Kilo release as presented by the OpenStack Foundation:

OpenStack Kilo – April 2015 from OpenStack Foundation

Eric’s Favorite Features

There are lots of very interesting features and improvements that were packed into the Kilo development cycle. According to the OpenStack Foundation there were 394 to be exact. I don’t have an exhaustive list, but I can tell you a couple of things that I am particularly keen on that arrived with Kilo.

Keystone-to-Keystone Federation

Identity federation was available in previous releases, but was well known to be challenging to work with and very new. The Kilo release of Keystone has seen the federation features listed as stable with much more documentation and working examples of how to federate your OpenStack clouds to one another. As people explored OpenStack without federation, the issue rose that if more than one OpenStack cloud was implemented that the identity environments were separated, and thus difficult to manage.

By adding stable Keystone to Keystone federation we have the ability to create a true hybrid OpenStack cloud. This is also important as companies are embracing OpenStack and the potential for two organizations to have to merge during a purchase or partnership was a bit limiter up to this point.

Ironic for VirtualBox (experimental)

Although this is an experimental feature within the Ironic (bare-metal provisioning) program, the availability of a way to test out Ironic deployment for people is going to be very helpful as we get more folks exploring OpenStack. It’s one thing to have a working OpenStack environment, and a whole other thing to have procedures and methods to build, deploy, and grow the infrastructure. Using VirtualBox as the test bed for Ironic will allow more people to test the waters and provide feedback to the development teams. This can only lead to good things.

Scale Preparation for Neutron

This is a work in progress, but it is top of mind as we head into the Liberty release. Networking within the OpenStack environment has often been shown to have scale challenges when growing in large environments. Many won’t hit any of the scale limits that are currently a challenge, but it is important just the same that the teams are working to address this and have done lots of work to build in future improvements as upcoming releases come out.

People

Yes, people are a feature. This includes a growing community, an eager developer ecosystem, and the most important thing of all which is people using OpenStack. The focus on the operator and what is called the “superuser” has been big with the last couple of OpenStack Summits, and with good reason. The more people who are using OpenStack in some form, the better the overall ecosystem will do.

Looking forward to an equally exciting Liberty release, and I hope to see lots of you in Vancouver at the OpenStack Summit!




Managed Clouds and Why SMB Customers Don’t Chase Unicorns

If we look at the economy and distribution of wealth, we can see that there are some interesting statistics about what many call the 1%. Stretch a little further into the top 10% and you will find what they refer to as the champagne glass effect. In other words, the top percentile of earners have a disproportionate percentage of the overall wealth. So what does this mean to what I’m talking about here?

Is There a Champagne Glass Effect in IT?

Gartner has a well laid out graph to illustrate the overall spend of technology that is available here: http://www.gartner.com/technology/metrics/

source: http://www.gartner.com/technology/metrics/

source: http://www.gartner.com/technology/metrics/

This is less of the illustration of a champagne glass effect with the graph than it is showing the distribution of spending by industry. As you can imagine, and as could be correlated by other data, there are certain industries and company sizes that spend more on services and IT resources.

What is different about the spending at the “enterprise” level, is that it is often done on hardware, software, and cloud resources, with a strong reliance on internal IT resources to manage those resources. While we often focus on those enterprise success stories with high trust and amplified feedback loops between the IT and business teams, what about the rest of us?

Small to Medium Business: The 99%

In using the economic champagne glass as the example to illustrate the 1% versus the 99%, we can take the same view of technology spending and reliance on internal resources for technology development and management. I don’t want say that everything in the SMB space can be painted with the same broad brush, but there are hundreds upon thousands of businesses ranging in size, and they will consume and provision IT resources much differently than the 1%.

We can even expand to the 90%/10% range really and still capture a lot of environments which are still heavily invested in the traditional IT model.

SMB Doesn’t Chase Unicorns

The elusive unicorn of IT is that internal IT staffer, or contractor, or even an entire team of people who are working magic in the technology backing the organization. That magic, is really not magical at all. But the ability to attain that seamless end-to-end success in providing IT resources to meet business needs is just as elusive as a unicorn when you aren’t staffed to be able to handle the tasks.

Cloud is often touted as the answer. It isn’t. Cloud is an enabling technology and methodology to deploy business applications into, but requires the ability to create, deploy, and manage these applications into that cloud environment. With many companies (especially SMB) this is as elusive as the fabled unicorn that so many seem to hold in high regard. So, what is the SMB customer supposed to do when they aren’t prepared to staff up with internal resources in hopes of building these environments?

Managed Cloud

To many cloud pundits and DevOps advocates, this is the antithesis of cloud. That being said, I’m a cloud advocate, but I also have the view of being inside the SMB market through experience and through my exposure in social networks, conferences, and various community organizations.

If managed cloud is often frowned upon by many leaders in the cloud industry, the question is why?

As a fan and customer of Rackspace, I have really loved their choice to heavily leverage the managed cloud as a key offering. For many SMB customers, this is precisely what we need. Some regard it as training wheels to get into the cloud, and if that is the case then I don’t think that is such a bad thing.

I’ve made a note of the great article by John Engates, CTO of Rackspace, here at VirtualizationSoftware.com and through conversations with other Rackers like Cody Bunch and Ken Hui (recently moved to EMC), you can see that the presence at VMUG conferences is really highlighting their plan to show their distinct capability to run big VMware and OpenStack clouds for their customers.

cody-vmug

Mike Kavis at Cloud Technology Partners wrote an article on the move by Rackspace here that talks about the concept and the shift towards more managed provisioning versus the panacea of self-provisioned IaaS.

More companies are rising up with the approach of bringing managed services as an offering to differentiate themselves from the big IaaS (Infrastructure-as-a-Service) providers like cloud juggernaut Amazon, as well as Google and Microsoft who are climbing the market share charts quickly behind them. It isn’t that IaaS isn’t good, but the point is that the market for IaaS business is shrouded by these three major players.

SMB + High Touch = High Trust

The path to adoption of more cloud resources and DevOps practices in the SMB market place is one that will be paved by the managed cloud route in my opinion. Organizations which have not got the resources nor the experience to create and consume services in cloud environments will find that the managed cloud path is one that leads to comfort with the new ways in cloud IT.

Is this a guaranteed path? No. Is this right for every company? No. That’s right, I said it. At this point in time and for a long time to come, public and private cloud environments, managed or self-provisioned, are not going to be appropriate for many organizations.

In a year or two we can reassess the landscape a bit and make a judgement on things then. For now, I like that managed cloud feeling. It’s nice when someone else is on pager duty for you 🙂

 




How Bon Jovi Taught Me How to Adapt to the Cloud

When we talk about the shift towards cloud architecture, there are many folks who get worried about what we are saying. One thing to note as we have these discussions is that the shift towards cloud has been happening for some time, and will continue to happen. It isn’t an overnight thing, so you shouldn’t imagine that you have to make an overnight change to adapt. However, let’s take a look at some life lessons I’ve learned along the way.

Bon Jovi Taught Me How to Adapt

Everyone has had to endure some kind of change as we have gone through life. Some adapt better than others, and some honestly don’t have to depending on a number of factors. We all know someone who’s dad still has a hairstyle like Elvis, and hasn’t needed to change because they aren’t faced with a requirement to do so.

Let’s take a look at a great example of how adaptation happens gradually over a career. Our example here is New Jersey band, Bon Jovi. Once a part of the massive hair band revolution that took place in the 1980s, they looked the part and fit in well with what was happening at the time.

bon-jovi-early

We almost want to make fun of it when we see it now, but remember that at the time that they were rising to popularity and moving from clubs to arenas, this was what everybody looked like. And in case you didn’t believe it, take a look at this:

creem-magazine

That’s right, they looked just like everybody else.

Why Bon Jovi Chose a Different Path

Bon Jovi did something that we as systems administrators and systems architects need to do. They saw the writing on the wall and they began to adapt their style with a longer term plan to succeed. It isn’t that they abandoned what they were doing, but they faced some adversity over their lack of alignment with the heavier sounding competitors that were living like every year would be 1986.

So as I made a choice not too long ago to dive head first into areas of technology where I was not working with on a daily basis, I had some of what Bon Jovi taught me in mind. For quite some time I had a sort of a dichotomy happening because I was doing significant learning on platforms that I wasn’t getting to use every day. Now many ask why I would do this? Here’s why.

Bridging the Gap

In cycling, we have something that happens regularly. The larger group known as the peloton, rides in a large pack, and at some point a small group of riders make the jump to become what is called an escape group. This group will work extra hard for a short while to make a gap between themselves and the peloton, and then they hope to gradually increase, or maintain that lead.

One of the talents I’ve learned is that even when you can’t make the lead group, you can also make a well timed decision to go solo and bridge the gap. That means that you, and you alone make an incredible effort to ride out of the peloton and latch onto the escape group. This means that you may use massive energy to get there and you may not be the overall winner, but you have the opportunity to be with a group that leads the peloton right to the end of the race.

This is something I do in my every day efforts. I research relentlessly. I try things out that I have limited time to work with. I have a Kanban board that has a backlog that would make most people weep, but I have the same WIP (Work in Progress) limits that anyone else does. The difference is that I choose short sprints to do my work, and I make sure that the things that I am working on are directional and advancing my value as a person, and as an IT resource.

Bon Jovi Bridged the Gap

So here we are many years later, and we can make the references to bands like Bon Jovi because you probably know many songs they’ve done. In fact, you may know songs that they have done in the last few years. Yes, the same band who was touring arenas in 1986 is still doing the same thing today. If you look at how long they were around, they were actually doing bar gigs and small clubs as far back as 1983.

bon-jovi-modern

As you can see by the picture, these are the same people who were there before, but they just have some more age changes, and they have changed their style in small ways to adapt to the changing music ecosystem around them. All those bands who made fun of them for being “mainstream” and for not staying with their single-minded methods of delivering the same musical formula over and over, well, those bands are gone. Some are coming back because they are considered “retro” now, but Bon Jovi have had thriving careers all the way through.

Bon Jovi Taught Me the Cloud is Important

I saw the writing on the wall. Among many people I was getting exposed to I saw Cody Bunch was talking about OpenStack, Nick Weaver was creating vCHS with a team of outliers who were making a path forward where none had been marked. I was witnessing the escape group. But these same people who were escaping the peloton, they were a part of the peloton for many years.

So as former systems administrators, how did these outliers make the choice to take the lead? They were the early adopters. Scott Lowe was telling me about VXLAN and stretched clustering which everyone thought was a hobby. That same crowd that didn’t see it as a “current” requirement, didn’t see the future need. I saw that this meant something

This means something...

This means something…

I was surrounded by the same rock stars of the IT industry who were a part of the crowd just like you and I. This was one of the many “Aha!” moments I had that told me that I needed to prepare.

This Journey Has Just Begun

We are always moving. Our environment is always adapting. Slowly, but surely, we are seeing the shift. It is a tectonic shift that is slow and gradual, but every once in a while it causes a massive disruption. I hope that I can help to give people the inspiration to have that “Aha!” moment that leads them to the next step in their learning path and the next step in their career.

 




Meet Your New Systems Administrator: Paul Issee

We have been evolving our data center operations throughout the years. As we come from centralized to decentralized, from mainframe to distributed, and from physical to virtualized deployments, the one thing that has had to be the most adaptive is the ever valuable Systems Administrator.

So, as we head into the next generation of the SDDC (Software Defined Data Center) and SDN (Software Defined Networking), one of the biggest challenges being faced is understanding how the modern Systems Administrator will be able to adapt to the new paradigm shift in technology. Is there one language to learn? Is there one product to learn?

This is my tongue in cheek view of what the ultimate Systems Administrator looks like based on what we are all hearing.

Meet Paul Isseepaul-issee

Despite the big players talking about SDN like Martin Cassado, Joe Onisick, Brad Hedlund and others, plus the many players in the vendor space who are mentioned with the proposed SDDC evolution, there is one name that we are all hearing about, which is Paul Issee.

When you listen closely, this name comes up in every webinar and every discussion around the advancement of virtualized networking and security. Apparently, Paul Issee will oversee everything. Paul Issee will have an end-to-end view of the entire data center and cloud infrastructure.

Beyond letting our new sysadmin Paul Issee see everything that is going on, apparently Paul Issee has one talent that no other Systems Administrator has been able to have up to this point: implicit trust in persistent application of rules regardless of change to surrounding infrastructure. Wow! This Paul Issee is pretty incredible.

Letting Paul Issee Define Your Operational Security Model

One of the talents that Paul Issee has from what we have been told is that Paul Issee has a new security model that will be able to hold a distributed database of rules that apply to objects in the environment.

Once Paul Issee does all of this magic, you will find that you have now achieved the ultimate goal of having a “Paul Issee Defined Infrastructure”. Paul Issee is also more than just a technology tool. Paul Issee is fully aware of business rules that apply to the technology of an organization.

In other words, the awareness of business rules around access, separation of administration, logical isolation of resources, and much more will be a part of what Paul Issee is managing in the modern data center. Paul Issee is bringing the same evolution to our data center and cloud that DevOps does for our application development environments.

Does Paul Issee Replace Me?

One word answer: NO! What having Paul Issee on your team will do for you is to allow you to get back to the task of creating and managing your physical and virtual resources with less concern about the state of things in your production infrastructure.

Beyond the traditional virtualized networking we are using today, we will begin to build this Paul Issee Defined Network into place which will save us time and worry. This doesn’t replace is at all. If anything, it cements our role in being able to understand and build these environments that map to the business rules that are in place.

paul-issee-defined-network

The one thing that you will learn in practice by putting your tasks in the hands of Paul Issee is that Paul Issee is entirely trustworthy and reliable. All of the work that is done is also logged, and when an issue arises, Paul Issee will have a safe plan to protect infrastructure.

When you move around your virtual resources, Paul Issee will see those moves and account for them with all of the business and security rules that need to apply. Basically, wherever your virtual resource (VM, vApp, Container etc.) goes, Paul Issee goes with it.

What if Paul Issee Fails?

Luckily, the new data center model uses a distributed control plane. What this means is that the knowledge about Paul Issee is spread throughout the physical and virtual environment at various ingress and egress points. All of the content and knowledge from Paul Issee will survive the loss of any portion of the environment using this distributed model. In effect, Paul Issee is always there.  Do you have a Systems Administrator that has a 100% attendance record?

Wait, I See What You Did There

Yes, this is all a play on words to show you that your new Systems Administrator “Paul Issee” is exactly what the name sounds like: policy. Policy-driven infrastructure is going to be the destination that we are striving towards in the coming months and years.

In the same way that orchestration has helped to solidify the standardized approach to doing regular tasks such as server and application builds, we have the next step even beyond that.

evolution-data-center

The move from automation, to stateful orchestration is now one-upped with the ability to have a distributed policy engine that will maintain a view of the environment just in the way that dynamic network routing protocols have been able to do. The difference in what we are seeing with the next generation of data center and cloud environments is the application of security into the policy engine, not just topology.

What’s Next?

This is the ultimate question that we have about what is the product or language that this new data center will speak. It will mean that there will be some programming language required to interact with the system. Will our Systems Administrators need to be developers? No. Will it be necessary to stretch our skills as administrators and architects to fully embrace and leverage these new methods? Yes!

Keep your eyes on the ecosystem, and as products like Cisco ACI and VMware NSX enter more data centers, you will see that other products will line up alongside them with a common methodology: Policy-Driven Infrastructure.