devopsy.kinsta.cloud

Tag: service provider

Should You Embrace DevOps in Your Business?
New to some, old hat to many and a source of ambiguity to more than a few, DevOps is being embraced by the IT world as an answer to increase quality of business processes—to innovate faster and to get new products to market sooner in a defined time frame. There is no doubt DevOps has fundamentally changed the way an IT organization works and how it gets things done.

But one may argue what, exactly, does it mean? Is it a process? A methodology? A paradigm? A platform? A technology or a culture? DevOps is not a platform or technology, but a practice that requires internal cultural changes where working together is encouraged to reduce complexity and remove the siloed setup while ensuring the stability of service delivery.

In simpler terms, DevOps is an evolution of agile software development that aims to break down the “wall of confusion” between developers (Dev) and operations (Ops) team to collaborate better so they can deliver frequent changes faster, with higher efficiency and robust quality based on market demands.

Let’s have a look what Gartner has to say:

“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

Once you have a firm grasp of what it is, we can move forward. The critical step is to assess your business environment and processes for DevOps compatibility. The assessment questions could be:
- Are you meeting your project timelines?
- Are your build, deploy and test processes automated?
- Is your development and delivery cost rapidly increasing?
- Do you need more stable operating environments?
- Do you want to improve customer satisfaction through frequent and timely updates, immediate feedback loops and continuous improvement?
- Are you ready to break down the traditional silos across teams and ready to go faster?
If you’ve answered “yes” to any of these questions, then you may want to consider DevOps as a service for your enterprise. But before you consider it, the critical first step is to research your consulting partner. Look for a partner that has a long-term vision and a clear, tightly integrated road map to help your business realize the true benefits of DevOps. So whatever your drivers are for undertaking the initiative, your partner should have the requisite skills and experience to guide you on your journey. Alongside, your partner should offer you a complete range of services. From initial discussions through to delivery and ongoing support.

There’s a lot to be said for DevOps. In a business climate that’s all about speed, quality and delivery, it’s critical that enterprises understand the power of DevOps. It is not a fringe movement; it has now become a key part of enterprise IT planning to stay relevant in the marketplace.

About the Author / Ritesh Gujrati

Ritesh Gujrati is digital marketer at OSSCube, a global solution provider. He frequently talks about disruptive technologies like DevOps, digital transformation, big data, IT modernization, IoT and cloud. He is well-versed with web analytics tools, paid media marketing and has hands-on experience on organic promotion and content marketing. Feel free to contact Ritesh through ritesh.gujrati@osscube.com.
August 8, 2016
The DevOps Devil is in the RFP Details
The request for proposal (RFP) process in IT outsourcing is, at its best, a challenging, time-consuming process rife with pitfalls for both customers and outsourcing providers. The process is made even more complicated if customers are unable to provide clear and detailed requirements because of haste or inexperience in software development outsourcing.

In my work matching companies that need to outsource their software development to international partners, I’ve seen this particular challenge, where less mature customers do not offer potential partners enough of the needed detail in the RFP process for determining an accurate estimate. The question remains, What is the best way to navigate a situation like this?

There are two key considerations at the very start. First, because IT outsourcing can mean several types of services, including help desk, cloud enablement, network monitoring, etc., outsourcing of custom software development is a type of IT outsourcing that has specific best practices for engagement, methodology and process. Second, I recommend dropping the word “vendor” from your lexicon to refer to a company you hire for custom software development; instead, use the term “partner.” In my experience, treating your software outsourcing partner like a vendor inevitably leads to an adversarial relationship that shuts down creativity and innovation. For software development outsourcing to work, it is absolutely critical to maintain good communication between equal partners. A good working relationship cannot be underappreciated as a key element of success.

From the provider perspective, there is no ethical way to respond to an RFP that lacks details with an accurate time estimate and cost quote. Any proposal offered should be for a discovery phase, where the service provider uncovers the details the customer is unable to provide on its own. The customer can use the deliverable from a discovery phase to have a more realistic discussion with multiple service providers and receive credible proposals. If the prospective customer is unwilling to pay for the discovery phase or provide the required details, then the service provider should turn down the opportunity.

From the customer perspective, the answer to the question of how to resolve unclear requirements, then, is to require that the contract governing the relationship be for a dedicated agile development team that can start developing software as the highest priority requirements are defined. The team may grow or shrink over time to accommodate changing priorities, and the release plan can be updated every three or four sprints as you learn more about the requirements and what users want.

The customer should be prepared to commit contractually to providing a dedicated, easily accessible and available product owner to resolve questions and issues quickly. A “local” product owner can also be on the outsourced team to facilitate communication when developing apps with complex software requirements, but he or she should not be considered a replacement for the customer’s product owner.

The provider, then, should be prepared to provide at a minimum:
- Team ramp-up time
- Monthly rates per developer at various levels of seniority
- Historical retention or attrition rates of team members
- References to other customers using similar software technologies and/or domain experiences for what is needed for a particular project
- For customer experienced with agile development, an estimated velocity of story points per sprint
An additional challenge from the client perspective is to be able to define the IT outsourcing speed that is needed for the task at hand. The recent concept of two-speed IT defines two kinds of IT software development—slow and fast. Each kind can be outsourced, but with different types of service providers.

Slow IT outsourcing is most typically used for the careful update of legacy software systems that are changed slowly over months and years to maintain the stability of the business. Fast IT outsourcing is most frequently used for product development and digital transformation and requires an agile approach that includes UX design, user testing, development and DevOps. By recognizing the distinction between fast and slow IT outsourcing speed approaches, you’ll be able to select a partner company with the right experience.

By abiding by a few key parameters, customers and providers alike can make the RFP process a constructive and productive experience. While it’s true that customers always seek the best possible deal in an outsourcing bid, they don’t always offer the information required during the RFP process to help providers meet their needs. An RFP should be viewed as an opportunity to build a relationship, rather than executing a transaction, and a commitment by both customer and provider to trust and transparency will go a long way toward long-term success.

About the Author / Steve Mezak

Steve Mezak is CEO of Accelerance, a Silicon Valley firm that, since 2001, has matched hundreds of U.S. companies needing software development with international, outsourcing partners. Steve has more than 30 years of experience in the IT industry, from writing software code to facilitating and managing software development teams. He’s authored two books, including most recently, “Outsource or Else! How a VP of Software Saved His Company” (June 1, 2016). Contact Steve by email: steve@accelerance.com; or Twitter: @SteveMezak.
August 2, 2016
The 3 Compliance Questions to Ask
As companies move to cloud, they require more certainty around export compliance.

Of the many complexities associated with cloud computing, export compliance laws arguably are some of the thorniest. From a legal and technical perspective, the export compliance laws currently on the books—as they vary from country to country—can make even the savviest and most experienced attorneys’ and engineers’ heads spin.

All enterprises must adhere to a variety of industry- and country-specific rules related to important security, data privacy, taxation and export controls. But these rules become especially murky around cloud services. For example, if a U.S.-based company provisions a virtual machine abroad, say in China, does it need to develop region-specific export controls?

Export compliance rules raise other, broader questions. For example, how do you retain agility while complying with the necessary regulations? And how do those regulations and controls vary according to workload? Like tax regulations, rules for collecting and distributing user data vary depending on location.

Not having the proper compliance protocols in place can have serious implications. Say your client is expanding into a foreign market and, at the last minute, they request a number of changes that have not been evaluated from a compliance perspective. Either the expansion is delayed, which could be damaging from a reputation and financial perspective, or the company runs the risk of being cited for compliance violations.

So, as more and more companies expand globally, how can they prepare to meet the compliance challenges stemming from cloud computing?

Three questions in particular are critical to answer when it comes to cloud export compliance.

Is it possible for companies to be both agile and compliant?

Increased business agility is perhaps the single greatest benefit cloud offers. Cloud computing facilitates rapid provisioning of resources, allowing companies to scale quickly and adapt to changing client and market needs. But what effect does export compliance have on cloud’s speed and flexibility? This type of unprecedented agility requires a re-think of how governance and policy enforcement is managed. Instead of manual checks, companies must transition to real-time policy enforcement and recording that matches the agility of cloud. This is a change to both culture and process—the rocky road where foundations can begin to crumble.

How do compliance rules vary from country to country?

Companies that operate internationally are subject to a number of rules related to citizens’ data protection, taxes, variations relating to workload, region-specific controls, paperwork and registration. When conducting cross-border provisioning, legal counsel is mandatory to establish best practices and to ensure compliance. Unfortunately, because the cloud is a relatively new phenomenon, legal expertise in this area is scant.

Further, even when there is some legal expertise, when it comes to uncertainty, the default answer from legal counsel is often, “No, we can’t do that.” Indeed, when there is a certain amount of risk and haziness around the law, the easiest—and safest—thing for legal counsel to do is to say it can’t be done. But that’s not helpful to a business.

What steps can companies take to prepare for these differing requirements?

There are three essential measures that companies can follow to help ensure their cloud services are compliant with global export regulations.
1. Identify: All software that could be subject to cross-border exports—either packaged software or homegrown code transferred between between countries—requires legal guidance and approval. So the first step is to determine the software being exported.
1. Register: Once you have identified the appropriate software, you need to maintain a registry. Whether an image or an automation routine deploys the software, it’s important that you have a clear record verifying what must be registered.
1. Record: Companies that employ cloud across borders may be required to keep a record of all export transactions. Many businesses make excuses why they don’t properly document these transactions—the virtual machines in question do not belong to them; their cloud software is publicly available; or recording export transactions is only mandatory when exporting to riskier markets such as China, Iran or North Korea. To protect companies from liability or legal action associated with cross-border data transfers, legal counsel often will suggest recording all cross-border software movement.
These steps are critical to the export process, and partnering with a cloud provider that can help clear up export confusion can ease the pain. Some cloud brokers and providers offer applications that track cross-border exports, which can save a number of headaches. They have tagging and metadata reporting systems in place ahead of time. These are necessary for security and privacy compliance anyway, so it can be leveraged across domains.

A good cloud platform provider anticipates a business’s needs and offers services that a company may have never even taken into consideration, such as tracking tools to keep tabs on software so that it can be easily reported. These companies have in-house counsel with expertise in cloud export and tactical, strategic plans (such as the metadata tracking) so you know what software is going where for how long and how often—data that can also help support audits.

Information is power, and the more you have, the more prepared you are to deal with thorny issues such as export compliance. Having a partner to guide you through the process—an experienced cloud platform provider with sound advice—can help arm you with the information you need to get to cloud quickly, safely and securely.

About the Author / Rodrigo Flores

Rodrigo Flores is Managing Director of Product Innovation, Architecture and Management for Accenture Cloud Platform. The Accenture Cloud Platform is a multi-cloud management platform that procures, provisions, orchestrates, manages and governs enterprise cloud resources.
June 10, 2016
Video did not kill the radio star – IT Ops Continues on

The Buggles classic “Video Killed the Radio Star” may have been a hit song, as well as hotly contested idea in the early 80s, but given the retrospect of the last 40 years, we know that video did not kill the radio star – it simply changed him. Just as MTV failed to kill the radio star, DevOps will fail to kill IT Ops.

Today’s dynamic virtualized and cloud-filled world has significantly changed IT. With Software Defined “Everything” and virtualized compute, network, storage, etc., everything is fluid. And to top this off, bandwidth is unlimited and inexpensive; making it easy to offload and move things in ways we couldn’t have dreamed possible just a few years ago. As a result, the infrastructure supporting these technologies is highly distributed, and can no longer be served from one place. All of this is significantly changing the way IT Ops, well, operates. In order to understand how IT Ops has changed, we need to look back at how it was. We don’t need to look back far, however.

Most organizations have individual business units. Be it a large organization with separate businesses, or a smaller one with separate departments, these business units often find themselves competing over shared IT resources. Five years ago, business units vied for the time of shared application developers that lived in IT. Now, with the explosive growth and maturation of rapid delivery application development technologies, and with more and more revenue generated or influenced online, it makes sense, that these business units lobbied to the CIO to bring the app developer and application support functions within their control. Application development has become a critical part of most businesses today..

Once this happened, the distribution of budget also changed, taking full control of the IT budget away from IT Operations. Today, as much as 30% of the IT budget is directed by the individual business units. This happened because the business units were not getting the prioritization they wanted from the shared application developer approach. In the eyes of the business, IT couldn’t move fast enough for them, or didn’t have the same priorities that the business unit had. No one was satisfied. So, the executive teams moved the application development and support budget to the respective business units, partly to stop the bickering.

Some of these business units took their funds and used them to outsource development or to purchase software-as-a-service applications. Once cloud platforms and inexpensive, unlimited bandwidth arrived, the business units had alternatives, and they used them.

This is all logical for business units, but it does not come without risk to the organization. With applications developed, controlled, and delivered outside of the purview of IT Ops, there were concerns about whether these applications would meet HIPAA or PCI compliance standards, IT’s security standards, business continuity guarantees, or back up schedules. A compromise was needed. What most organizations have come up with is to have IT Ops handle the general infrastructure, and allow each business to do what they want with the rest – about 30 percent of the budget. How does this look?

Most apps today are componentized. If you take a retail app for example, the product browsing, the shopping cart, the payment page, and the confirmation and fulfillment are each separate applications. While the underlying infrastructure – how the app is configured, monitored, and supported – needs to be handled by IT Ops, each component lives on its own schedule of updates, and has its own team that maintains and fine tunes these apps to make sure they’re accountable to the business goals. But who, you might ask, comprises the team if not IT Ops?

DevOps: The intersection of Development and Operations

Enter DevOps. DevOps is one of those terms that can mean different things to different people, but in its most simple definition, DevOps is the convergence of development and operations. Forrester analyst Mike Gualtieri hit the nail on the head when he said: “The goal of DevOps to make the process of deploying applications faster and smoother.”

Without “DevOps” all application issues (outages, etc.) will be routed to IT Ops. Because IT Ops is shared, has other priorities, and does not necessarily know the goals of each business unit, this is not the most practical option. Sure, IT Ops are sharp and talented people, but they specialize in maintaining infrastructure – they are not application experts by trade. Some organizations have hundreds of different applications spread among a dozen business units. There is no way that anyone could expect IT Ops to understand the specific needs and behaviors of each of these specific applications.

The application developers know the app best, they know the requirements, and how to diagnose issues. They need a deep solution to trace transactions and end user experience. And, they know best what the app needs in a general sense….how much CPU, how much storage, how much RAM, etc. However, what they don’t have is expertise with VMware vSphere, Cisco UCS, VCE vBlock, FlexPod, IBM hardware, NetApp storage, EMC storage, etc. They are developers. They can manage their application operationally, but what happens when they run into an infrastructure problem? This is where IT Operations comes in.

Gualtieri also said, “DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure.”

This is why the portion of the IT budget that is moving away from IT and into individual business units continues to grow. It’s not necessarily surprising when people start talking about an end to IT Ops, or in some cases, and end to Operations all together (NoOps).

However, despite the fact that organizations are moving away from IT Operations overseeing 100 percent of the budget, to a chunk of it now being managed by individual business units, without IT Ops each unit would control all of their own IT. Imagine unified communications without IT Ops. Do you really want each business unit in charge of that? No, you want economies of scale. You want it to be shared – the network, the bandwidth, the storage – IT Ops will remain to manage all of that.

As Gualtieri noted, “developers and operations need to stick together to best meet the demands of the business.” Recent research drives this point home. A study on the state of DevOps by Puppet Labs found that IT performance strongly correlates with DevOps practices like proactive monitoring, and continuous delivery and integration. In fact, according to the research, DevOps practices can boost IT performance and ultimately improve a business’s bottom line.

IT teams have a more consultative and strategic approach, working in partnership with developers and other users of IT infrastructure to ensure that they all have access to what they need without bottlenecks or barriers to entry. Despite the fact that there appears to be room for both IT Ops and DevOps within organizations, it is clear that a shift is occurring.

IT Ops: Making a move to large service providers

Taking advantage of the latest technology innovation, as well as economies of scale, many organizations are now using service providers instead of owning their own infrastructure. One could say that this is pushing the IT Ops folks out, and they would be correct, but don’t worry they’re not becoming an endangered species. Instead of working for large enterprises, IT Ops professionals are working for the large service providers. They aren’t going away, they’re just moving off site.

The budget will likely continue to go down for IT Ops on premise, but the cost of hosted infrastructure will go up, so the budget for IT Ops will even out. IT Ops is not disappearing, it’s transforming.

In a time when Ops have become trendy and heated debates over terms have garnered the attention of the tech community, it comes as no surprise that the majority of us are left wondering what the future holds. One thing is for certain, be it DevOps, IT Ops, or SecDevOps, there will continue to be places for Ops within organizations.

July 10, 2014