devopsy.kinsta.cloud

Category: Editorial Calendar

Trusting Continuous Delivery
DevOps, continuous delivery and the pipeline for faster software development are fundamentally different from traditional software development. It’s such a different approach and a different culture that it can take some time before Dev and Ops teams embrace and trust it—a necessary step for DevOps to make progress in any organization. By mixing containers and their value proposition into DevOps, this new software creation and deployment paradigm can readily foster that trust.

What Continuous Delivery Brings

DevOps and continuous delivery offer application development using containers, providing the required level of trust to get over that hump and move things forward. According to David N. Blank-Edelman, a DevOps veteran and currently technical evangelist at Apcera, the following container features lead to trust because they answer Dev and Ops concerns:
- Containers are resource-friendly replacements for virtual machines, built to encase the coder’s development environment
- Containers are the complete package format replacement, possessing everything you need to run an app
- Containers create an abstraction that enables development and its results to sit in a host in any of a number of infrastructures including on-premise and inside any of several public cloud providers
- Containers are the fastest means to launch short-lived, purpose-built testing sandboxes as part of a continuous integration process
- Containers are the end result of a build pipeline (artifact-to-workload)
- Containers form the boundary for loosely coupled components as part of a larger app or service. Such is the case, for example, when each part of a microservice-based app lives in its own container
According to Blank-Edelman, the aforementioned features imbue trust because they satisfy the following Dev and Ops queries:
- Is the container allocated to use only the resources it should?
- What resides in that container / workload?
- Where did that container come from? Is it OK from a security, coding and business requirements perspective?
- Where is the container permitted to live and run such as in what cloud, environment, country, and in proximity to other containers technically?
- Can the container communicate with only the things it should such as other containers and any hypervisor or other management resource? “If I move the container to another location, do the answers to these same questions still apply?” asks Blank-Edelman.
Though these questions express concerns in direct and simple language, experienced DevOps engineers who have felt the frustration of building development processes and attendant infrastructure understands these are difficult questions to satisfy. Without modern containerization efforts to sustain DevOps, development and production goals grow further out of reach.

The Importance of Policies

As containers undergird DevOps and continuous delivery, policies support containers. Developers input changes and innovations in code to the continuous delivery pipeline. Developers then respond to the needs of the growing code in a nurturing fashion, fixing errors and enabling new features. This pipeline works when automation, together with each progressive step in the development process, lays a foundation for the next step in a predictable and reliable manner.

“Here’s where it gets tricky: First, not only do you have to be able to answer the trust-related questions for each step, but it is entirely possible (and entirely likely in an enterprise environment) that different people/teams will share control of and input to each step on that path,” says Blank-Edelman. With so much collaborative effort in play juggling all these pieces, policies are necessary to configure these steps, address networking and other elements, and control the component parts of the process ahead of time and everywhere along the way.

Policies that make particularly good container watchdogs include those that set steps in the DevOps/continuous delivery pipeline apart, hemming them in on all sides. “Just like having your papers in order makes for an easier border crossing when you travel abroad, so, too, does having your policies reflect the trust required to move from one step to another,” says Blank-Edelman.
March 28, 2016
How Continuous Delivery Challenges Security

Security and continuous delivery each have implications in their effects on each other. While continuous delivery can demand new security measures, traditional security can slow continuous delivery or simply not address its security needs at all.

Micro Case Study Clarifies Security Conflict

Amrit Williams, now CTO of CloudPassage, shares an experience that exemplifies the challenges continuous delivery poses for security. Williams once worked with one of the largest national HMOs in the United States, which developed and supported a customer healthcare portal to enable customers to access health data and take advantage of other HMO services.

At the time of his service there, the company sought to enhance its portal’s performance to challenge other HMOs in the marketplace that were popular, in part, due to the strength of their portal.

“They wanted to add a bunch of new features and make continual improvements by way of moving from a development model of new releases every six-month period to new site releases and updates every couple of hours or about four times per day,” says Williams. But every time the Ops team would bring up new containers and compute resources to deploy new technologies and application code, success would count on repeated manual changes to firewall rules to appropriately pass data, enabling applications to talk to the portal and its technologies.

“They finally decided to allow the firewall rules to apply to the application at the server level rather than at the underlying network level so that they didn’t have to go changing those rules all the time,” says Williams.

In DevOps, Security Still in First Gear

“Traditionally in the enterprise, security has been about speed only when the company is potentially dealing with a compromise, a policy violation or some other threat to the business,” says Williams. The organization is not used to having to respond quickly with security simply to deliver code. Common security tools were not designed to shift and adapt to automated code development and deployment.

“For example, a lot of times the security teams will rely on endpoint security tools that typically require static IP addressing, which is antithetical to dynamic compute models,” explains Williams. These mammoth resource-hogging security applications ask too much and secure too little if they can even work effectively in DevOps shops at all. When you must stop to adjust these security tools, you may trigger change management processes that can slow the development process even further.

Why Not Fail Fast?

While DevOps makes it easier to isolate and fix coding errors quickly, this doesn’t appear to spill over to security. Fixing errors to make the code work doesn’t mean the code is more secure. These changes could even introduce new security flaws that were not there before.

Securing continuous delivery is about the security team surrounding dynamic processes with protections that keep up with the speed of the continuous delivery pipeline. This can be difficult when these processes are automated, bringing up resources on demand to create and deploy software.

“It is really the deployment and configuration of these environments that can lead to some of the biggest security concerns and not necessarily the code itself,” he says. “It is that aspect of DevOps that security is usually not very familiar with, which can really result in them being left out of the process because they try to apply a rule or a government policy that is again, antithetical to that process.”

Continuous Delivery Security Incidents Challenge Legacy Security

In this case example, Williams shares a particular type of threat that legacy security tools would not prevent in a continuous delivery environment.

“It was 2012, during Christmas and it happened to customers using a region of Amazon‘s public cloud services. Amazon rebooted a bunch of servers, and some of those servers were running local host-based firewall management tools that were reliant on connectivity back to the management consoles as well as a static IP address,” says Williams.

When those systems came back online, neither the agents on the hosts or the tools functioned properly. Amazon and its customers had to work to ensure the agent software on the hosts worked and communicated with the firewall management tools and that customer systems were secure. This was important because of the number of sales Amazon customers had to process securely at the time, which was just a few days before Christmas Eve.

Again, this is an example of the failure of legacy security tools inside an environment that was increasingly adding automation while approaching continuous delivery. The lesson here is that as DevOps and continuous delivery approaches are altogether unique from legacy development, so the security tools that protect these environments need to be new, unique and suited to continuous delivery by design, lest they fail to survive partial outages such the Amazon example.

March 24, 2016
Experts Weigh In on the Evolution of DevOps

DevOps is an ethereal concept. It means different things to different organizations and individuals. It also is going through an evolution, which means that as quickly as we might think we have a grasp on what it is and how to effectively employ it, DevOps has moved on. There’s no way to accurately predict whether DevOps will even still be a thing in another five years, or if it will have faded into oblivion—replaced by the next hot tech or development model. We can, however, take a look at how DevOps has changed in the past year, and what the immediate future holds for it.

It isn’t an easy question to answer because first we have to agree on what DevOps is. Are we talking about DevOps as a culture or business model, or are we referring to the evolution of the tools and applications generally used in a DevOps environment? I reached out to the DevOps community to get some expert insight.

Current State of DevOps

“The technology question is a common one when it comes to DevOps. We are still faced with the problem of a clear definition of DevOps. So what makes this difficult is … I’m squarely in the camp that believes DevOps is more about culture than tools or tech,” explains Andrew Storms, vice president of Security Services at New Context. “That being said, a well-rounded and mature DevOps organization does require a shift in people, processes and technology. A lot of people will likely point to orchestration of infrastructure as the most important DevOps tool. However, I think the bigger driver of orchestration has been virtualization and cloud.”

One of the defining characteristics of DevOps from my perspective—aside from the IT culture aspect—is the fact that we continue to raise the bar for automation. Each new automation tool further streamlines the process and puts a spotlight on the next bottleneck. Eventually, a new solution is developed to automate that as well.

Chef CEO Barry Crist believes that one of the most important evolutions in the world of DevOps in the past year is continuous delivery (CD)—or the process of rapidly developing software and iterating through quick, small-batch releases. “Continuous delivery was previously exclusive to the web innovators like Facebook, Amazon and Google, but over the last year companies have realized it’s a primary key to unleash an organization’s innovation engine. When the whole stack—infrastructure, compliance, security, microservices and apps—are all expressed as code, IT is able to deliver value more quickly.”

DevOps also has introduced more common ground between developers and security/compliance officers. In high-velocity organizations that have embraced DevOps, IT can deal with security threats more quickly by assessing a vulnerability, creating a fix, testing it and deploying it rapidly before damage is done. DevOps is also starting to automate and define compliance. When compliance is defined as code, the software can be managed and tested like any other piece of code in the organization.

The Evolution of DevOps

Storms stresses that the immediate future of DevOps revolves around it becoming more mainstream—the new normal. “We are already seeing the business value of DevOps. Companies are getting code out the door faster and at a more efficient means. Other departments, like those of security, are starting to see the value of DevOps and looking at ways to incorporate key points into their departments,” he says.

Crist sees DevOps as evolving beyond IT itself. “In the next few years, the DevOps tent will expand beyond ‘devs’ and ‘ops’ to include executives and other business units,” he says. “DevOps is really about building high-velocity organizations. Mature DevOps organizations see both innovation and quality increases that drive more profit and shareholder value, as well as advances in security and safety.”

Only time will tell how DevOps will actually adapt and evolve. I tend to agree with Chef’s Crist that the natural evolution is to take the core principles and practices of DevOps and expand them beyond development and beyond IT to streamline all aspects of the organization. I guess the real question is whether or not we’ll still refer to it as “DevOps” at that point.

March 24, 2016
5 Things DevOps is Not

For those who have been embracing and championing DevOps for years, the growing popularity of DevOps is as exciting as landing your first job out of college! Okay, maybe not that exciting, but still really cool. More and more companies of all sizes are embracing DevOps by including the adoption of DevOps practices directly into their fundamental strategies.

On one side, this is giving teams the leverage they have needed all along to either begin their DevOps journey or to increase the maturity of existing DevOps adoptions. On the other side, when DevOps becomes a mandate, some of that grassroots passion can become watered down, as the use of the word becomes increasingly overused or incorrectly used.

DevOps incorporates a new collaborative culture that embraces numerous practices combined together for a continuous software development methodology that places significant emphasis on feedback loops, collaboration and continuous improvement. DevOps requires fundamental cultural changes and includes so many practices that can be overwhelming to those just starting their journey.

Instead of highlighting everything that DevOps is, I thought it would be good to take a step back and highlight what DevOps is not instead.

1. DevOps is not simply combining Development & Operations teams

We’ve all seen this one when the term DevOps comes up. “Let’s combine the Development & Operations team and, voilà!, we now have DevOps.” DevOps combines a set of processes and practices to be adopted throughout the entire delivery pipeline and spans multiple stakeholders. A couple of the key practices within DevOps adoptions include continuous integration (CI) and continuous delivery (CD). Simply combining two teams and calling it DevOps cannot accomplish those practices.

2. DevOps is not a separate team

Setting up a separate DevOps team is another trap many organizations fall into when beginning their DevOps journey. In general, I’m not a fan of the DevOps team as I believe it leads to more silos in the end. I’ve also found the creation of these teams can lead to further confusion when the mission is not clearly defined.

There are some cases where a temporary DevOps team may make sense to help enable the processes and potential tooling that may be needed for adoption, but the key is making it temporary—which is often better in theory than in practice. There are several great blogs out there discussing DevOps teams such as Matthew Skelton’s blog, “What Team Structure is Right for DevOps to Flourish?”

3. DevOps is not a tool

Let me be the first to say I actually love the growing number of tools that enable us to continue maturing our DevOps adoptions, but I’ve noticed the use of one or two tools starts to lead to the perception that DevOps is a tool. How many times have you heard?

“We’re already doing DevOps. We have Chef.”

“We do DevOps. We automatically deploy through Jenkins.”

Keep in mind, I’m a big fan of both Chef and Jenkins, but I think the power of DevOps is drastically underutilized if you’re equating the utilization of a single automation tool to DevOps success. Adopting automation and tooling is, of course, a part of DevOps, but only when combined with end-to-end practices of increased collaboration with continuous integration/continuous delivery, amplified feedback loops and continuous improvement (to name a few)! DevOps is a journey and that journey may start with a tool, but the goal should be to first identify your DevOps strategy and then find a tool or tool chain that meets those goals.

4. DevOps is not a one-size-fits-all strategy

Because there are so many different business drivers and technologies to consider when setting up an overall DevOps adoption strategy as well as identifying your DevOps tool chain, it’s important to apply the same tenets of DevOps to your DevOps strategy. Embrace change, gather metrics, understand feedback, fail fast and correct your course quickly. As an example, if you initially identify a tool that no longer works for your technology or environment, abandon it and move on. Just because you used it on the last project doesn’t make it a silver-bullet fix for the next one. We need to first understand our current strategy and environment, then react accordingly.

5. DevOps is not automation

That one may have caught the eye of a few people, so I’ll clarify: DevOps is not solely automation. Automation is absolutely a huge part of DevOps; however, it is not the only part, and deploying some degree of automation is often used interchangeably with DevOps. I think understanding the key DevOps practices is a great precursor to ensuring DevOps is viewed as more than just automation. Understanding the core DevOps principles is key to understanding the true benefits of DevOps adoption.

There are a lot of things that DevOps is and I think I share a widely spread passion for DevOps. There are also a few things that DevOps isn’t—or isn’t solely. If you’re just starting your DevOps journey or still maturing your existing model, making sure everyone on your team has some basic DevOps education and is aware of the DevOps strategy for your project is key. It will go a long way in helping everyone understand that DevOps is about a lot of things. It’s also not about a lot of things.

The list above isn’t exhaustive and I’m sure you all have a few you’d like to see on the list. I’d love to hear you thoughts and suggestions at @Shelbee_SE.

You also can download and browse through the DevOps for dummies e-book.

About the author/Shelbee Smith-Eigenbrode

Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM Cloud Infrastructure Center of Competency. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.

March 17, 2016
Gartner Evaluates APM Tools for DevOps

In 2009, Gartner analyst Mark Nicolett created the Critical Capabilities report. Over time, this document became paired to individual Magic Quadrant reports, and in 2014, Gartner mandated that Critical Capabilities be paired with each Magic Quadrant. Instead of graphically plotting vendors on a x- and y-axis, this research takes a deeper look at a product and its fit for specific use cases.

So how does this pertain to DevOps?

In its latest “Critical Capabilities of Application Performance Monitoring” research, Gartner notes, “Because of its wide lifecycle purview, the DevOps release team often leverages many of the capabilities found in APM suites.” Since the foundation of DevOps is to foster collaboration among the two, typically disparate teams, modern application performance monitoring (APM) solutions are geared perfectly to help encourage this feedback loop. “When examining the capabilities valued by this buyer, APM tooling is critical when attempting to quickly assess the quality (and effectiveness) of a recent release. Detecting and diagnosing issues must be done quickly, which often requires in-depth data sourced from multiple, integrated tools,” according to Gartner.

“Much of the activity of APM technology is focused on detecting and providing insight into root causes. Identification of the impact on system and application resources is based on existing (or proposed) transaction-level trends,” the report continues. “This capability provides IT operations and DevOps release teams with the ability to tell the (line of business) and application owners the potential impact for any planned changes or continuation of resource consumption trends. Although capacity-planning tools have often filled this role, APM suites increasingly offer predictive analytics capabilities for shorter-term horizons”

Of course, we can’t ignore the key to DevOps success: culture. However, no tool—no matter how good—can foster the right type of culture. John Rakowski, my current colleague and ex-Forrester analyst, wrote a compelling ebook on the intangibles that successful DevOps teams need.

The Critical Capabilities research report provides a comprehensive and technical product analysis ranking APM suites from 15 vendors on critical APM capabilities across five different usage scenarios, including DevOps. The capabilities assessed for each use case included business analysis, service monitoring, anomaly detection, distributed profiling, application debugging and workload planning.

The vendors evaluated were AppDynamics, AppNeta, BMC Software, CA Technologies, Dell, Dynatrace, Hewlett Packard Enterprise, IBM, JenniferSoft, ManageEngine, Microsoft, Nastel Technologies, New Relic, Riverbed Technology and Tinygun.

The report is free of charge and can be downloaded here.

March 10, 2016
Continuous is the Engine that Drives DevOps

It has been stated time and time (and time and time) again that DevOps is primarily a matter of shifting IT culture. The tools and practices that comprise DevOps play a secondary role. But that is only partially true: In reality, the culture shift revolves around continuity, and the applications and tools that fuel continuous delivery drive the DevOps engine.

I alluded to this point in a post in early 2015. I stated, “Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response … or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”

That post last year was a bit tongue in cheek. I have since refined my position, however, and come to the conclusion that the hint of sarcasm was perhaps unwarranted. That continuous continuousness is the crux of the culture shift. It is the thing that separates DevOps from non-DevOps.

On the Continuous Journey

Speaking on the topic of continuous security, Andrew Storms, vice president of Security Services at New Context, explains, “Smaller incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes. Try finding the single change in a monthly release that resulted in an unexpected security hole in your database configuration vs the release with only two changes that was just developed and released in the last few hours. Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection.”

That sentiment extends beyond security to all of IT. When we talk about the culture shift in IT required for DevOps, we are generally talking about breaking down silos and removing the barriers between different teams. The goal of the culture shift is to shed tedious bureaucracy and red tape and empower employees to freely collaborate and cooperate to get things done. In other words, we want to eliminate barriers and roadblocks so productivity can be more continuous.

Assuming the DevOps transformation begins at that level, it creates an environment of continuous collaboration which becomes continuous development. What follows is a natural evolution of continuity. Continuous development becomes continuous delivery, which requires continuous testing and continuous deployments, followed by continuous monitoring, which provides the metrics and feedback that take you back to the beginning of the loop.

All of the “continuous” tools and solutions may seem to be part of the technologies and practices that come after the DevOps culture shift, and to some extent, that is true. However, they are also indispensable and inseparable from that DevOps culture shift because without all of the various gears meshing together smoothly—and continuously—what you’re left with is a more traditional approach to IT where everything comes to a halt.

Is DevOps more of a cultural shift than a collection of tools? Absolutely. That culture shift revolves around continuity, though. Continuousness is the culture shift that drives DevOps.

February 11, 2016
Where will DevOps be in 10 years’ time?

What will the DevOps landscape look like in 10 years’ time? Ten years ago, Agile was seen as new and different. Now it’s part of everyday life of most developers. Will it be the same with DevOps? It’s time to clasp the crystal ball and unravel where the future is headed.

First things first. DevOps is here to stay. The overwhelming trend towards the digitization of services accelerates the need for agility and shorter release cycles with DevOps as an invaluable building brick: think the Uber vehicle booking service, the Airbnb property rental service—even Amazon’s move to take the terrestrial version of Top Gear and launch it as a digital-only, on-demand broadcast service. Services are going digital. And so are companies: banks, retailers, telcos and others are increasingly positioned as software-driven businesses where IT makes the difference.

These organizations will need to develop and deliver compelling, customer-centric apps quicker than ever before. Agile development will become the battle cry of every business. Dev and Operations teams will increasingly need to shake hands in a middle ground of rapid development and reliable, high performance services delivery.

At a technical level, DevOps enablement will be driven by increased public and private cloud adoption: Infrastructure, Platform and Application Service Clouds are all important enablers for DevOps practices. Moreover, DevOps will also grow through the replacement of IT Operations Management tool chains – including automation, monitoring and service management – from non-DevOps to DevOps-enabled and DevOps-ready tools.

If agile is a journey, DevOps can be seen just as another part of it; one, that suits companies, which successfully completed the first phases of agile transformation and are now looking at ways to further enhance their agile maturity levels and accelerate releases. The increased adoption of agile development methodologies and the increase of related maturity levels thus will also fuel growth. Gartner, for example, has indicated that agile development is essential for mobile application development, arguing that the traditional methods used to define and develop desktop applications will not work with mobile application development.

Still not convinced? Then how about this. Research by Computing in the UK shows that 30% of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13% planning to go down this route.

Awareness of existing DevOps success will also fuel this continued growth. Recent research, for example, shows that high-performing IT organizations are deploying code 30 times more frequently with 50% fewer failures using DevOps practices. And demand for DevOps skills is soaring too: DevOps engineers are among the highest paid IT practitioners today, according to APM Digest.

Make no mistake, the software delivery chain will continue to accelerate and change cycles will shrink. In many competitive scenarios, an advantage can only be sustained through organizational agility. In fact, agility can make such a competitive advantage sustainable. Since IT is so important already in the “legacy” enterprise and becomes even more so in the digital economy, existing IT systems and methods will need to move towards agile.

Here’s another thought. I predict that within the next 10 years the split of ‘Mode 1’ and ‘Mode 2’ companies will disappear. Mode 1 is the traditional approach to development, emphasizing scalability, efficiency, safety and accuracy. It’s the blueprint for how IT Operations works. Mode 2 meanwhile is non-sequential, emphasizing agility and speed. And it requires new thinking and processes around issues such as investment management, governance and collaboration.

It will disappear for two reasons. First, distinct cultures and operational modes are not sustainable within the same business. Second, if agility is not a requirement, the service should not be operated within the boundaries of the firm for strategic reasons. Own “mode 1” operator companies should be used to outsource non-differentiated IT services.

In due course, bimodal IT will flourish within organizations, servicing two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Success in both modes demands smarter, more flexible tools that support today’s complex IT operations. Bimodal IT is not without its risks and challenges, but it will be increasingly powerful in helping companies meet ever-growing customer expectations. DevOps will help firms help them bridge these two modes.

Market demand for DevOps skills will continue to grow too in the next 10 years. Research indicates that DevOps engineers are among the highest paid IT practitioners today and aggressive hiring of people with DevOps expertise will continue in the years to follow.

One final, more controversial thought. In 10 years’ time, we might not even be talking about DevOps anymore. By then, all stakeholders will understand how to work holistically to achieve business value through the end goal of delivering high quality applications and services to customers. So DevOps might even become redundant. But continuous delivery will be the norm.

September 2, 2015
Stackify APM+ brings real-time application performance management to .NET

It’s a fast-paced world. Recent research from Microsoft suggests that the attention span of the average human is about 8 seconds now. That means if your application doesn’t work as expected your users will quickly move on to find a suitable replacement. An application performance management tool can be crucial to identifying and resolving application issues as quickly as possible…while you still have the user’s attention.

Stackify introduced APM+ to give .NET developers real-time application performance analysis. Stackify has already established itself as one of the leading vendors of application performance management. Its platform monitors important metrics like CPU, memory, and disk utilization on servers and alerts developers or admins when issues arise. Now it is extending that monitoring to Microsoft ASP.NET environments with APM+.

“The level of real-time app performance and depth of APM+ analytics is unmatched in the market. Not only does Stackify give a complete 360-degree view of how a system is spending its time and where, but it also allows developers to quickly drill down to the heart of the code and see how it can be fixed or improved,” says Stackify CTO, Jason Taylor.

Application performance management in general, and a tool like APM+ specifically, fit neatly with the principles of DevOps. As I noted in a previous article DevOps is “continuous” at virtually every level. There is no beginning or end—no point when an application is completed and deployed and you can kick back and relax. While finishing touches are being put on an app to prepare for a new release a laundry list of changes and updates is already being worked on to develop the next release. There’s no rest for the weary (developers).

There will always be fixes and new features to work on for an app, but application performance management gives you insight into the changes that matter most. Knowing things like which app takes the longest time to load, or which app gets called the most often, or which app is failing the most gives developers a huge advantage that allows them to devote resources where they will have the most impact.

According to a Stackify press release, “APM+ gives developers an increased understanding at every level of an application’s performance and offers code-level profile traces to provide unparalleled system visibility — including method calls, log statements, cache lookups, DB queries, and web service requests.”

Why is that important? A couple reasons stand out. First, you want to be proactive about identifying and resolving issues with your apps. The old-fashioned method of waiting for users to report problems is too slow and reactionary. By that point you already have disgruntled users frustrated with your app.

The second major reason is that a tool like APM+ gives you a streamlined ability to resolve the issue(s) plaguing the app. Rather than a user reporting a problem and developers poking and prodding to investigate what the underlying issue is, APM+ gives developers visibility into metrics and data that enable them to quickly find and fix the problem.

APM+ is focused on the .NET framework initially but Stackify notes that it plans to offer support for a broader range of development languages later this year.

May 21, 2015
5 ways APM can solve your DevOps worries
This week at the InterOp conference in New York I had the chance to talk to a lot of IT managers transforming their organizations to adopt a DevOps culture. One of the key questions I heard repeatedly was – are there some best practices to break down the wall between Dev and Ops? How do you get to a point where we can deploy code multiple times a day like Facebook , Amazon and Netflix without impacting our users’ experience ? How do we minimize the risk of deployment failures and the blame game that ensues? With the need to innovate and close the customer feedback loop quickly Ops is being asked to deploy code more rapidly than ever before. The complexity of hundreds of developers updating code makes it a very sensitive environment. The last thing Operations wants is an outage leading to financial loss and the last thing development wants is to get a call in the middle of the night to figure out what code change caused it.

To have tight control over this fast paced environment we need Application Performance Management at every step. APM can help break down the Chinese wall between Dev and Ops and eliminate the finger pointing that happens during outages. Here are 5 APM best practices to enable a smooth DevOps working environment
1. Use the same APM tool in Dev and Ops: APM should not be an afterthought , should not be a tool that only Operations looks at to monitor apps. APM is essential in every step along the way , from dev/test to staging to production. As a part of test deployment, developers should use the same APM tool as Ops to see the impact of the code deployment on the application’s performance and catch issues before hand. With the same tool everyone is on the same page and there is less confusion on the metrics being tracked. Developers can’t say “Sorry Ops, we are not seeing the problem”
2. Isolate and fix performance problems sooner with Code Level Diagnostics: Today’s APM tools come equipped with deep diagnostics that lets you drill down to the line of code that may be causing a performance slowdown. When code deployed in the Test or Staging environment results in a response time spike, developers can use deep dive code diagnostics to detect the line of code, the SQL query, the method call that may have caused the spike and fix the problem before it is deployed on production. For example, you can detect that a SQL query is taking way longer than it did last week for a specific mobile device platform.
3. Detect changes with Deployment Detection: When new version of code is deployed in production, the change should be detected automatically without having to reconfigure the APM tool.
4. Analyze Pre and Post Deployment Performance Trends: Get before and after snapshots of the end to end transactions from your APM tool and compare performance trends over time. With topological visualizations you can, at a glance, see if any particular business transaction slowed down post deployment. With historical data you can see how the application’s performance and resource consumption is evolving over time. This will help fine tune your apps’ resources as well. For example you can determine whether an AJAX call has been slowing down over the last 2 weeks due to the slow down of a third party API call or because a disk consumption is increasing over time.
5. Automate actions on failures: Configure your APM tool to take actions on failures. For example configure an action to automatically increase memory if a memory spike alert is generated post-deployment while you take the time to diagnose the root cause.
Using APM let your developers focus on writing code rather than spend time fighting deployment catastrophes and enable a healthy collaborative working environment between Dev and Ops.
October 3, 2014