Use Wufoo integrations and get your data to your favorite apps.
Beth Kindig is the Founder of CitizenTekk.

Tag: OpenStack

There are 2 posts tagged as OpenStack.

10 Mistakes to Avoid in Planning for OpenStack Cloud

Build your own cloud? With free open source? Too good to be true?  Not quite. 


OpenStack provides you with the opportunity to make resources available to your people by creating your own cloud without paying huge software license fees — that’s true.  But in the years we at Mirantis have been building and deploying production of OpenStack cloud environments , we’ve seen a lot of magical thinking. If you watch out for these ten common mistakes, you’ll be moving in the right direction.



Mistake #10: It’s open source. Who needs a budget?


Very often we hear, “Why do we need a budget for this? We’ll just implement the code off the repo. There’s no license fee.”


That last bit is true. There’s no license fee to run OpenStack, but open source software doesn’t just appear out of nowhere, especially for a project as large and complex as OpenStack. Hundreds of people get paid to work very hard to improve the code, which changes constantly, so the latest version of one component requires you to bring in the latest version of everything else.


The problem here is that the latest code is always unstable, and critical bug fixes happen at the speed of the community, not yours. Sometimes you’re going to need to pay someone to fix your bugs in your timeframe and not the community’s. Thus, open source code is free at any given moment in time, but there’s always change over time, and time is money.


Mistake #9: I can do it by myself.


If your entire cloud is small enough to fit on your laptop, you might be able to do it yourself.  If you’re looking at a medium or large cloud, however, get some help.  Most people implement clouds for reasons that aren’t simple; you must understand what everyone else needs — not just you — in order to do this right. Explicitly document your use cases so that you can figure out whether you need a public, private, or hybrid cloud. Is your workload multitenant, long-running, short-running, dedicated, ephemeral, stable, bursty, or maybe even all of the above?


Maybe the solution to your problem isn’t even in the cloud. Look at your legacy applications. Do they belong in the cloud, or do they need to continue on your existing infrastructure?


None of these decisions can be made in a vacuum.


Mistake #8: Everyone understands the terminology.


You may believe that everyone understands the terminology, but it is critical to understand the whos, whats, whys, whens, wheres, and hows — collectively. Consider the following sentence we heard in a planning meeting:


We built a service to support the service, but when we had problems with the service level, we called services.


Really?  Take the time to understand what your constituents mean in precise terms, because there is no common understanding — even with common words. There’s a lot of chatter on the OpenStack forums about the actual meaning of the word “type.”


Mistake #7: Assuming legacy systems will go away (or be migrated).


There’s a reason COBOL programmers still have jobs. Legacy applications don’t just go away; that’s just the reality.  Just last week, a hyper-enthusiastic system admin told us, “We’re just going to build a cloud and move everything over.” Maybe it’d work, but not quickly. Some legacy systems, such as certain data storage, transactional, financial, and insurance applications are just not ready to move to cloud, especially if business rules have not been well-documented.


Mistake #6: All you need is load balancing.


This particular fallacy comes from thinking of the cloud as a giant router that just shifts stateless traffic to where it can run the fastest. Think about what workloads you’re moving to the cloud. Is it a dev-test environment? Can you ramp up or ramp down? Can you shut it down in an emergency? Do you need a single component or multiple components? In most cases, you can’t scale an application just by cloning its elements; not all constituent services can maintain consistency across replicas unless they’re architected from the get-go.


Mistake #5: We don’t need to talk to the developers.


In OpenStack cloud, applications can exercise far more control over the platform they run on than in a conventional environment, but with great control comes great responsibility. Operations and developers need to play nice with each other —you need expertise at the developer level to, both, properly architect and operate the solution.


That’s not to say that admins and operators should just get out of the way. You’re building an IaaS cloud with OpenStack so developers can use the infrastructure more easily. You want to give the developers just enough choices to make them successful, so create a menu — don’t give them the run of the kitchen.


Mistake #4: Our staff has the skills.


We often hear, “Our staff has the skills. It’s just like Linux.” Sure, if your organization is endowed with source-code masters for IP networking, hypervisor resource management, storage redundancy and optimization, source-code management, security and encryption, driver optimization, distributed application architectures, and any number of other technologies involved in OpenStack, you may be right.  Chances are, though, you’re missing one or many of these skills, and your staff needs to know that.


Everyone can use Linux, but not everyone’s a kernel engineer. Ultimately you can become the source-code master who knows everything, but it’s not overnight.


Mistake #3: We can monetize later.


“Cloud introduces great efficiencies.  It’ll pay for itself.”  Go ahead and try to get that past the CFO.


More than likely, you’re going to need new hardware and it’s not going to be the light and cheap stuff. And smart people don’t work for nothing. You’re going to need to train the people who don’t know everything they need to know. Oh, and do you also have a vacant, water-cooled data center nearby?


You may also need a new business model. Your existing infrastructure was funded with a set of assumptions about utilization by different functions and business owners – assumptions that likely no longer hold true. Where are your users going to get the money to support the cloud?


Understand your users’ economics and you’ll understand the value of your cloud.


Mistake #2: The cloud fixes itself


A cloud is not auto-magical, but, with the right monitoring and maintenance, it can, indeed, fix itself — sometimes.  But you need to make sure you have the right monitoring and the right redundancy, especially for alerting when capacity thresholds are near. You might not know it’s broken until it doesn’t fix itself; then you’re going to get that 3:00 A.M. call, and you must be prepared.  Remember that engineer who knows everything?  She’s not always going to be available.


Mistake #1: Failure is not an option


Finally, there’s the romantic old-school belief that failure is not an option. In fact, when it comes to cloud, failure isn’t just an option — it’s a core design principle.  Fail often and fail fast, so you can move quickly. Just make sure that your systems and applications are prepared for the moment when something goes down and they have to adjust.


“Automate all the things,” as the saying goes — especially the notification of failure.  This way, you can really enjoy this new technology as your systems keep going even when something doesn’t go quite according to plan. That’s when your organization gets the maximum benefit from the cloud.


Isn’t that why you wanted OpenStack in the first place?


OpenStack's Third Birthday - a Recap with a Look into the Future

OpenStack was first announced three years ago at the OSCON conference in Portland.

I remember the first time I heard about the announcement and how it immediately caught my attention. Ever since that day, I have become a strong advocate for the technology. Looking back, I’ve often wondered why OpenStack earned my loyalty so quickly.


Was it because OpenStack is an open source cloud? Well, partially, but that couldn’t be the main reason for my interest. OpenStack was not the first open source cloud initiative; we had Eucalyptus, then and other open source cloud initiatives before OpenStack emerged.


But these open source cloud initiatives were started by unreliable companies that lacked the commitment for a true open movement. I knew that a real open source cloud movement couldn’t meet its potential as an industry movement if startups led it. I knew that experience in the field gave OpenStack a much better starting point.


I also knew some of the main individuals behind the initiatives and their commitment to the Open Cloud and that made me confident that the OpenStack project would have a much higher chance for success than its predecessors. After three years, the game is essentially over and it’s obvious who’s going to win the open source cloud war. I’m happy to say that I also had my own little share in spreading the word by advocating the OpenStack movement in our own local community which also grew extremely quickly over the past two years.


OpenStack as an Open Movement

Paul Holland, an Executive Program Manager for Cloud at HP, gave an excellent talk during the last OpenStack Summit in which he drew parallels between the founding of the United States and the founding of OpenStack.


Paul also drew an interesting comparison between the role of the common currency on the open market and its OpenStack equivalents: APIs, common language, processes, etc. Today, we take those things for granted, but we cannot imagine what our global economy would look like without the Dollar as a common currency or English as a common language, even if they have not been explicitly chosen as such by all countries.


We often tend to gloss over the details of the Foundation and its governing body, but those details make OpenStack an industry movement.  This movement has brought large companies, like Red Hat, HP, IBM, Rackspace and many others, to collaborate and contribute to a common project as noted in this report. The steadily growing number of individual developers year after year is another strong indication of the real movement that this project has created.


Thinking Beyond Amazon AWS

OpenStack essentially started as the open source alternative to Amazon AWS. Many of the sub-projects often began as Amazon equivalents. Today, we are starting to see projects with a new level of innovation that do not have any AWS equivalent. The most notable ones, IMHO, are the Neutron (network) and BareMetal projects. Both have huge potential to disrupt how we think about cloud infrastructure.


Only on OpenStack

We often tend to compare OpenStack with other clouds on a feature-to-feature basis.


The open source and community adoption nature of OpenStack enables us to do things that are unique to OpenStack and cannot be matched by other clouds, like:

  • Run the same infrastructure on private and public clouds.
  • Work with multiple cloud providers; have more than one OpenStack-compatible cloud provider with which to work.
  • Plug in different HW as cloud platforms for private clouds from different vendors, such as HP, IBM, Dell, Cisco, or use pre-packaged OpenStack distributions, such as the one from Ubuntu, Red Hat, Piston etc.
  • Choose your infrastructure of choice for storage, network etc, assuming that many of the devices come with OpenStack-supported plug-ins.


All this can be done only on OpenStack; not because it is open source, but because the level of OpenStack adoption has made it the de-facto industry standard.


Re-think the Cloud Layers

When the cloud first came into the world, it was common to look at the stack from a three-layer approach: IaaS, PaaS and SaaS.


Typically, when we designed each of the layers, we looked at the other layers as *black-boxes* and often had to create parallel stacks within each layer to manage security, metering, or high availability.


Since OpenStack is an open source infrastructure, we can break the wall between those layers and re-think where we draw the line. When we design our PaaS on OpenStack, there is no reason why we wouldn’t reuse the same security, metering, messaging and provisioning that is used to manage our infrastructure. The result is a much thinner and potentially more efficient foundation across all the layers that is easier to maintain. The new Heat project and Ceilometer in OpenStack are already starting to take steps in this direction and are, therefore, becoming some of the most active projects in the upcoming Havana release of OpenStack.


Looking Into the Future

Personally, I think that the world with OpenStack is healthier and brighter for the entire industry, than a world in which we are dependent on one or two major cloud providers, regardless of how good of a job they may or may not do. There are still many challenges ahead in turning all this into a reality and we are still at the beginning. The good news, though, is that there is a lot of room for contribution and, as I’ve witnessed myself, everyone can help shape this new world that we are creating.


OpenStack Birthday Events

To mark OpenStack’s 3rd Birthday, there will be a variety of birthday celebrations taking place around the world. At the upcoming OSCON event in Portland from July 22-26, OpenStack will host their official birthday party on July 24th. There will also be a celebration in Israel on the 21st, marking the occasion in Tel Aviv.


For more information about the Foundation’s birthday celebrations, visit their website at