devopsy.kinsta.cloud

Tag: shadowOps

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.
July 1, 2015
To Be or Not to Be – Shadow IT

Is it being an innovator, or demonizing business decisions to use other vehicles, and cry foul?

Sun Tzu, the famous Chinese strategist and philosopher, once said, “If ignorant both of your enemy and yourself, you are certain to be in peril.” These words ring true to the quandary that traditional IT organizations find themselves in today: on one side, hordes of tech-savvy business users are deploying and engaging technology services at an alarming rate, often without any input or validation by the IT team. On the other side, there’s an aging on-premise infrastructure that requires frequent care and stresses the limited resources and budgets of IT staff. In between, sits a group of technology professionals that want to support their users while maintaining the appropriate level of compliance, risk management and security — fondly known as “Traditional IT”.

Security teams, a part of traditional IT organizations, have begun demonizing any non-sanctioned technology use – dubbing it “Shadow IT – taking a somewhat close-minded view as to how software and services are being procured and utilized in today’s organizations. In the legacy world, IT Security could block or veto projects based on its merit and risk. Business teams had no choice but to work within their constraints, as the security teams controlled the firewalls — the proverbial gates to the kingdom. Nothing entered or left the organization without being blessed through the firewall, which left IT Security in a very advantageous position. Fast-forward to today and we see a drastically different dynamic taking place in organizations: DevOps and business teams are driving buying decisions, or making them without IT approval.

Why is this happening?

If you look at how various teams are structured in most organizations it becomes obvious. IT departments, a legacy construct best suited for organizations with few technology-savvy users, are best suited with a role as a service provider. Meaning, they build infrastructure, deploy software and services, and operate utilities as a service to their user base. This could be users in the form of bankers, call center employees, or even software engineers. There is no minimum or maximum level of technology expertise required on behalf of the user, because the IT department is there to offer support and guidance as necessary. This is very much a “thou shall not use technology not provided by IT” point-of-view, because IT is ultimately responsible for the support and user experience of said technology.

However, IT departments are fundamentally based around annual budget cycles and 3 to 5 year amortizations of capital expenditures (servers, network equipment, etc.). As the quality and variety of software, hardware and SaaS solutions has increased ten-fold over previous decades, we have quickly entered a buyer’s world where multiple satisfactory solutions can be obtained quickly. This is counter to the traditional IT pattern of planning purchases in advance, leaving ample time for procurement haggling. In as little as a year, entire service providers can spring up with scalable, resilient, superior technology solutions — often affectionately referred to as disruptors. These disruptive technology companies move fast, gather feedback from their customers, improve their product/service and deliver new products. If you just spent a million dollars on servers that you plan on keeping for the next three years, it is nearly impossible to justify leveraging a fleet of cloud servers as an alternative just a few months later. The cloud servers could be the right solution for your business — but the pain of wasted capital is too great for most organizations to shake, much less the implied defeat or mistake in judgment by IT management.

DevOps teams, on the other hand – and much to the chagrin of IT and InfoSec teams, thrive in the chaos of moving quickly and breaking from tradition. This is not done maliciously, but rather out of necessity to reach a peculiar and demanding audience. Years of “buy it now” instant gratification have conditioned the end-user to expect fast, high-quality and competitively priced products. This holds true for the Internet generation now responsible for the buying decisions of everything from inexpensive productivity tools to enterprise-grade communications solutions. Decisions are not made solely on who can deliver the highest SLA or who had the best benchmark score. Agile teams now look for the best product fit, defined by a set of conditions ranging from automation integrations to direction and vision of the vendor. This wide range of criteria falls well outside the traditional IT buying spectrum, and thumbs its nose at the legacy buying practices. DevOps teams buy subscriptions to services that they can change or cancel at any time. They procure products that don’t even have user interfaces beyond an API and JSON output. They buy based on “what can we do with this” rather than “what can this do for me”, which is reminiscent of maker culture.

A new breed of tools that enable the DevOps teams to do great things while catering to the IT Security team has emerged. DevOps teams tend not to budget for security, and are often too fast moving to build all the requisite capabilities themselves. IT Security is desperate for a place at the table to ensure the safety and security of organizations and its users. This sets the stage for new, emerging technology companies to capitalize on the widening gap that has occurred as the industry shifts from the traditional datacenter model to one of private, hybrid and public clouds. This means no more 3-5 year investments in a security technology and no 3-5 year guaranteed relationship for security vendors. Emerging companies also have to raise their game to meet the needs of these organizations and prove to be the partner of choice. The uptake to date has been slower as the industry has been slow to detect and understand this shift. Many organizations have legacy investments and don’t want to bring additional complexity to their lives by adding new panes of glass. DevOps teams may directly integrate raw data feeds from new products into their toolkit, but IT teams need solid integrations to existing infrastructure to make the best use of these new products. Without this, they can’t keep pace with the rapid deployments and changes made by DevOps teams, and are left nearly blind to the dynamism of their infrastructure risk and security posture.

So what is the solution?

It’s simple. By integrating security more deeply into the DevOps toolchain, and operationalizing security practices the same way we operationalize infrastructure and code issues. This means there is a space to not only bring cloud-centric data down to the legacy investments through connectors and integrations, but also an opportunity for IT Security to enable DevOps by automating common security practices. If the practices and behaviors of Security teams were operating at or beyond the pace at which DevOps teams deploy, then a collaborative environment can be built with security detection, notifications, and even mitigations act as a “safety net” in agile environments. This makes a lot of sense when you realize that the biggest threat to these agile organizations is not malicious hackers or state-sponsored attacks, but rather human error, policy failure, lack of transparency into security practices, and lack of consistency over time.

About the Author/Tim Prendergast

With well over two decades of experience pushing the limits of technology, Tim set out to create the first “next-generation” security company, Evident.io, focused solely on programmatic infrastructures (cloud). Tim co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level.

Tim’s prior experience includes leading technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee. He holds over 15 years of security experience; 8 years of AWS security experience, with 3 of them defending the Adobe AWS infrastructure from inception to production as an AWS Certified Solutions Architect.

Connect with Tim: LinkedIN | Twitter | Evident.io

February 25, 2015
Eliminating ShadowOps

If you were like me, you thought that cloud and compute virtualization technologies were transforming the data center, but they are nothing compared to what is coming our way. The IT landscape evolution is accelerating with the advent of application containers, network and storage virtualization, big data, and integrated and hyper-converged infrastructures, to name just a few. IT and business unit roles for infrastructure and application support and management are also changing; driving the need for solutions that are not found in the traditional IT playbook.

The competitive online marketplace is placing increasing pressure on businesses to deliver services and application updates faster to market. While the increased focus today is on the applications themselves, the reality is that they are dependent on infrastructure in order to be delivered to the end user or customer. The inflexibility of traditional IT operations to deliver needed infrastructure impedes development teams from meeting that need for speed in service delivery, causing a disparity between ITOps and development teams.

The availability of infrastructure resources from cloud service providers today is viewed by application/service owners and development teams as a faster and more flexible way to get infrastructure for application and service delivery. When the business units and development teams begin to circumvent traditional IT operations to get the agility they require to meet their rapidly evolving needs, it creates what I call ShadowOps.

ShadowOps is characterized by the clandestine proliferation of outsourced infrastructures and services, which further impedes the relationship between IT and development operations and creates risk, affecting everything from governance and compliance, to business continuity disaster recovery, service quality and more.

Understanding ShadowOps

The infrastructure that application/service owners and developers require to run their applications is supported and managed by IT Operations. The business’ perception is that IT operations is a barrier. They are too slow and inflexible. This causes the businesses to seek outside infrastructure and thus a ShadowOps strategy is born.

ITOps has an enormous responsibility to meet certain requirements, such as regulatory or security audits, while also making sure there are disaster recovery and business continuity plans and systems in place; essentially planning for everything and anything that may happen.

Developers, on the other hand, live in the business unit and often have no baseline understanding of what IT Ops goes through on a daily basis, or how their procedures and needs are impacted by their operations.

While developers can typically deliver multiple releases per day, mostly unfettered as they traverse testing, development, QA and pre-production, once they enter the production environment, IT Operations is often unsuspecting of new or changed application behavior and underlying infrastructure requirements and are often left scrambling to deliver what new and changed applications need.

This causes the impacted developers to begin to look for infrastructure solutions that can give them the ease and speed they crave. So they go to Rackspace, or Amazon, or Microsoft Azure and simply buy the infrastructure they need to support their application and pay for it on a monthly basis.

When developers and application owners begin to outsource infrastructure, often with little regard for risk, they tend to overlook things like compliance requirements, audits, and the fact that a simple change can significantly impact IT operations.

IT Operations is burdened with certain regulatory demands and company policies, which makes them “slow” in the eyes of the application owners. External infrastructures are extremely appealing to application support and DevOps teams because of the pace at which cloud service providers can provision and deliver what is needed.

IT Operations is also saddled with legacy monitor systems, which requires a huge manual effort. Not only are there separate tools for monitoring storage, database, network and middleware, now with ShadowOps, there are separate infrastructures altogether and IT Ops has extremely limited insight into or control over external resources. They often don’t even know they exist until someone calls into the help desk unable to get to their application or unable to process a transaction. This is when things start to get out of control.

The Allure and Consequence of ShadowOps

ShadowOps is alluring to the developer for a few reasons: better time-to-value, time-to-market, agility, speed, responsiveness, which are all good things until they begin to impact availability or increase risk with no disaster recover or business continuity or audit ability on the part of IT operations. When developers purchase cloud service provider offerings rather than working through IT channels you have to deal with multiple providers – project management suffers, costs get out of control and you don’t get economies of scale.

So if each business unit, or development team goes this route independently, you have to ask yourself: Are they meeting business continuity requirements? Do they have redundancy in place? Are they backing up on a regular basis? Are they logging everything required? Are they controlling which administrators have access to certain systems? And finally, will it pass an audit, and how will the provider give access?

The consequence of a ShadowOps environment is not only multiple providers, but also the lack of a point person to negotiate response rates and SLAs that will meet the needs of their business unit, so when there is a security issue, there is no one to respond in a time frame to enables its resolution.

Unify, Automate, and Empower IT

So how do you eliminate ShadowOps and give developers the agility they need while also empowering IT?

It begins with enabling developers from central IT for better coordination, with better tools that address the needs of the changing IT landscape.

Providing IT operations with a unified, automated performance and availability monitoring tool, with a single UI and single datastore, along with event management for your entire infrastructure wherever it’s deployed is a big step towards overcoming the hurdles that lead to ShadowOps.

With a unified model that is automatically built and updated you’ll always be able to monitor the most accurate view of your entire IT environment, contain costs, promote shared resources and allow different units to make better purchases that meet evolving business demands.

A key symptom of a ShadowOps environment is an inflexible IT Ops organization, where it controls everything in-house with a strict menu of services and SLAs that developers are forced to deal with to meet their requirements. By leveraging a unified monitoring solution, you can empower IT to adapt and relinquish some of that control and facilitate a common ground with developers where IT acts as an enabler rather than an enforcer.

If the business unit wants to use an outside provider, IT operations can help them choose the right one, assign a project lead, help them set it up and make it work with the right controls.

IT is then free to be consultative with the business and development teams, guiding them to make better purchases and have more control of their environment, potentially combining multiple business units’ needs with a particular provider that specializes in the infrastructures they actually need.

IT operations, along with X-as-a-service (infrastructure, platform, software, etc.), allows greater flexibility to support rapid prototype and delivery. It allows IT to be a technology enabler for development teams, rather than forcing them to rely solely on their existing infrastructure and inevitably seek out ShadowOps.

For more on how you can eliminate ShadowOps by leveraging a unified monitoring tool to make IT Ops more agile and meet the evolving needs of your development teams, read our full report on aligning ITOps and DevOps here.

December 8, 2014