Welcome!

@DevOpsSummit Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Dana Gardner

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Feed Post

DevOps Is the Future of SIAM | @CloudExpo #DevOps #IoT #Microservices

Enterprises that engage in multisourced IT delivery need to re-evaluate their contracts

Enterprises with internally sourced IT operations typically struggle with typical tensions associated with siloed application and infrastructure organizations. They are characterized by finger pointing and an inability to restore operational capabilities under complex conditions that span both application and infrastructure configurations. These tensions often are used to characterize the need for a DevOps movement, which focuses on organizational, process and cultural changes needed to bring about a more fluid IT delivery that embodies higher quality and greater overall agility.

Large- and mid-sized enterprises that have multi-sourced IT environments also struggle with these same tensions, but they are magnified by the fact that IT outsourcing contracts written in the past 15 years barely scratch the surface for how vendors should work together in the face of failures or broad-sweeping changes. At least for in-sourced IT groups it is understood that any impact to business operations could very well be met with severe penalties including job loss. In the case of outsourced IT, as long as the vendor is operating within contractual boundaries and meeting service levels agreements, penalization becomes much more difficult.

Hence, practicing DevOps in multi-sourced IT environments should be a fundamental driver of Service Integration and Management (SIAM) activities. Yet, it seems that the majority of SIAM implementations focus on continuance of traditional tower-based (read siloed) approaches to IT delivery highlighted by managed communications handled through controlled gateways characterized by a loosely-federated group of ticketing systems and limited collaboration across the towers. In other words, the exact opposite of what DevOps prescribes as the cure to limited agility and low-quality delivery within IT.

In a fully-realized DevOps multi-sourced IT environment service levels should encompass responsibilities to participate in “cross-tower” activities oriented toward restoration of services as well as planning and deployment of new services. For example, if Vendor A is responsible for application development and Vendor B is responsible for infrastructure then Vendor B should actively participate in design and planning of the application with Vendor A exactly as would be expected of in-sourced IT departments delivering these same responsibilities.

There is some thinking that as Vendor B starts to deliver infrastructure-as-a-service that continued non-integration of towers will become less problematic. After all, if infrastructure is sourced from Amazon or Microsoft, then it is assumed that these vendors would not be a responsible party in the activities associated with failure or insufficient capacity.

This thinking is flawed in situations where a vendor is providing privately-hosted IaaS as part of an outsourcing agreement unless the expectation is that all responsibility for ensuring availability, security and other –ilities for the application are being pushed left onto Vendor A. Yet, even in this case, Vendor B could not deliver an economical privately-hosted IaaS solution without limiting oversubscription on capacity, which would require that they are an active participant in the capacity requirements in advance of demand.

Moreover, in the case of private IaaS, the enterprise would want some assurances in the face of a failure of the infrastructure, which has occurred to all major IaaS vendors, which would be too high of a risk for an outsourcing vendor to sign up to without pricing the service at a point that would make it an untenable choice.

Physical infrastructure is only one example to be considered as many organizations also multisource database and middleware operations to one vendor, Vendor C, and application delivery to other vendors. Here again, we have seen how Vendor C limits agility of the application delivery by forcing activities to go through the SIAM layer to addressed. For example, the application delivery team may want to create a test environment that would require Vendor C to configure and setup application infrastructure. Since most SIAMs focus more heavily on operations than development and test, these requests are given lower priority, and thus, the process of making the environment available could take weeks instead of hours. This has a dramatic impact on the enterprise’s ability to leverage continuous delivery as a competitive differentiator.

In conclusion, SIAM that is not aligned with DevOps philosophies and continuous delivery as passé before they even get implemented. Enterprises that engage in multisourced IT delivery need to re-evaluate their contracts to ensure that there are identified responsibilities as part of their service levels for working with other vendors to ensure continuous delivery metrics established at the SIAM level. This is going to require a whole new level of collaboration and communications that go far beyond ticket-based systems and that ultimately limit the potential to develop strong multisourced collaborative efforts.

More Stories By JP Morgenthal

JP Morgenthal is a veteran IT solutions executive and Distinguished Engineer with CSC. He has been delivering IT services to business leaders for the past 30 years and is a recognized thought-leader in applying emerging technology for business growth and innovation. JP's strengths center around transformation and modernization leveraging next generation platforms and technologies. He has held technical executive roles in multiple businesses including: CTO, Chief Architect and Founder/CEO. Areas of expertise for JP include strategy, architecture, application development, infrastructure and operations, cloud computing, DevOps, and integration. JP is a published author with four trade publications with his most recent being “Cloud Computing: Assessing the Risks”. JP holds both a Masters and Bachelors of Science in Computer Science from Hofstra University.

@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.