Schlagwort: 8217

Infrastructure software is dead. Long live infrastructure software.

The post Infrastructure software is dead. Long live infrastructure software. appeared first on Mirantis | The Pure Play OpenStack Company.
Mirantis Co-Founder and CMO Boris Renski recently stirred discussion with his blog post that infrastructure software is dead. At this year’s OpenStack Days Silicon Valley, he sat down with Battery Ventures Technology Fellow Adrian Cockcroft to talk about the changing paradigms in software and in delivery models, and the results were not what you might think.
In general, there are two different methods for deploying software.  Traditionally, in the pre-cloud paradigm, software is deployed as a monolithic package.  You deploy it, and 6 months, or 12 months, or 7 years later, when a new version comes out, you basically throw it out and start again, hoping your data and processes will still be compatible with the new version.
But those days are over, Boris argued in his blog post.  They simply aren&8217;t sustainable. Things move too fast; improvements are available for months or years before you can take advantage of them under this model.  So what do you do instead?
That question was on the mind of most of the audience for Boris and Adrian&8217;s discussion.
OpenStack and the old way
In the early days of Mirantis, Boris explained, the company used the pre-cloud paradigm, where the product is packaged as a whole, delivered, and then periodically updated. They quickly learned — and as anyone who has attempted to upgrade OpenStack knows — this isn’t feasible for OpenStack, which itself uses the Infrastructure as Code (IaC) model.
What&8217;s more, as cloud technology proliferates, the shift in paradigm away from traditional, pre-cloud views has become less about software and more about the delivery model.
So what do you do?
You abstract. Boris clarified this shift in paradigm with AWS as an example. AWS users aren’t provided the infrastructure software but rather an API to the interface. That way, AWS can change whatever it needs to in the infrastructure software without disrupting clients and users.
But it&8217;s more than that, Adrian explains. People initially want something that works without change — until they need a new feature. Such project-based thought was built on the fact that coding is expensive and slow, which is why bundling a package periodically was the norm. Now, with procuring hardware and downloading software from places like Github taking minutes, the purchasing and deployment cycle has collapsed. A deployment can take seconds simply by firing up a Docker container.
Basically, the entire reason for bundling has gone away.
Taking advantage of the new software paradigm
To adapt, the software community has learned to break everything into microservices that can deploy independently, resulting in lots of versions of things constantly changing.
But … doesn’t that break a lot then? Of course, Boris explained, but because you end up with a series of very small steps, it’s actually easier to detect problems and roll back to the previous version. As programmers will recognize, this is the same process used to debug, one step at a time, and it allows continuous change.
This process also solves the issues that arise regarding operations when updates need to be made. Previously, you’d have to wonder if you needed to bring all or part of your system down to make the updates. With containerized OpenStack services, you could upgrade each one independently.
And don’t forget the security benefits of updating in place.
Exploits of exposed software are proliferating, and as Adrian says, people are still downloading the same old vulnerable applications. He advised building around good source components that you can verify with services like JFrog Xray and use security scanners (Docker has one) to check your products.
Looking at the future
There are still a lot of issues that need solutions, of course.
Adrian pointed out that managing a multi-vendor dependency tree is a complex problem with no good fix. “You have to figure out how to keep everything going while trying to change everything,” he explained.
The goal is to keep the “northbound” components, that is, the APIs and so on, that developers want to use, evolving, but remember that the “southbound,” or hardware-facing components, act as constraints. This problem requires collaboration and partnerships to support these devices and to work out ways to get all the versions of hardware and software to work together.
Missed this year&8217;s OpenStack Days Silicon Valley? You can see the whole panel. Just head on over to the OpenStack Days Silicon Valley 2016 videos page and scroll down to “Infrastructure Software Is Dead…Or Is It?”
The post Infrastructure software is dead. Long live infrastructure software. appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

Six reasons OpenStack fails (Hint: it’s not the technology)

The post Six reasons OpenStack fails (Hint: it’s not the technology) appeared first on Mirantis | The Pure Play OpenStack Company.
We know OpenStack is hard. But why?
Earlier this month, Christian Carrasco gave a keynote address at the OpenStack Days Silicon Valley conference, discussing six factors behind OpenStack evaluation and deployment failure — and how to solve those problems. As Cloud Advisor at Tapjoy, Carrasco is architecting a 550-million-user cloud based on both private and public resources. He also has a history as CTO of a private cloud hardware company and two other startups focused on cloud technologies, so he brought a lot of insight into the causes of failure, pinpointing six primary points of failure.
Lesson 1: Leave the dogma at home
Dogmatic views, or beliefs accepted as fact without doubt, are blinders, he explained, and they can come from a variety of sources, including bad previous experiences with technology. For example, Carrasco’s experience with OpenStack five years earlier had been a negative experience because the platform just wasn’t ready. Fast-forward five years to 2016, and it’s now rock-solid for many applications, including his.
However, if dogma had prevailed, trying OpenStack again might have been out of the running. Keep in mind, though, that rebranding old technology as new, or new technology as old, or even rebranding fake technology as its legitimate counterpart can lead to a poor experience that gets associated with that real technology. (See Lesson 5.)
Lesson 2: Fear, doubt, uncertainty, and doom (aka FUDD) can cause problems
Remember when Linux was first launched? If you do, then you probably also remember the a proliferation of scare tactics. Your world will end if you use Linux! Nothing will work! Licensing is too confusing! Cats and dogs, living together, total chaos!
OpenStack has seen the same kind of FUDD. Every year, independent publications, public entities, and skewed statistical reports predict the death of OpenStack. And yet, OpenStack keeps on keeping on, taking over the private cloud market.
Lesson 3: Find the right distribution
The third reason Carrasco covered was the “You picked the wrong trunk” scenario. The latest version of open source software such as OpenStack is called the “trunk”, a base repository of code. The thing about trunk is that it requires lots of tweaking and the modules aren’t always in tune with each other. Community Linux trunks can have some configurations tweaked but not all, and it still requires a level of expertise, so deploying from trunk is not for less-experienced engineers.
Lesson 4: You are not a full-stack engineer
In today&8217;s world, where personnel often have to fulfill multiple roles, many engineers are being told they have to be &8220;full-stack engineers.&8221;
Carrasco, who has worked the full stack and still says he’s not a full-stack engineer, believes full-stack engineers are myths, and he makes a great argument for his belief. It’s really hard to be a full-stack engineer, he says, because you have to be proficient in every realm of the stack &8212; and it&8217;s not just the software. Just being proficient in software stack is difficult, but when you throw in the hardware side, as well as networking, security, and so on, being an expert in everything is a monumental, if not impossible, task.
Organizations need to be aware of the skillset of the people leading the OpenStack deployment and be sure they&8217;ve got all of their bases covered.
Lesson 5: You thought OpenStack was a better buggy for your horse
OpenStack isn’t necessarily a better buggy, or a cheaper method of doing something, or the open source way of doing something. Carrasco says it’s more of a paradigm shift, a new methodology that is still evolving, in the way data centers operate. And the reality is that sometimes this methodology isn’t ideal for traditional businesses.
Lesson 6: You didn&8217;t have a sufficient team
While the rumotrs that you need dozens of experts to successfully deploy OpenStack is an exaggeration, you&8217;re likely going to have problems if you try to deployed it alone, or with a very small team that isn&8217;t ready to deploy data center technology.
If you need help with your OpenStack deployment, there are plenty of options available for design, architecture, and verification of your stack, from automated tools to semi- and fully-managed services.
Along the same lines, some companies aren’t really ready for OpenStack yet, and it may not be economically feasible for a small company to hire a cloud team, purchase hardware, and rack up costs.
On the other hand, some companies lend themselves well to deployment, such as companies that were born online, are making the move to online, or are ready to stop using buggies and be committed and engaged to moving to the next generation of #cloud computing.
OK, so what do I do about it?
Carrasco offers two major solutions to help prevent OpenStack deployment failure.
The first thing Carrasco asks companies he advises is &8220;Where is your Cloud Officer?&8221; If you’ve made a multi-million dollar investment in your cloud and it’s a side project of some other team in your company, that&8217;s not a recipe for success. “What happens to clouds that become orphaned?” he asks. “They become security risks. They become a headache. Nobody wants to work with them, and they vanish,&8221; he says. There needs to be real ownership for your cloud to succeed, and a Cloud Officer will protect your cloud, prevent vendor lock-in, and bring the cloud in line with the organization’s initiatives.
The second solution he suggested is all about vendors. Despite the open nature and coopetition of OpenStack, according to Carrasco, the status quo consists of both public and private vendors fiercely guarding their territory and coming up with creative ways to lock users into their service or their cloud technology, etc., and few companies are creating ways to enable outside operability.
Carrasco’s ultimate vision for a solution is to adopt what he calls a hyper-converged cloud. In this architecture, you have your cloud and your assets powered by multiple vendors &8212; whoever you want to choose to power your cloud. This structure has an added advantage of opening possibilities for niche providers of services not offered by private or public clouds.
The point is not about technology, but about people being able to own their assets. Carrasco is instituting this concept successfully now at Tapjoy, but for this concept to work, interoperability standards are key. Oh, and to those who’d say it’s late for standards, Carrasco points to market research that shows cloud technology is still a tiny speck on the radar when compared to the market share of other tech industries.
So stop trying to make a better buggy, Carrasco says, and focus on making the next-generation cloud.
You can see the entire speech on the OpenStack Days Silicon Valley website.
The post Six reasons OpenStack fails (Hint: it&8217;s not the technology) appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

Most enterprises tailor hybrid cloud to their specific needs

CIOs, CTOs and all line-of-business leaders looking to gain differentiation and strategic advantage: you’ve come a long way in the last four years when it comes to cloud technology. That&8217;s one of the key takeaways from a new IBM Institute for Business Value report, Tailoring Hybrid Cloud. My co-authors — IBMers Justin Chua, Robert Freese, […]
The post Most enterprises tailor hybrid cloud to their specific needs appeared first on Thoughts On Cloud.
Quelle: Thoughts on Cloud

NetApp + Mirantis: MOS 9.0 Reference Architecture and Fuel Plugin

The post NetApp + Mirantis: MOS 9.0 Reference Architecture and Fuel Plugin appeared first on Mirantis | The Pure Play OpenStack Company.
What happens if you need to integrate NetApp’s leading storage hardware into OpenStack?
Last year, to facilitate deployment of NetApp storage solutions with Mirantis OpenStack 8.0, NetApp created the first release of their Fuel Plugin for ONTAP and E-Series integration. This release also included a comprehensive Reference Architecture, offering guidance and best-practice gleaned from several major Mirantis OpenStack+NetApp customer deployments.
Elaborating on the more-basic instructions offered in the Fuel Plugin Guide, the NetApp Mirantis Unlocked Reference Architecture discussed NetApp ONTAP and E-Series storage solutions in detail, explained configuration options on a feature-by-feature basis, and offered step-by-step instructions for using the plugin, including pre-configuration and post-deployment checkout.
This week, NetApp has released an updated version of their Fuel Plugin for Mirantis OpenStack 9.0 (Mitaka), collaborating with Mirantis to produce a fully-updated version of the NetApp Mirantis Unlocked Reference Architecture. (Both the Fuel Plugin and Reference Architecture can be downloaded from the Mirantis Unlocked NetApp Partner Page at http://mirantis.com/partners/netapp/).
The new document makes it easier for deployment engineers and architects to integrate NetApp Clustered Data ONTAP/ONTAP 9 or E-Series storage solutions with a Mirantis OpenStack 9.0 cloud.
New NetApp Plugin Features for MOS 9.0
Mirantis OpenStack 9.0 supports several new NetApp features:

Consistency Groups, enabling snapshots of multiple Cinder volumes to be taken at the same instant in time, ensuring consistency
CHAP Authentication, for communication between iSCSI initiators and targets
Quality of Service (QoS) based on maximum I/O per GB, in addition to QoS based on maximum bytes per second, bytes per second allowed per GiB, and IOPS
Manila (File-Share Service) support is not supported out-of-the-box in Mirantis OpenStack 9.0, but the Mirantis Services division, assisted by the OpenStack@NetApp team, can enable NetApp clustered Data ONTAP storage for Manila at customer request.
SolidFire support can also be enabled separately; refer to the SolidFire Partner page for more information.

To take advantage of these new features, among many others in the Mitaka release (further stabilized and hardened by Mirantis, the #1 bug fixer for OpenStack Mitaka) NetApp and Mirantis recommend using the latest version of Mirantis OpenStack (MOS 9.0, Mitaka) and the latest NetApp Fuel plugin.
Where to go from here
Of course there’s much more than we can tell you in a single blog post! The following resources will help get you started:

Mirantis Unlocked Partner page for NetApp
Reference Architecture for MOS 9.0 with NetApp storage
MOS 9.0 Fuel Plugin for NetApp (.rpm) and Installation Guide
OpenStack@NetApp Deployment and Operations Guide
Discuss NetApp and Mirantis OpenStack at theOpenStack@NetApp Community
Technical Support is available from NetApp Technical Support or Mirantis Support.

The post NetApp + Mirantis: MOS 9.0 Reference Architecture and Fuel Plugin appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

Six DevOps myths and the realities behind them

The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
At OpenStack Days Silicon Valley 2016, Puppet Founder and CEO Luke Kanies dispelled the six most common misconceptions he’s encountered that prevent organizations from adopting and benefiting from DevOps.

Over a five-year period, Puppet conducted market research of 25,000 people that shows the adoption of DevOps is critical to building a great software company. Unfortunately, however, many companies find that the costs of the cultural change are too high. The result is that these firms often fail to become great software companies — sometimes because even though they try to adopt the DevOps lifestyle, they do it in a such way that the change in a way doesn’t have enough real value because the changes don’t go deep enough.

You see, all companies are becoming software companies, Kanies explained, and surveys have shown that success requires optimization of end-to-end software production. Organizations that move past barriers to change and go from the old processes to the new way of using DevOps tools and practices will be able to make the people on their team happy, spend more time on creating value rather than on rework, and deliver software faster.

Key points in the 2016 State of DevOps Report survey show that high-performing teams deploy 200 times more frequently than average teams, with over #2,500 times shorter lead times, so the time between idea and production is minimal. Additionally, these teams see failure rates that are #3 times lower than their non-DevOps counterparts, and they recover 24 times faster. The five-year span of the survey has also shown that the distance between top performers and average performers is growing.

In other words, the cost of not adopting DevOps processes is also growing.

Despite these benefits, however, for every reason to adopt DevOps, there are plenty of myths and cultural obstacles that hold organizations back.
Myth #1: There&8217;s no direct value to DevOps
The first myth Kanies discussed is that there’s no direct customer or business value for adopting DevOps practices. After all, how much good does it do customers to have teams deploying 200 times more frequently?

Quite a lot, as it happens. DevOps allows faster delivery of more reliable products and optimizes processes, which results in developing software faster. That means responding to customer problems more quickly, as well as drastically slashing time to market for new ideas and products. This increased velocity means more value for your business.
Myth 2: There&8217;s no ROI for DevOps in the legacy world
The second myth, that there’s no return on investment in applying DevOps to legacy applications, is based on the idea that DevOps is only useful for new technology. The problem with this view, Kanies says, is that the majority of the world still runs in legacy environments, effectively ruling out most of the existing IT ecosystem.

There are really good reasons not to ignore this reality when planning your DevOps initiatives. The process of DevOps doesn’t have to be all-or-nothing; you can make small changes to your process and make a significant difference, removing manual steps, and slow, painful, and error-prone processes.

What&8217;s more, in many cases, you can’t predict where returns will be seen, so there’s value in working across the entire organization. Kanies points out that it makes no sense to only utilize DevOps for the new, shiny stuff that no one is really using yet and neglect the production applications that users care about &8212; thus leaving them operating slowly and poorly.
Myth 3: Only unicorns can wield DevOps
Myth number three is that DevOps only works with “unicorn” companies and not traditional enterprise. Traditional companies want assurances that DevOps solutions and benefits work for their very traditional needs, and not just for new, from-scratch companies.

Kanies points out that DevOps is the new normal, and no matter where organizations are in the maturity cycle, they need to be able to figure out how to optimize the entire end-to-end software production, in order to gain the benefits of DevOps: reduced time to market, lower mean time to recovery, and higher levels of employee engagement.
Myth #4: You don&8217;t have enough time or people
The fourth myth is that improvement via DevOps requires spare time and people the organization doesn’t have. Two concepts at the root of this myth are the realities that no matter what you do, software must be delivered faster and more often and that costs must be maintained or decreased, and organizations don’t see how to do this &8212; especially if they take time to retool to a new methodology.

But DevOps is about time reclamation. First, it automates many tasks that computers can accomplish faster and more reliably and an overworked IT engineer. That much is obvious.  

But there&8217;s a second, less obvious way that DevOps enables you to reclaim time and money. Studies have shown that on average, SREs, sysadmins, and so on get interrupted every fifteen minutes &8212; and that it takes about thirty minutes to fully recover from an interruption. This means many people have no time to spend hours on a single, hard problem because they constantly get interrupted. Recognizing this problem and removing the interruptions can free up time for more value-added activity and free up needed capacity in the organization.
Myth #5: DevOps doesn&8217;t fit with regulations and compliance
Myth number five comes from companies subject to regulation and compliance who believe this precludes adoption of DevOps. However, with better software, faster recovery, faster deployments, and lower error rates, you can automate compliance as well. Organizations can integrate all of the elements of software development with auditing, security, and compliance to deliver higher value, and in fact, if these aren’t all done at once, companies are more than likely to experience a failure of some sort.
Myth #6: You don&8217;t really need it
Kanies says he hasn’t heard the sixth myth often, but once in a while, a company concludes it doesn’t have any problems that adopting DevOps would fix. But DevOps is really about being good at getting better, moving faster, and eliminating the more frustrating parts of the work, he explains.

The benefits of adopting DevOps are clear from Kanies’ points and from the data presented by the survey. As he says, the choice is really about whether to invest in change or to let your competitors do it first. Because the top performers are pulling ahead faster and faster, Kanies says, and “organizations don’t have a lot of time to make a choice.”

You can hear the entire talk on the OpenStack Days Silicon Valley site.The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis