Unix and Mac. Developers are always in combat. My last verbal combat was a “discussions” around ESB and Microservices. They are fun because both supporters tend to have very strong opinions about what they think is best and both want to fight each other. I recently got involved in one of those discussion about ESB vs. Microservices and the ESB guy throw lots of arguments at me. “ESB is magic” got almost burnt into my mind until I started to investigate a bit: “How to fight ESB discussions in combat?”. Here are my top 5 findings that may help in your next verbal ESB combat situation.
Category: Blogs
-
“Show Me The Money!” – Delivering DevOps Value
HM Heath Solutions delivers new business applications in the healthcare industry to 35 million customers. In order to embark on their DevOps journey to improve software delivery, Valerie Scott, their Manager of Shared Services Division, had to show senior management an ROI on a successful project, before they would invest fully. On June 2, Val Scott along with Rick Slade of IBM joined Alan Shimel of DevOps.com in a webcast to discuss this interesting client case study. During their discussion, they illustrated in vivid detail how HM Health Solutions showed success in DevOps to their senior executives, for them to buy in and sponsor the project.
Val and Rick’s webinar parallels many similar discussions I’ve had with senior executives. To net it out, the bottom line is, as it was so clearly and unequivocally articulated in this amusing clip from the movie Jerry Maguire: “Show Me The Money!”
When I meet with senior LOB, Finance or IT executives — they shout a similar refrain:“All I want to do is buy a business outcome. I want to invest in an IT project, and have it pay back. Unfortunately for many application development (or other types of enterprise IT) projects, that pay back is illusory, and ROI difficult to measure.”
— Jane or John Executive, representing nearly every IT executive or CFO I have ever met
Unfortunately, many struggle to quantify, monetize and demonstrate the financial return on investing in IT projects. Yet as described in this blog, it is the primary responsibility and outcome of management; leading the economic performance of their department or unit. Show me the money! Fortunately, many clients experience positive returns, both operationally and economically. Ten (with links to more) client case studies with returns are highlighted in this blog, and summarized on this page.
As you undoubtedly have experienced yourself, senior executives respond to clear business value and benefits articulated as financial returns, as ROI. But how do you do that for DevOps, a set of technical practices and associated culture change? As Val and Rick described during their informative webcast, comparing productivity, time-to-market, speed of delivery, and quality, both before and after a DevOps pilot, are crucial. These operational metrics will be improved by adopting DevOps. However, to win the hearts and minds of senior executives, you have to monetize the results, in other words – show them the money! Technical techniques and practices such as those Val and Rick described to Alan, shifting left, test driven development, and automating application build, deployment, and test are absolutely necessary, but they are insufficient to win the argument with senior executives. The gains they produce are necessary, and impressive. The operational results have been stellar thus far at HM Health Solutions, per Val:
- a 67% reduction in resource demands on the release team & process,
- a 75% reduction in relative hours to repair defects per environment,
- an 82% reduction in application deployment time.
Yet as impressive as these operational results are, they are insufficient. As Val described, arguments about business value, technical value, or improvements to developer or operations staff productivity, alone did not persuade the management. The magic word is an economic and financial one: “investment”. Making a strategic investment to improve delivery speed and quality of business applications was the key to winning the hearts and minds of the senior executives.
In addition to the technical practices described above, Alan asked Val to describe the tools HM Health Solutions adopted. A continuous delivery solution with application release automation software from IBM UrbanCode was implemented, including application build, deploy, and release.
As a way of summarizing the webcast for the audience, Alan asked Rick and Val for their two key takeaways; the two most important messages and things to remember. Rick’s:
- Knowing which metrics are critical to your organization. There are many benefits to adopting DevOps, and many potential hard numbers that are straightforward to capture and measure. Deciding which metrics have the most impact and are most persuasive to your stakeholders is critical to making the case to invest in DevOps.
- Implementing tools and automation: automated testing, and linking that to build and deployment processes and automation.
Val’s: Rick’s two takeaways of course! And one more…
- DevOps is new in the industry, and is not yet well understood or common practice in enterprise IT or among its leaders. Understand your audience, and become good at explaining it in straightforward and clear business and financial terms to senior executives. Especially persuasive are other client proof points, and the results of pilots in your own enterprise IT environment. Make sure pilot results show that the solution works and delivers timely business value, and that the related facts and metrics clearly quantify the results.
Read this blog to know more and Check out other customer proof points/ case studies
This was a very informative, fast paced, and information rich webcast. I hope that you find the replay useful in continuing your DevOps adoption journey.
If you’d like to explore more about management responsibilities and know-how for establishing an ROI for DevOps and app release & deployment automation, see this ROI web page, and read this ROI blog for additional resources on method, approach, making the case, and calculating the ROI. And please don’t hesitate to reach out to me on twitter: @paspung.
I look forward to hearing your success stories in making the ROI case to senior executives, and delivering DevOps value to your organization!
Peter Spung, DevOps Deploy and UrbanCode Integration Executuve, IBM Cloud, @paspung
-
Stop whining about shadow IT and do something about it
Much has been written about shadow IT at the business unit and employee level where the proliferation of cloud applications has all but eliminated IT’s control over what applications are used in their organization. The explosion of public cloud technologies has caused an identical revolt amongst development teams who no longer want to—or need to—wait for IT to spin up the IT infrastructure needed to fuel their development efforts. The reality is public cloud has drastically changed the expectations of developers – even if they aren’t using it.
Gone are the days where development teams are satisfied with putting in a help desk request for a new server and waiting to access it. Developers now expect IT to provide services similar to what they can get from a public cloud provider. And if you can’t provide it? Then you risk them pulling out a credit card and bypassing everything you’ve built. But just as shadow IT can wreak havoc on data security and IT budgets, there’s a whole new set of problems that can arise when shadow IT hits the infrastructure level. So now that the developers’ expectations for immediate resources have been changed irrevocably by public cloud, what can IT do to bridge the gap?
Calling a truce: provide self-service provisioning and management
First and foremost, the obvious one—give developers the immediate access to IT resources that they need to do their jobs. IT needs to leverage its existing investment in virtualization technologies by providing self-service provisioning and virtual machine management capabilities to developers. In other words, get out of the way and give them what they want.
At the minimum, IT should be looking to setup an internal cloud management system which provides IT an on-premises solution with:
- Integration to existing authentication/authorization systems (e.g. Active Directory)
- Quotas to control usage by employee/group
- Chargeback/showback to provide usage tracking and accounting
Giving back control is the best way to ease what can be a tenuous relationship between IT and developers. Developers will be happier because they will be provisioning new servers in minutes rather than days and IT can focus on more interesting challenges.
Abstract away the complexity
Self-service provisioning is only step one. IT needs to get out of the business of provisioning servers and let developers manage their virtual machines themselves. However, that doesn’t mean that IT should leave developers to manage every aspect of their cloud usage on their own. On the contrary, IT’s job should be to create the tools and infrastructure to ensure best practices within your organization and track IT infrastructure resources to avoid unnecessary infrastructure costs.
But how? The first step is using a centralized automation and orchestration technology. I won’t get into the religious battle between the various flavors—Puppet, Chef and Ansible are the three most common that we see and they all have their strengths and weaknesses. However, they all provide the type of framework IT needs to empower self-service provisioning capabilities.
IT should own the base OS images which developers can use for their virtual machines and use an automation framework to provide the means so that developers can easily set up a common set of framework applications (e.g. web servers, databases, monitoring tools, etc.).
IT can also use cloud management tools to effectively track resources. We’ve seen many instances where customers have discovered numerous unused VMs. By tracking resources and enforcing expiration dates on certain resources, IT can deliver infrastructure more cost effectively.
Give users choice
Frankly not all clouds are created equal. And certainly not for all tasks. An internal VMWare virtualization may provide a great cloud—once IT has provided the services mentioned above—for most developer’s needs—but don’t stop there. For example, public clouds, like AWS, Azure, Google, have servers located all around the world. That makes them ideal for web applications which are going to have geographically dispersed users. Most IT shops certainly shouldn’t be trying to duplicate that capability or prevent its usage. Embrace it instead, where appropriate!
That doesn’t mean that IT shouldn’t have visibility and control into that usage. IT should strive to create a system which supports a collection of private and public clouds, has unified chargeback/showback and quotas across ALL of the private and public clouds that IT wants to support.
Abstract Away the Complexity to Support Teams Beyond Developers
These best practices shouldn’t be limited to developers! One of my favorite use cases that I have seen was an IT shop which provided their sales team with the capability to spin up VMs for product demos. They encapsulated the complexity of 10+ product variations and multiple operating system varieties into a single dialog box. When the sales manager wanted to do a demo, they checked a couple of boxes in a dialog box, hit submit and a VM was spun up on their internal VMWare cloud which automatically expired 8 hours later. This was a perfect example of allowing a non-technical user to control of their own virtual machines while IT maintained complete control of the underlying technologies.
Maintain flexibility!
One final word of caution: the world of private and hybrid cloud is changing very rapidly. IT needs to be able to utilize their existing virtualization infrastructure, typically VMware, today while exploring new private cloud options like OpenStack and preparing for the future of containerization and micro-services. It’s important to avoid solutions which are locked into a particular technology—which may leave IT behind in this rapidly changing environment.
There is no doubt that public cloud has led developers to have drastically increased expectations for private IT. By putting in place a cloud management platform backed by DevOps server automation, IT can meet these expectations and stop the growth of shadow IT at the infrastructure level.
About the Author/Jon Mittelhauser
Jon Mittelhauser is the CEO of CloudBolt Software. A 20-year Silicon Valley veteran, Jon Mittelhauser has a proven track record of building highly regarded technology organizations from the ground up and helping to architect pioneering technologies. He is considered one of the founding fathers of the World Wide Web. He was co-author of the first widely-used Web browser, NCSA Mosaic, and was a founding engineer of Netscape Communications Corporation. Mittelhauser was an early investor in Tesla Motors and one of the first Tesla Roadster owner. -
SaaS: Building Tools for the DevOps-Minded
DevOps, Continuous Delivery, Continuous Integration and Continuous Testing are no longer just methodologies and development strategies — they’re all a part of a growing economy within the tech industry.
Great Software-as-a-Service (SaaS) companies such as Chef, Docker and New Relic have done an amazing job of spotting the trends early and building their tools and services around a new wave of development processes. Chef and Docker alone have reportedly raised nearly $250 million, and New Relic went public in 2014.
In fact, this very website is another example of how impactful these new development practices are — as several specialized news outlets have been born out of these revolutionary development strategies. So, not only has the DevOps methodology helped developers create better products, faster; but the process has opened opportunities for technical experts to share their experiences on sites like this, e-books, webinars, conferences and any other way people communicate.
On DevOps.com, you’ll see the best articles on the web discussing how DevOps is defined in different organizations, why Fortune-500 companies are shifting old practices toward CD and the best practices of CI from industry experts.
In the race to be the most DevOps-friendly solution — no matter the niche — hundreds of startups have been founded and funded, which has only enhanced the toolboxes of thousands of developers. You’d be hard-pressed to find a good SaaS company that doesn’t offer integration with Jenkins CI, TeamCity or Chef, and that’s because not only should a SaaS product solve an important problem, but it should have minimum disruption of your current development process.
With all that in mind, Continuous Testing is one of the most exciting spaces in technology today. Continuous Testing is a process that aims to synchronize testing and QA with dev and ops, which ultimately yields better products more quickly.
There are several factors that make Continuous Testing successful in a team’s software development lifecycle — such as open-source collaboration solutions, test automation APIs and tools to track the historic performance of applications .
With the release of Load Impact Version 3.0, the global performance and load testing SaaS company has announced its latest feature that fits right in with the DevOps mindset: Performance trending.
Performance trending allows users to plot runs of the same test over time. That gives companies a clear view into data that locates patterns of performance degradation or improvement in order to easily validate code and infrastructure changes.
In the spirit of Continuous Testing, DevOps, CD and CI — performance trending improves users’ ability to gain both a low-level and high-level view into the performance of their systems. And with the increased number of tests run by DevOps professionals, performance trending yields valuable information for companies concerned with their application performance — which should be everyone.
Between DevOps.com and plenty of great conferences and meetups around the world, it’s safe to say this economy of DevOps-minded tools will only continue to grow in the coming years.
-
DevOps TLV June & July Updates
Ahoy there – so here are a few quick updates from the DevOpsphere in Tel Aviv
Events
DevOps Days Tel Aviv 2015 is officially announced…join us on October 7-8th in sunny Tel Aviv for yet another excellent two days of all things Dev, Ops, culture, psych and more. We’re looking for awesome talks, you can pitch your ideas here, and if you’d like to support the cause, you can find sponsorship information here.
Join us for the first ever StatsCraft conference taking place July 30th at Google Campus Tel Aviv, spearheaded by my own DevOps Days co-organizer (and DevOps.com contributor Nir Cohen) – an event on all things monitoring – with great sessions on Riemann, Graphite, ELK – with hands-on workshops you won’t want to miss.
Meetups
If you missed the June Docker meetup on Docker in Production, you can find the recording here, the slides from the last AngularJS meetup here, and stay tuned for some hot DevOps Israel meetups already in the works.
If you’re in the area and would like to get involved in the community be sure to reach out – @shar1z, would love to hear from you.
-
Managing Open source software components
Building any software need lots of efforts including resources, time, money, etc. It is really a great pleasure when it goes live or gets released. In parallel, there is always a chance that bugs may put the release in a difficult condition even after multiple rounds of testing. Teams can fix bugs related to software features or functionality, but the ones which can hit badly are
- Security vulnerability.
- Licensing risk of open source component.
- Outdated open source component.
The world is moving towards open source in a very fast pace and its growing use in software as components inside the application. Open source components are available free for us, however there could be more risk while using them. A product which is paid and commercial is bound to fix issues and provide adequate support for any vulnerability or security issue and Licensing, But open source software may have a little more of a high risk and its very important to be updated about new releases and available bug fixes.
If open source components are not monitored properly and keep up to date, that may lead the software to become vulnerable.
Above checks needs to be done during the development phase and ruled out any discrepancy related to security or legal. This check can be included as part of build process to make sure it does not pass the fist barrier and caught even before hitting the testing phase. Eventual this can save development and testing effort and their time.
There are tools available which can take care of some/all of verification of open source components in various phases.
This tool can verify the license of the open source component and check its compatibility with various definitions. You can even add your own license definition as per your requirement.
Sonatype Nexus and WhiteSource
These tools will verify the license and keep the component information up to date. They will check for any updates, bug fixes for any vulnerability issues and notify the user. These tools can do component security vulnerability and license analysis with the latest available information.
Security issues would be the last thing any software developer wants. Even small legal or security problems can put your system/software in a dangerous situation. Better to secure software first then fixing it later.
Reference ->
http://www.scmtechblog.net/2015/06/managing-open-source-component.html
http://www.scmtechblog.net/2015/03/maven-repository-tools-comparison.html
-
ElasticBox enhances Container support with new release
ElasticBox announced a new version of their product today that enhances Container support. In yet another example of how important Containers are becoming to today’s software development scene, ElasticBox will now allow you to define microservices as Docker files in containers.
Other enhancements include (from the press release) :
UI Enhancement: Tags now make it easier to sort and find items quickly throughout the product. The rich interface enables IT Ops and Development teams to visually assess the latest status of instances, share and manage boxes, and collaborate easily.
Deployment Policies: New functionality allows policies to be boxes, enabling customers to share virtual infrastructure resources from providers like AWS (Amazon Web Services) without having to expose AWS account specifics. Policies have claims that enable IT Ops to tag virtual machine properties, such as platform, instance type, OS family and more. Like all boxes, these deployment policies are reusable and sharable.
Script Boxes: Script boxes are powerful building blocks that can be shared and reused. Variables and script events are stored here. With the addition of requirements, Script boxes have tags to identify the platform, runtime and infrastructure dependencies of the box. At the time of deployment, the requirements and policy claims can be easily married, so developers can self-service the appropriate infrastructure, and IT Ops has the reassurance that the right infrastructure resources are being consumed.
Automatic Updates: With semantic versioning of boxes, customers can now choose automatic updates for major, minor and patches of instances. This enables rapid, efficient updates at scale for enterprises.
Enhanced Container Support: As more customers experiment and deploy to containers, ElasticBox can now support containers, such as Docker, as a new box type. This enables enterprises to define microservices as Dockerfiles in containers, which then can be linked via bindings. With this enhancement, the lifecycle of application services can be easily managed.
vCloud Air and vCloud Director Support: ElasticBox supports a multitude of private and public cloud infrastructure providers. Enterprises with VMWare’s vCloud Air or vCloud Director workloads can now leverage ElasticBox for complete workload automation. At deploy time, ElasticBox auto provisions vApps, one template per VM, and orchestrates automation.
I had a chance to speak with Carol Carpenter, CEO of ElasticBox on the new release:
Q. Why is this latest release so important?
As DevOps matures, we see that companies seek to not only provision applications faster but reduce inter-dependencies between development, QA, and IT Ops. Kill the cruft in the application cycle.
This latest release of ElasticBox brings deployment policies for DevOps to retain needed control and visibility while enhanced container support delivers more flexibility to application teams.
Q. What’s changed?
Many enterprises have built their application deployment workflows around a handcrafted potpourri of tools and processes. When faced with scale challenges from the business, existing tools are fragile and expensive in terms of failed builds and troubleshooting time. ElasticBox brings an adaptive off-the-shelf management solution so enterprises can spend less time re-tooling and more time shipping code.
Q. What’s next?
ElasticBox is built by developers who want to ship code faster to the cloud, and we’re committed to this mission. We’ll continue to ensure our platform adapts to customers’ evolving environments, regardless of which technologies they choose for their development and operational stack.
More information on the new release can be gleaned from ElasticBox CTO Alberto Arias Maestro’s blog.
DevOps.com is working with ElasticBox on a new DevOps survey right now. You can take the survey and win an Amazon Gift Card or 3dr Drone by taking the survey here.
-
Eight steps to a sustainable DevOps transformation
DevOps is not a standard. It is more a philosophy described by a loose set of concepts and tools, many rooted in the agile methodology and continuous delivery. That often causes confusion about the potential scope of DevOps, and makes it difficult to determine a definitive start and end point for a DevOps initiative. Moreover, DevOps requires significant cultural and organizational change, which can be hard to achieve and sustain.
So now we know what DevOps is, here we propose eight steps to a sustainable DevOps transformation, based on the use of a modified version of the Kotter change framework (1):
“Deliver it faster and less expensively”. The two most common requests from the business—whether it is to deliver digital transformation, find more agile and cost-effective alternatives to internal IT, or other requirements.
IT organizations must become fully aware of the urgency to change in order to stay relevant for the business.
In the context of dev/ops this urgency is measured by release velocity, turnaround time for new features and other metrics. Benchmarking helps here: comparing delivery time results with other equivalent companies using DevOps tools, for example. Any deficiencies can be brought up through a value stream analysis with a TIMWOOD waste analysis.
For successful DevOps transformation, identify a team which is both supportive of the change and able to communicate progress. Include senior IT management from operations and development, plus key stakeholders in DevOps processes.
The DevOps vision for continuous delivery should be aligned with the business vision. It should be broad enough to cover all aspects of DevOps, but sufficiently narrow to guide decisions in the subsequent change process.
Gartner use the term “boundary objects” to denote things that can be “interpreted differently across different communities, but that posses enough common understanding to make them useful mechanisms to communicate with and improve knowledge”.[1] Boundary objects are thus considered a possible way to align on major concepts; the objects are flexible to local requirements, yet robust enough to maintain a common identity across sites. A DevOps/continuous deployment roadmap is also a necessity, encapsulating important themes and their priorities on an approximate timeline. Avoid detailed project plans, on the basis that DevOps should follow an agile approach and is all about continuous improvement.
Should the whole organization adopt DevOps or should DevOps remain limited to those areas in which the need for agility ultimately beats strong process compliance needs, risk mitigation and availability requirements?
There is no definite answer to this, but keep in mind:
- DevOps is a lot about culture. In the long-term it will be difficult to maintain a single organization, built upon two different cultures.
- IT systems are often inter-dependent; simple changes have to be implemented across an array of systems.
Communicate the vision, strategy and roadmap again and again. Moreover, start to live the cultural values of continuous delivery, such as avoiding blame, putting individuals before the process and promoting transparency.
Many aspects of the vision—such as reduced process complexity and a revised understanding of collaboration—should already diffuse into the company culture even if “full” DevOps is not in place yet.
The guiding coalition needs to remove obstacles (such as too many process steps or approvals and rigid system access rights). These potentially limit the ability to experiment with new tools or methods. Indeed, any systems or structures that seriously undermine the vision should be replaced. Likewise, risk taking and nontraditional ideas, activities, and actions should be encouraged.
For successful DevOps deployment and transformation it’s important to deliver visible performance improvements, preferably a couple of pilot projects using established DevOps teams.
When choosing the pilot team, ensure:
- The team can be trusted to manage continuous delivery
- The application is a good fit in terms of architecture and technology
- The DevOps benefits are apparent to the business
Use the credibility derived from successful pilots to change systems, structures and policies that don’t fit the continuous delivery vision.
Have the different teams implement their own “flavors” of DevOps, best suited to their specific environment.
These teams can leverage the experience, processes and tools developed through the pilot, but are not required to do so as long as their implementation fits into the overall continuous delivery vision.
Avoid governance frameworks, which run contrary to the concept of agile.
Articulate the connections between the new behaviors and corporate success with continuous delivery. To do this, you need the right metrics in place, linked to top-level KPIs. At this stage the entire business system has to be adopted to the new culture so that the change becomes part of “business as usual”.
This “institutionalization” also needs to be supported by metrics, incentive schemes and the appropriate style of management.
(1) John P. Kotter, The Heart of Change, 2002
[1] Gartner, How to Scale DevOps Beyond the Pilot Stage, Cameron Haight, 11 March 2015, https://www.gartner.com/doc/3003922/scale-devops-pilot-stage
-
Visualizing and defining requirements comes to DevOps
We have all seen the nice circular diagrams of a DevOps methodology for application lifecycle management (ALM) like the one above. We interject some automation, make the two halves work closer together, get some feedback loops going and go as fast as we can. But lets look at those first two steps in the diagram, the ones labeled consult and design. What and how do we accomplish this? There is a company called iRise that has built a great business by allowing for rapidly visualizing and defining requirements for building applications. It is high time we recognize this as the important piece of the puzzle that it is.
I recently had a chance to meet with some of the executive team of iRise while I was in London for the CD Summit. The premise of iRise is so simple I was thinking to myself, “why hasn’t anyone else thought of this?” If the old adage of crap in is crap out is true, why wouldn’t we take the time to define and plan our software better early on? I know everyone thinks they do, but do they really? Do we quickly visualize to help define the requirements and to help the team buy in and sign off? If it is set up right to begin with, it flows a lot faster later.
Now the folks at Tasktop creators of the Eclipse Mylyn open source tool have teamed with iRise to OEM iRise into the Tasktop Software Lifecycle Integration system. In speaking with Stephen Brickley, EVP of iRise, he thinks this partnership will be a key factor in bringing iRise into the mainstream DevOps tools market.
iRise’s customers, like software departments everywhere are adopting new ways of developing and operating software. New times and new ways don’t mean that you throw out what works though. To me it is a no brainer. If you have a tool that lets you quickly visualize, prototype and communicate to the rest of the team before investing a lot of effort into development, it really has to help. It is the ultimate shift left.
I guess the issue is how quickly can you do this without adding extra steps to the development process. From what I saw of iRise it makes it really easy and fast. Of course I would be interested to hear from anyone who has used iRise or even a similar tool on your own experience. But if it all is as it seems, I would expect iRise to be a welcome addition to the DevOps toolbox.
What do you think? What tool do you use for this now or do you just skip this in planning and initial requirements? We are always on the lookout for new tools to report on at DevOps.com, but ultimately we depend on our readers to tell us what is really useful or not. So let us know.
-
Open source and Samsung take center stage at Red Hat Summit
While much of the DevOps world was focused on DockerCon in San Francisco this week, there was also big news happening on the east coast. While DockerCon was shaking things up with the announcement of the Open Container Project the Red Hat Summit in Boston held its own share of big news and much of it spotlighted the important role of open source.
“Red Hat is really the independent voice of Linux focused entirely on business,” said Rob Enderle, principal analyst with the Enderle Group. “It is also a showcase of how to make money on the platform without taking advantage of anyone in the process and largely remaining true to the core tenets that created Linux in the first place.”
Focus on Open Source
One of the primary core tenets—if not the defining core tenet—of Linux is open source. The shared development and collaborative nature of the operating system as an open source project is its main strength. At the Red Hat Summit open source played an even larger role than normal.
“The company continues to show strong momentum for OpenShift Commons as the re-write of the technology is moving forward showing that the platform-as-a-service (PaaS) battles are alive and well,” explained Al Hilwa, program director of software development research for IDC. “Red Hat also rebranded and updated its FeedHenry platform as it continues to turn it fully into open source and integrate it with OpenShift.”
Samsung Partnership
Aside from the focus on open source, the other big news out of the Red Hat Summit was a new strategic alliance with Samsung. Samsung will push Red Hat’s mobile platform and potentially other software into the enterprise in a more integrated fashion as a function of the new partnership.
The relationship has potential, but according to Enderle there are both positive and negative outcomes possible. “Samsung needs Red Hat far more than Red Hat needs Samsung because Red Hat provided the enterprise brand that Samsung needs to penetrate the space. Samsung is a firm that has never found a platform they didn’t like and have historically been unable to focus on any one of them for extended periods of time,” cautions Enderle. “Red Hat alone won’t be able to fix that and Samsung’s behavior could actually tarnish Red Hat if they aren’t careful.”
Strong Momentum
Hilwa also made another observation about the strength of Red Hat’s business model. “That the company will cruise through the two billion dollar annual revenue barrier sometime this year is all but certain with its posted rates of growth. This is an enormous milestone for the open source world.”
We’ll have to wait and see how the Red Hat / Samsung partnership pans out for either company, but the Red Hat Summit highlighted the strength of Red Hat’s momentum and the unstoppable juggernaut of open source development.