I can’t show you the really cool Overview screen yet, but here’s the one that replaces the one we’ve demo’ed before. The nodes are grouped by switch and ordered by port so it creates a very nice “rack” layout if your wiring is organized.
Props to Jon Roberts (@emptyflask) for his excellent UI work!
I wrote this responding to Lauren Carlson‘s (Software Advice) Blog Post. Lauren – I’d be more likely to agree with the statement that “SLAs are dead” Here’s why…
<soapbox>
Recent industry buzz about cloud service level agreements (SLAs) and reliability miss the core point about cloud. Cloud is about agility, business models, consumerization of software and merciless pursuit of efficiency.
The fact that Amazon EC2 built its base without an “enterprise” SLA is exhibit #1 that the IT world changed and it’s not going back.
Here are my reasons why IT pandoras can’t get cloud back into the box.
#1. Cloud has vastly superior network connectivity
The concept of your users accessing your applications from inside your firewall is so 2005. Today’s reality is that significant amounts of network access is externally routed means that applications need to live where they have excellent bandwidth to their users and to other applications.
#2. Cloud has elastic consumption of resources
Cloud is not less expensive infrastructure, it is mainly more flexible. If you’re worried about an outage, then cloud is exactly the investment for you because you position a backup site at another location without having to pay for online resources. It’s much harder to take down a site that invests the time to design a system that dynamically reallocates load between sites.
#3. Cloud drives more robust architecture
The fact that cloud delivery is more opaque and modular without a five 9s SLA has driven a cloud application architecture revolution (see CAP). We have shifted the app paradigm from robust scale up hardware to robust scale out software. Also significant, DevOps innovations have made deployments repeatable and adaptable.
The only “logical” argument for pulling applications back from the cloud is to assert control over more of the delivery chain for your application. It the same reason that we think that driving is safer than flying – we’re the ones sitting behind the wheel when we drive. News flash – driving is NOT safer than flying.
Cloud applications are not about hardware infrastructure, they are about SOFTWARE. Perhaps one of the greatest disservices foisted on the market was saying cloud is synonymous with “Infrastructure as a Service” and “Virtualization.” Cloud applications are powerful because we created ways that circumvent the limitations of IaaS and VMs!
</soapbox>
As promised, here’s the other drop in advance of our OpenStack team’s Crowbar release.
This is the second part of the Swift and Nova recipes that we are intentionally leaking out to the community.
USAGE NOTE: These recipes are designed to work with Crowbar! They are not intended to stand alone.
As part of our collaboration with Opscode, Matt Ray, has been merging our recipes into his most excellent OpenStack cookbook tree. If you want to see our unmerged recipes, we’re also posting those to our github.
In addition to our Swift recipes, you can now check out the Nova recipes.
ADDITIONAL USAGE NOTE: The Matt’s tree is more complete – these are released for reference only. They will ultimately be maintained as part of the Crowbar.
<service bulletin> Server virtualization is not cloud: it is a commonly used technology that creates convenient resource partitions for cloud operations and infrastructure as a service providers. </service bulletin>
OpenStack claims support for nearly every virtualization platform on the market. While the basics of “what is virtualization” are common across all platforms, there are important variances in how these platforms are deployed. It is important to understand these variances to make informed choices about virtualization platforms.
Your virtualization model choice will have deep implications on your server/networking choice, deployment methodology and operations infrastructure.
My focus is on architecture not specific hypervisors so I’m generalizing to just three to make the each architecture description more concrete:
Of course, there are many more hypervisors and many different ways to deploy the three I’m referencing.
This picture shows all three options as a single system. In practice, only operators wishing to avoid exposure to RESTful recreational activities would implement multiple virtualization architectures in a single system. Let’s explore the three options:
OS + Hypervisor (KVM) architecture deploys the hypervisor a free standing application on top of an operating system (OS). In this model, the service provider manages the OS and the hypervisor independently. This means that the OS needs to be maintained, but is also allows the OS to be enhanced to better manage the cloud or add other functions (share storage). Because they are least restricted, free standing hypervisors lead the virtualization innovation wave.
Bare Metal Hypervisor (XenServer) architecture integrates the hypervisor and the OS as a single unit. In this model, the service provider manages the hypervisor as a single unit. This makes it easier to support and maintain the hypervisor because the platform can be tightly controlled; however, it limits the operator’s ability to extend or multi-purpose the server. In this model, operators may add agents directly to the individual hypervisor but would not make changes to the underlying OS or resource allocation.
Clustered Hypervisor (ESX + vCenter) architecture integrates multiple servers into a single hypervisor pool. In this model, the service provider does not manage the individual hypervisor; instead, they operate the environment through the cluster supervisor. This makes it easier to perform resource balancing and fault tolerance within the domain of the cluster; however, the operator must rely on the supervisor because directly managing the system creates a multi-master problem. Lack of direct management improves supportability at the cost of flexibility. Scale is also a challenge for clustered hypervisors because their span of control is limited to practical resource boundaries: this means that large clouds add complexity as they deal with multiple clusters.
Clearly, choosing a virtualization architecture is difficult with significant trade-offs that must be considered. It would be easy to get lost in the technical weeds except that the ultimate choice seems to be more stylistic.
Ultimately, the choice of virtualization approach comes down to your capability to manage and support cloud operations. The Hypervisor+OS approach maximum flexibility and minimum cost but requires an investment to build a level competence. Generally, this choice pervades an overall approach to embrace open cloud operations. Selecting more controlled models for virtualization reduces risk for operations and allows operators to leverage (at a price, of course) their vendor’s core competencies and mature software delivery timelines.
While all of these choices are seeing strong adoption in the general market, I have been looking at the OpenStack community in particular. In that community, the primary architectural choice is an agent per host instead of clusters. KVM is favored for development and is the hypervisor of NASA’s Nova implementation. XenServer has strong support from both Citrix and Rackspace.
Choice is good: know thyself.
Our OpenStack team here at Dell has been busy getting Crowbar ready to open source and that does not leave much time for blog posts. We’re putting on a new UI, modularizing with barclamps and creating network options for Nova Cactus.
However, I wanted to take a minute to update the community about Swift and Nova recipes that we are intenionally leaking out to the community in advance of the larger Crowbar code drop.
As part of our collaboration with Opscode, Matt Ray, has been merging our recipes into his most excellent OpenStack cookbook tree. If you want to see our unmerged recipes, we’re also posting those to our github. So far, we have the Swift recipes available (thanks to Andi Abes!) with Nova to follow soon.
5/31 Update: These are now online.
Greg Althaus (@glathaus) and I will be leading a discussion about OpenStack at the May CTLUG on 5/19 at 7pm. The location is Mangia Pizza on Burnet and Duval (In the strip mall where Taco Deli is).
We’ll talk about how OpenStack works, where we see it going, and what Dell is doing to participate in the community.
OpenStack should be very interesting to the CTLUG because of the technologies being used AND way that the community is engaged in helping craft the software.
I’m not going to post OpenStack full conference summary because I spent more time talking 1 on 1 with partners and customers than participating in sessions. Other members of the Dell team (@galthaus) did spend more time (I’ll see if he’ll post his notes).
I did lead an IPv6 unconference and those notes are below.
Overall, my observations from the conference are:
While IPv6 deserves more coverage here, I thought it would be worthwhile to at least preserve my notes/tweets from the IPv6 unconference discussion (To IP or not to IPv6? That will be the question.) at the OpenStack Design Summit.
NOTE: My tweets for this topic are notes, not my own experience/opinions
We had a hallway conversation after the unconference about what would force the switch. In a character, it’s $.
Votes for IPv6 during the keynote (tweet: I’d like to hear from audience here if that’s important to them. RT to vote). Retweeters:
Brad Szollose’s Liquid Leadership piqued my interest in the idea that gaming teaches critical job skills for the information age. This is a significant paradigm shift in how we learn, share and collaborate to solve problems together.
At first, I thought “games = skillz” was nonsense until I looked more carefully at what my kids are doing in games.
When my kids are gaming they are doing things that adults would classify as serious work:
They seek out these challenges because they are interesting, social and fun.
Is playing collaborative Portal 2 (which totally rocks) with my 13 year old worse than a nice game of chess? I think it may be better! We worked side-by-side on puzzles, enjoyed victories together, and left with a shared experience.
On the flip side, I’ve observed that it takes my kids a while to “come back down” after they play games. They seem more likely to be impatient, rude and argumentative immediately after playing. This effect definitely varies depending on the game.
I don’t pretend that all games and gaming has medicinal benefits; rather that we need to rethink how we look at games. This is the main theme from McGonigal’s Reality is Broken (link below). I’m just at the beginning and my virtual high lighter is running out of ink! Here are some of her observations that she supports with research and data:
If you’re interested in discussing this more, then please read one of the books listed below and choose another in the field.
Please feel free to post additional suggestions for titles as comments!
If you’re interested, let me know by commenting to tweeting – I’ll post our meeting times here in the future.
Note: I do not consider myself to be a “gamer.” Although I greatly enjoy games, my play is irregular. I suspect this is because I can achieve flow from my normal daily activities (programming, writing, running).
Mascot history in earlier post.
This version is has no bits from external sources.
Want to install? Bring it!
In software, the 80/20 rule is a harsh reality. It has two equally distressing parts:
Part 1 should be a good thing – 80% of what you build will help all your customers. Unfortunately, “unique” means that 20% of what you invest in will only help a fraction of your audience. No problem you say?
How do you know WHICH 20% is the unique part and which is the 80% common part?
Not knowing the 80 from the 20 is where Part 2 is particularly unkind. Since you spend the majority of your investment on features for a narrow audience, you’d better get that pick your top features wisely.
The cold reality is that is that it’s not obvious which features are included in the 80% and which are in the 20%. If you want to build a successful product, you need a way to pick the right features.
At most 50% of the features for a product are obvious in advance.
Let me explain using my last “next big thing” as an example. I’m built a mobile sandwich application called sAndroidwich™. Here are my product manager’s 10 features (in rank order):
It’s pretty obvious that we’d identified BLT as our core market because everyone loves bacon, but what about the next 5 features? Our product manager has 25 years of experience consuming sandwiches and swears that he knows this market inside and out. Will these features put me into the top 3 social food apps? You bet! Call up Y Combinator, we’re going to IPO!
My potential feature list should have looked more like this:
That’s 16 features even though I only have time for 10! In addition to simply listing more features, I’ve also added market segments. It’s important to remember that 80/20 rule also applies to features by market so features for 1 market may not help (or even hurt) sales in an adjacent market.
The challenge to picking features is that 50% of them are common to all users and their use is obvious while 30% of them are common to all users but you can’t distinguish them from the unique features. I consider these to be “nonobvious common.” You should take the time to list 160% of your potential features if you hope to find the real 80%.
To figure out the 30% nonobvious common features, you must accept that your own experience and bias clouds your judgment.
If you make the assumption that you can predict which of the features in the 80% and which are 20% then you will be wrong about 50% of your feature set! If you accept that the second 50% of your features can only be discovered by customer interactions then you’re open to discovering the hidden 30% of common features.
Discovering this hidden 30% is critical to success because they are your market differentiation!
If you can find the hidden 30% then your competitor is probably handing you the golden goose. In most cases, they are waiting while their engineering team is building the wrong features or focusing their 80% effort on the less critical 20% features. This behavior ultimately causes feature fan out – which will have to wait for a future post.
BTW: sAndroidwich™ never made it into the top 10 apps – my team’s bias toward tuna and hummus (omega 3s AND delicious) meant that we missed the super-hot Beef and Jack market. If only we’d shipped the BLT features (using Lean) then market tested and added incrementally, we may have been able to adjust before iSubpad and Po’Berry got all the users.
Rob Hirschfeld 