devopsy.kinsta.cloud

Tag: processes

The devopsy.kinsta.cloud Application Performance Management Leadership Links Guide

Businesses today are largely defined by the applications they run. And to stay competitive enterprises must continuously update their software and performance issues must be identified and solved swiftly.

This drive toward more rapid software iterations and enterprise development and IT management efficiency is one of the biggest reasons why more companies have embraced DevOps and continuous integration and deployment pipelines.

But how do enterprises make certain they can continuously deploy and delivery new software apps and features and not inadvertently impact user experience? Precisely how are mistakes and failures, or app performance issues quickly identified and remedied? How are application issues managed so that there aren’t costly outages or development teams aren’t getting texts in the middle of the night for emergency software change requests? This is where application performance management (APM) comes in.

According to the market research firm Markets and Markets, the APM Market is expected to reach nearly $5 billion by 2019, up from $2.72 billion in 2014.

There is a significant intersection between DevOps and application performance management. It’s also essential for application management teams, development teams and operations teams, and needs to be integrated in many DevOps processes. In this devopsy.kinsta.cloud Survival Guide, we provide resources to help you to get the skinny on using application performance management to help more tightly integrate Dev and Ops, find the right APM tools and successfully manage today’s more complex environments with application performance management.

APM Prepares Prep Sportswear for Promising Growth – devopsy.kinsta.cloud

In this story, David Geer looks at how custom sportswear vendor Prep Sportswear is using APM to prepare for growth

14 Tools That Raise Web and App Performance – devopsy.kinsta.cloud

Asaf Yigal lists his 14 Tools That Raise Web and App Performance

Gartner Evaluates APM Tools for DevOps – devopsy.kinsta.cloud

Grab this Gartner report on APM toolsets.

5 Ways APM Can Solve Your DevOps Worries – devopsy.kinsta.cloud

To have tight control over Devop’s environments we need APM at every step, contends this post by IBM’s Payal Chakravarty. APM can help break down the Chinese wall between Dev and Ops and eliminate the finger pointing that happens during outages. Here he lists five APM best practices to enable a smooth DevOps working environment.

Continuous Monitoring: The Role of DevOps and APM – devopsy.kinsta.cloud

IBM’s Arun Biligiri discusses the intersection of DevOps and APM.

APM On-Premises or SaaS: What’s the Best Fit? – devopsy.kinsta.cloud

Which APM deployment option makes most sense for your organization? There‘s no simple answer to this question. A lot depends on your environment and requirements. This post explores the points to consider in deciding between SaaS and on-premises monitoring.

Webinar: Using APM to Turbocharge Continuous Integration – devopsy.kinsta.cloud

Check out this Webinar with CA Technologies and CloudBees to learn how APM can Turbocharge CI.

Can Your DevOps and APM Initiatives Increase Customer Loyalty?

Can APM help to increase customer loyalty, CA’s Peter Waterhouse thinks so.

— George V. Hulme

April 14, 2017
Security @ the Speed of DevOps Survey: Efforts Still Lag

Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In devopsy.kinsta.cloud’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

Have a look at our survey and report to see how enterprises are tackling this challenge today.

— George V. Hulme

February 13, 2017
DevOps: State of the Art in 2017, and Why CDOs Should Care
Nine years after the term “DevOps” was coined, the following two questions seem still open:
- What does it stand exactly for? and
- How do we make all this technology work together?
From the perspective of the industrialization of work labor also in the software industry, the answer to the first question appears very clear to me: DevOps is the third (digital) revolution of software and IT services, where CI/CD was equivalent of the second industrial revolution as elaborated in more detail in this article. Chances are high that further transformation can be expected to merge it with the fourth industrial revolution, as stated here: “DevOps will underpin the 4th industrial revolution.” That is also why chief digital officers (CDOs) should be in contact with DevOps teams in their organizations.

Now, I see two important things have happened end of 2016: First, the establishment of DevOps Express, as 14 leading enterprise vendors have recognized the importance of interoperability of their tools for leveraging DevOps stack. The demand for this—the second important thing—has been (in my opinion) totally confirmed by CA’s infographic going viral, which maps a broad selection of tools around the software development life cycle. Adding the lifecycle view has been definitely an improvement beyond an overview of tools as proposed in the Periodic Table from XebiaLabs. Still, we are not done. Let me explain why.

The next challenge I see is there is yet no agreement within the community what is—or could be—a reference DevOps toolchain (meta) model or process (meta) model. Is it:
- “Plan, Develop, Test, Release, Operate,” as suggested by CA, or maybe
- “Plan, Create, Verify, Package, Release, Configure, Monitor,” (Wikipedia) or
- “Requirements, Development, Build, Testing, Deployment, Execution” (Len Bass et al.)?
Source: Wikipedia, DevOps toolchain

In the seminal book, “Continuous Delivery,” this life cycle was suggested as “Commit stage, automated acceptance testing, automated capacity testing, manual testing, release.” While we talk so much about culture in DevOps, we should recognize the need to align on a high-level view on the DevOps life cycle that is well-understood and accepted by most stakeholders.

To have a track of all this and attract other collaborators, I have created an open format (SVG) infographic and published it as a GitHub project. Dear colleagues at the DevOps Express consortium, this is your call! Let’s join forces and accomplish this together.

Next Steps

After we will have (I hope so) a community-accepted DevOps meta-model toolchain setup and all important tools in place on the ecosystem, many more interesting questions will appear:
- Which of these DevOps tools leverage open APIs to reduce risk of vendor lock-in?
- Which tools belong to which generation of systems, leveraging optimization of human labor?
Why DevOps is also CDO’s Business

The fourth industrial revolution builds on digital process data, right? So if we aggregate all that data spread across and produced by the DevOps tools, we could get useful and holistic analytics and insights about IT in much faster time than we can imagine today.

About the Author / Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, like IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations. Connect with him on LinkedIn.
February 7, 2017
To DevOps Or Not To DevOps

Although enterprises today all claim to be software companies, there remain four distinct groups of organizations: the technology leaders, the technology followers, the technology hopefuls and the technology laggards.

The first group are the industry leaders who are paving the way. These are the organizations coming up with new technologies, processes and cultural shifts. They write articles and books and present at conferences, and despite perhaps working at smaller companies, they are the names you may recognize. These are the companies the rest of us aspire to be—the Googles, the Amazons and the Microsofts that keep the rest of the industry hanging on to every word.

The technology followers typically are smaller organizations that tend to adopt the latest and the greatest technologies. They are the leaders’ first wave of followers who are not afraid to try new things, nor afraid to fail. They have cultures that allow them to experiment and adapt and are given a lot of free time to invest in learning and implementation, after they watch the big guys successfully implement.

However, the first two groups are the minority of software organizations, since not everyone can lead the way, nor can everyone have the luxury of spending a significant portion of their time experimenting with new methods. After all, most of the new technologies do not have a long lifespan. They appear, generate some attention and then disappear. Front-end frameworks provide a great example of this: new ones pop up and exist for a few months before being superseded by other frameworks.

Another example of technology followers is containers—few doubt their usefulness and most of us are convinced they are the best solution. The only question is which cluster orchestration framework to choose. These frameworks are evolving so rapidly, with new ones introduced on a weekly basis, that it’s almost certain most will be defunct within a year. So, if you are into experimenting with the latest offerings, chances are you could make a wrong choice. Will it be Kubernetes? Docker Swarm? Mesosphere Marathon? Rancher OS? Cloud Foundry’s Diego? CoreOS Fleet? The question is not whether to adopt one of those tools, but rather, which one has the best shelf life.

Most of us fall under the third group, the technology hopefuls. We don’t have the ability to lead the way, nor do we have the luxury to explore the latest and greatest technologies. Yet, we cannot allow ourselves to become obsolete. The industry is moving so fast that just a few years can leave you at the back of the pack where no effort or investment can get you back in the game.

The technology laggards are the software companies that have fallen behind. This group includes businesses that are struggling to remain intact and run the risk of disappearing. These are the organizations that do not innovate, do not adapt, do not invest (enough) in improvements and do not even understand the current industry trends. They are the organizations that do not comprehend that becoming obsolete doesn’t take decades, but years—sometimes even months.

Based on the definitions of these groups, chances are, unless you are Google or Microsoft, you are not in the first or even second groups. By reading this article you are making the effort to be informed so you don’t lack the self-awareness that places you in the fourth group. Like most software organizations, you fall into the third group of technology hopefuls.

As part of this group, you have to balance between the latest and the greatest technologies and the chance of becoming obsolete. You cannot try every new solution that comes along, nor you can let years pass by until you jump on the train. The big questions you have to ask are, How can I distinguish what will stay and what will disappear? How do I make a choice between what to adopt and what to ignore?

There may not be a one-size-fits-all answer, but one process you absolutely cannot ignore is DevOps. If you’re asking yourself whether your organization should adopt DevOps, the answer is a resounding “yes.” And I encourage you to adopt it now, before you are replaced by other companies that are already living and breathing DevOps. Otherwise, you’ll be unable to adapt to the speed needed to keep up in today’s market and understand the cloud and scale accordingly when an avalanche of users come to your site after a successful marketing campaign. Lacking preparedness could cost you your business, especially in a competitive market.

DevOps is here to stay, evolving similarly to Agile by providing value and answering many of today’s challenges. The only problem is that adopting DevOps can be difficult. To implement DevOps, you might have to change your company’s culture; you might need to adopt new tools; you might need to change processes; and, you might need to change your software architecture. Changing any of those aspects is hard, but changing all of them is very hard.

Your culture and company structure need to be agile (in the literal meaning of the word). The old, monolithic tools need to be replaced with smaller, much more dynamic ones that will work well with the ever-changing nature of cloud infrastructure. Processes need to be automated, since there is no time to pause for manual intervention. To accommodate the needs of automation and frequent deployments, your applications and services will need to be relatively small for continuous delivery or deployment to become a standard process. Your teams need to be highly specialized and fully capable of working on all aspects of the software development life cycle, from requirements to post-production support.

It’s a harsh and challenging road ahead, but at the end of it lies success. You’ll experience faster time to market, greater reliability, high availability and faster adaptability to market changes. Some are already there, while others already embarked on the journey. Don’t be left out—the alternative will leave you obsolete.

To DevOps or not to DevOps is not the question. For most organizations, adopting DevOps is the answer.

About the Author / Viktor Farcic

Viktor Farcic is a Senior Consultant at CloudBees, a member of the Docker Captains group, and books author. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .Net suffix), C, C++, Perl, Python,ASP.Net, Visual Basic, C#, JavaScript, Java, Scala, etc. His big passions are Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD). He published “The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices,” and “Test-Driven Java Development.” He is currently working on his third book, “The DevOps 2.1 Toolkit: Docker Swarm.” Connect with him on Twitter.

November 1, 2016
Continuous Integration vs. Continuous Delivery: There’s an Important Difference

If you read DevOps blogs today, it can be easy to assume that Continuous Integration (CI) and Continuous Delivery (CD) are synonymous terms. People often use them that way. But that’s a mistake.

As an example of conflation of the terms CI and CD, take this page, which purports to be a “history of CI/CD tools.” The author does provide a truly excellent history of CI platforms.

But CI tools are the only subject that the page discusses. It’s not a history of CI and CD. It’s just a history of CI platforms. To work the history of CD into the picture would require discussion of how software testing and delivery practices have changed over time, not just an overview of the history of CI software over the past several years.

I don’t mean to knock the page. It’s a great read, and the mistake the author makes in treating CI and CD as synonymous is hardly rare. He or she is just repeating a common confusion. You see the same lack of distinction between CI and CD on Docker’s discussion of CI/CD, for instance.

The Difference between CI and CD

It’s unclear how this conflation of the two terms originated. But it’s easy enough to clear up.

Simply put, CI is the process of integrating code into a mainline code base. In almost all scenarios today, CI is done using platforms designed specifically for the purpose. Implementing CI is, therefore, as simple as using the right tools.

CD is more complicated. CD is about the processes that have to happen after code is integrated for app changes to be delivered to users. Those processes involving testing, staging and deploying code. There is no single type of tool that does all these things. These processes take different forms, depending on the culture of the team and the type of app it is creating.

In actuality, then, CI and CD share little in common. Besides starting with the same word (“continuous”) and being different stages in modern software delivery pipelines, they don’t have much to do with one another.

Why the Difference Matters

Why is it important to steer clear of this confusion? The main reason is because, by conflating CI with CD, organizations can end up doing only the former but thinking they have implemented the latter.

Setting up a CI server such as Jenkins or Bamboo to integrate code changes continuously does not mean you are doing CD. It just means you are using a CI server.

To get to CD, you also have to organize your software testing, staging and deployment processes in a way that automates them as much as possible and makes them continuous. Doing so requires more than simply turning on a certain type of tool.

How you actually do CD is fodder for a separate, much longer article (or you could just read the book about it). But recognizing that CI is not CD, and avoiding confusing formulations including CI/CD, is a start.

— Chris Tozzi

October 20, 2016
A DevOps Checklist for Traditional Service Providers

As companies such as Amazon and Google rapidly innovate to deliver new services, traditional service providers recognize that change is necessary to keep up with shifting customer expectations. Given the pace at which technology continues to morph, creating better, faster and more innovative solutions is a necessity, and if this isn’t achieved, even longtime customers will eventually look elsewhere.

For younger businesses, taking a collaborative approach to IT and product development often comes naturally as it’s built into the company’s DNA. However, for more established service providers, adapting to this new way of doing business can prove challenging. Traditional service providers have spent years perfecting their technology and require multiple layers of review prior to rollout. While these checks and balances are in place to ensure a level of quality customers have relied on for years and expect to receive from traditional providers, it also can hinder their ability to react quickly to client demands. However, the adoption of the principles embedded in DevOps can allow traditional service providers to work more like a startup by accessing their technology and human skills in a new way, while also continuing to deliver products which meet the expectations of their established customers.

Now the question is, how can traditional services providers successfully implement this DevOps approach? While it can (and has been) done successfully, there are five critical steps that need to be taken into account:

1) Establish a clear goal. The most important step is the first: Management must have a clear understanding of what they are looking to accomplish with the DevOps transition. Service providers have a long legacy of well-defined, reliable services, so all changes must complement their current product offerings and live up to the quality their customer base has come to expect. If an overall goal is not defined, customers will be left confused and disappointed, and ultimately, there will be no impact on the bottom line.

2) Set a timeline. While creating an unrealistic timeline is never advised, it is critical to set an aggressive, pragmatic and adjustable one. As mentioned above, without aggressively pushing forward, an organization will find itself continuously playing catch up to its competitors. The timeline is meant to push an initiative forward even when there are setbacks or changes that need to be made along the way. The right timing is a balancing act: too fast and you have a poorly crafted product rollout; too slow and you are stuck behind the competition. The key metric to measure progress is the degree of evolution to the DevOps model within key stakeholder organizations. If solutions are delayed due to existing processes, then either the scope of the team needs to be adjusted to encompass those processes or the goal needs to be changed so they are no longer an issue.

3) Collect necessary resources. Typically, the biggest gap that needs to be filled to move forward is with human resources. For many established companies, having design and architecture skills—core capabilities needed to develop a new product—hasn’t been a priority. Creating the right team that consists of new talent that have these missing skills, along with the addition of current employees who have a more intimate understanding of the company and customer, is a critical aspect in making sure this more collaborative and innovative approach to solution development and delivery works. And it doesn’t stop once the team is created, it is important to continue to foster an environment that encourages the new team to work together and promote their process within the broader organization.

4) Create benchmarks. To ensure the established timeline is being met and that there is an opportunity to change course if necessary, it is important to set clear deliverables at various stages of the process. These benchmarks must look to what people are doing today, not just the end goal. Initial measures should focus on the pace at which progress is being made, and later, focus on the end products being delivered.

5) Get the entire company on board. Changing an embedded philosophy isn’t easy, especially one that has worked well for so long. No matter the organization there is almost always resistance on some level when fundamental changes are being made. It is up to leadership and the DevOps team(s) to demonstrate internally and externally that the changes being made are not just for the sake of change, but in the end will benefit the entire company, as well as the customer.

While taking a deeper look at an organization’s “people, process, technology and information” and moving to a new mindset doesn’t happen overnight or come without its hiccups, the status quo is no longer sufficient to compete. The reality is, a more collaborative and faster delivery model is necessary to be successful in tomorrow’s marketplace.

About the Author / Tim Pearson

Tim Pearson is the director of product line management at Ciena. In his role, Tim leverages DevOps practices to break barriers in network delivery to meet the demands of mobile, VR and video applications. Driven by challenge and fueled by deep industry knowledge, he has built a reputation for developing innovative business and product strategies to drive growth and open new markets. Tim holds a Bachelor degree in Electrical Engineering from Memorial University, a Masters degree in Management Science from the University of Waterloo and an MBA from the MIT Sloan School of Management. Connect with him on LinkedIn and Twitter.

October 19, 2016