devopsy.kinsta.cloud

Tag: application performance

Why One Second Matters for Today’s Application-Centric Businesses

A lot can happen in a second, especially if your business is digital. Google receives 68,000 search requests. Amazon averages $2,361 in sales. In this application-centric world, those are just examples of what application outages can cost the business. Imagine if you didn’t even know there was a problem for just one minute. Sixty seconds of downtime would result in almost 3 million unfulfilled Google search requests and it would cost Amazon about $141,660 in missed sales.

In an economy where consumers will abandon an application in six seconds if the experience isn’t satisfying, shopping carts are routinely deserted for poor performance and brand loyalty depends on immediate gratification, one minute of poor application performance can be disastrous for today’s digitally transformed organizations. Businesses must be able to see how their application (which is essentially their business) performs in real time, by the second.

The Need for Speed in Today’s Modern Applications

Those who code fastest will be the winners in a digitally transformed world. To increase velocity, developers are embracing more modern development methodologies such as Agile and using containers and microservices for their flexibility, scalability and speed. This is having a tremendous effect on the technology makeup of today’s applications and services.

Operations must respond to this development speed revolution, especially when applications are deployed in a containerized environment. Consider this: Within 15 seconds of starting a script, an array of newly created containers can alter (or significantly impact) performance and/or quality of an organization’s applications—and its business. If those applications aren’t monitored within the same realm of speed at which the application is morphing, IT Ops won’t know about problems until unhappy customers start calling—something every business wants to avoid.

Traditional application management products architected for monolithic applications struggle with visibility into modern applications. They also struggle to match the speed of change within the modern dynamic applications that digital businesses are rolling out today. In essence, using a traditional tool to monitor modern applications removes the benefits of a high-velocity development process through the increased risk of insufficient monitoring. High-resolution, time-based metrics (i.e., one-second granularity) are critical to modern application performance management.

This need for one-second visibility actually goes beyond monitoring. Operations teams require feedback whenever a new application component is deployed, whether it’s a long-term server, a short-term container or a change of host. With application changes occurring with increased frequency and regularity, feedback is necessary in seconds, not minutes.

One Second Means Business Success or Failure

For monitoring tools to catch up with development progress and innovation, one-second visibility, or granularity, is essential.

In today’s modern, dynamic application world, where the application is the business and possibly the only direct engagement with customers, one second means everything. It can mean the difference between business success or failure.

The technology that allows developers to deploy applications so quickly is a great advantage, but that same attribute—speed—creates a huge hazard if these more complex applications can’t be adequately monitored and managed. The only way to ensure your IT Ops team—and your business—are protected against application outages is to monitor (and manage) your applications on a second-to-second basis.

About the Author / Mirko Novakovic

Mirko Novakovic is CEO and co-founder of Instana, where he brings deep technological experience with a background that includes performance management software, agile development and DevOps. Prior to Instana, Novakovic founded codecentric AG, a leading software consulting firm focused on performance, agile software development and software architecture. He received a Bachelor of Applied Science in Information Technology at Stuttgart University and an SMB Management at the University of St. Gallen. Connect with him on LinkedIn and follow him on Twitter.

December 26, 2017
Testing’s Role in Delivering Digital Transformation
“We have a quality philosophy now…but it took the rise of the middle child to make it happen.”
- Ann Lewis, ExxonMobil
Ann Lewis’ metaphor of testers being the “middle child” between software development and IT operations was present throughout Accelerate 2017, Tricentis’ annual user conference. Nearly every head in the room nodded as Lewis described how testers, like middle children, tend to get less attention than their professional or familial siblings, but she insisted that there’s never been a better opportunity for testers to receive the respect they deserve. Digital transformation, no matter how you define it, requires new commitments to quality, and it’s up to testers to claim be the change agents in the transformations that CIOs are tasked with delivering.

Tricentis CEO Sandeep Johri and other CxOs who spoke at Accelerate echoed this sentiment. Johri pointed out that speed continues to be a primary focus of maintaining or gaining competitive advantage, and manual testing processes that prevent agility or DevOps success at the enterprise level must be automated going forward.

What was also made clear is that scaling investments in automation is not the single key to success. The pressure CIOs are under today, especially around digital transformation, requires new investments in a number of different areas, many of which are only just being realized. While CIOs may understand the necessity of quality, it’s up to testers to get the buy-in required for the continuous testing required to deliver it at scale.

Testers with an oft-ignored middle child mindset may find the concept of being recognized as a “champion” by their CIO or CEO unlikely. But, Todd Pierce’s impassioned session on “What CxOs really think about testing” was designed to inspire testers to change the way testing was viewed too often in the past.

As a current Rock Health and Dignity Health board member, and former Bill & Melinda Gates Foundation chief digital officer, Pierce shared his peers’ all-too-common beliefs that testing takes too long, costs too much and constrains developer productivity. And, while it may hurt to admit, with manual testing that should be automated and insufficient testing time that results in bugs making it to production, it’s not surprising that CIOs would feel this way.

Pierce explained that testers who adopt innovative, scriptless “high-precision testing,” are able to shorten their test cycle, reduce defects that make it to production and eliminate costly rework for themselves and developers alike. When high-precision testing is performed continuously throughout the software development life cycle (SDLC), those beliefs that testing takes too long, costs too much and impedes innovation lose all validity. “Everyone in this room should be the drivers of agility in the enterprise,” remarked Pierce.

Emmet Keeffe at Insight Venture Partners hosted a CIO roundtable later in the day where four CIOs detailed their personal experiences with taking enterprises through digital transformations. Each CIO admitted that in the past they had underestimated the the time being spent on testing, and one somewhat bravely stated that he’d always found testing somewhat “boring.” One might expect a room of testers to storm the stage with charges of heresy, but, given that many testers have suspected that management felt this way for years, I got the feeling that many were simply impressed that someone who felt that way had admitted it.

But the panel, Pierce, Lewis and countless other speakers at Accelerate also made sure that the attendees of their sessions understood one thing: As more organizations undergo digital transformation—and no matter what stage of digital transformation they’re in—testing has never been in a better position to drive positive changes that will have monumental impacts on the business.

Whether CIOs have been tasked with delivering greater agility, DevOps shifts, increased security, enhanced user experience, reliability and performance or legacy app modernization, testing may not be the first organization that CIOs turn to for help. But, as Keeffe explained, testing leaders who truly understand the incredible opportunity they have to make those CIOs heroes will make themselves heroes in the process.

About the Author / Noel Wurst

Noel Wurst leads influencer relations for Tricentis, and collects stories around cultural shifts and evolving technology’s impact on the software testing industry. By attending global conferences, interviewing passionate software professionals, and working closely with product, engineering and customer success teams, Noel looks for stories that matter and innovative ways to share them with audiences that lead to business growth. You can follow Noel on Twitter and LinkedIn.
October 30, 2017
Riverbed Aims to Unify App, Network Performance Management

Much of the initial focus on DevOps has been on accelerating the rate at which applications are built and deployed. But once those applications are deployed, it’s not too long before the focus shifts to the quality of the end-user experience. Aiming to make it easier to determine what the quality of that experience really is, Riverbed Technology has launched a Digital Experience Management initiative based on the SteelCentral management platform.

Erik Hille, director of product marketing for Riverbed, says the latest release of SteelCentral provides tighter integration between SteelCentral Portal and the SteelCentral Aternity end-user monitoring tool and SteelCentral AppInternals, an application performance management (APM) platform. The goal, says Hille, is to make it easier for an organization to holistically manage individual end-user experience by correlating information at the device, network and application levels. As part of that effort, Riverbed also has integrated the workflow between SteelCentral Aternity and AppInternals to create an integrated monitoring system.

Hille says IT operations teams can use a comprehensive approach to managing digital experiences that can be set up in fewer than 10 days. Once in place, IT operations teams can more quickly identify the root cause of any issue by correlating application, device and networking data through a single pane of glass. In addition, Riverbed is employing REST APIs to make it possible to consume alerts generated by collaboration tools such as Slack and HipChat. IT operations teams can not only automatically open incident management tickets, but also collect additional metrics via those APIs.

Riverbed is also providing integration between NetProfiler, a network performance monitoring tool, and NetIM, a network device management tool, to provide more visibility into how network infrastructure impacts network performance.

Hille notes that most IT operations teams are swiveling between different sets of tools to correlate the same information. The problem is that as more organizations strive to become a digital business, any performance issue has a direct impact on customer satisfaction and the amount of revenue being generated. Faced with that increased business pressure, Hille says IT organizations need to re-evaluate legacy approaches to IT operations based on silos. The goal should be to implement a more proactive approach to IT focused on proactively preventing issues from occurring or escalating, versus merely reacting to isolated events as they occur.

One of the few things in DevOps that developers and IT professionals can agree on is that whenever there’s an issue, it’s the fault of the network guy. That’s not always true, but it does take networking professionals a long time to prove their innocence. Until then, there’s a tendency to assume their guilty until proven otherwise. Obviously, that kind of bias isn’t in keeping with the whole spirit of integrated DevOps. A more comprehensive approach to application and networking performance management should go a long way toward reducing the amount of finger-pointing inside any organization.

There will never be a perfect IT environment. The goal is to discover issues before the end-user notices—and, failing that, resolve that issue in as little time as possible. Any argument about what exactly happened to cause the problem can occur at a later date and time.

— Mike Vizard

June 26, 2017
Database Bottlenecks: The Hidden Cause of App Slow Downs?
Performance problems can cripple mission-critical business apps. If you are lucky enough, your solution could be as easy as adding more WAN bandwidth, a few extra servers or a content delivery network, but the real problem arises when your database becomes your biggest bottleneck. When performance issues adversely impact the applications that keep your business operations running and revenue pumping in, the challenge is more difficult to overcome.

It can be painstaking, tedious work to examine the architecture for flaws, dive into code for clues on sluggish performance and scour log files looking for correlation events. Among all the areas to examine, the following three problem spots should be high on the list of troubleshooting priorities to remove performance issues:
1. Connection Pooling Problems
2. Below Par Query Performance
3. Insufficient Concurrent Capacity for Handling Heavy Traffic
When database administrators (DBAs) fail to find and fix bottlenecks in time, businesses lose eyeballs and revenue—sometimes losing customers for life. Every transactional app accesses a relational database, and their biggest problem is the challenge of scaling horizontally. While modern databases support horizontal scale-out, today’s apps aren’t written to leverage this additional capacity.

An intermediate software layer, database load balancing software, solves this challenge; it makes the apps able to use additional servers without any code changes. It often includes caching as well, which can substantially increase performance—again, with no code changes. Database load balancing not only makes it easy to scale horizontally but also helps you identify other bottlenecks and mitigate them in a matter of minutes.

Database Load Balancing: The Silver Bullet?

Database load balancing software comes with analytics tools that precisely pinpoint database issues in real time. It monitors everything from every read and write query to connections, server performance and overall database load. Detailed analytics offer insights into what you need to fix and where to focus your attention to ensure better performance. A load balancer has all the necessary tools needed to resolve performance problems in a timely manner. It efficiently addresses the three major performance problems previously mentioned and significantly improves app performance and availability through:
1. Connection Pooling and Multiplexing: Database load balancing software can drastically decrease the number of connections to your servers by applying connection pooling and multiplexing. Unlike client-based connection pooling, this approach ensures greater operational efficiency and facilitates easy handling of additional connection spikes.
1. In-Memory Query Response Caching: The analytics of the software identifies potential queries to cache and lets you cache them with no application changes. For example, you can cache an article in a content management system (CMS) for a day, having the comments section pull from the database to stay fresh. You can cache a zip code table for months. Look for the ability to set time-to-live expiration or automatic cache invalidation so you can ensure atomicity, consistency, isolation, durability (ACID) compliance and transaction safety.
1. Dynamic Load Balancing: Database load balancing software routes queries from the app to multiple servers in a safe and consistent manner. Its automated read/write split ensures high performance by diverting all the read queries to available read replicas and writes to the master server. This load distribution increases capacity and facilitates an instant scale-out. A load balancer acts like a single point of control that offers deep visibility into performance needs. With real-time insights into the root cause of problems, the entire find and fix process becomes fast, efficient and effective.
Saddled with the most difficult task of identifying database bottlenecks, DBAs can make their life easy and work efficient by leveraging a feature-rich database load balancer that automates the diagnosis of bottlenecks and gets the data flowing seamlessly.

About the Author / Tony Branson

Tony Branson is Database Load Balancing Senior Analyst at ScaleArc. Tony has a passion for dissecting tech topics such as transparent failover, centralized control, ACID compliance, database scalability and downtime effects. On his days off, he can be found watching sci-fi movies, rock climbing or volunteering. Follow him on Twitter.
June 5, 2017
Measuring What Matters in Evaluating Software Performance
When developing and deploying a new feature or application, performance (speed, reliability) must be closely analyzed. After all, there’s no benefit to delivering a product if it doesn’t work well or users are forced to stare at a spinning wheel. To get a true view of performance, many organizations rely on metrics—a smart move since metrics, much like the scale, do not lie. Right?

Unfortunately, that’s not always the case. Even when metrics are used, there often are different interpretations of performance, as well as debate over which metrics should be used in the first place. Metrics can be biased and manipulated, but does that mean we should stop using them? Of course not. Instead, we must learn to weed out bias and metric manipulation.

What is Bias?

Bias is not a bad thing; everybody is biased to some degree. Bias is defined as a particular tendency, inclination, feeling or opinion, especially one that is preconceived.

Two common biases are anchoring and confirmation bias. Anchoring is the tendency to rely on a single piece of information, usually the first piece of information we encounter. The statistics presented first will most likely be remembered and drive decisions, responses and reactions.

Imagine you’re about to launch a new application, but before doing so you run some performance tests to see how fast the application loads. The initial tests show the load time is 10 seconds. That’s too high, so the team looks for ways to improve performance. A few weeks later response times drop to 6 seconds, a 40 percent improvement. That’s great, and everybody celebrates. But what if initial tests showed page load times of 4 seconds and a few months after launch times crept up 40 percent to 5.6 seconds. Would you still be celebrating? No, you would be looking at what went wrong and trying to fix it. The initial anchor influences whether you see a time as positive or negative. 5.6 seconds is better than 6 but the initial anchor makes 5.6 seem worse.

Confirmation bias is the tendency to interpret and search for information that confirms a pre-existing hypothesis. If you believe a new feature does not add value to an application, you may be more likely to focus on negative statistics rather than positive ones. If testing shows application load times will increase 15 percent with the new feature, you may use that as proof to delay or stop the release of the feature. If, however, you think the feature is a real game-changer, you will find the research about the 20 percent rule, which says people perceive changes in speed when the difference is at least 20 percent faster or slower. A change in 15 percent won’t be perceived by users. At the core, confirmation bias is about ego and not wanting to be wrong.

The first step to avoiding biases is acknowledging they exist and everybody—yes even you—is susceptible. But there are ways to avoid them, or at least minimize their impact. Create your own anchor. Do research to determine what is an acceptable response time and use that as the anchor point. Search for facts that support and oppose your viewpoint, and don’t stop with a single site or fact; find multiple sources. Foster an environment where disagreement is encouraged in a positive and constructive manner, and listen to the dissenting viewpoints. Ask better questions and be willing to accept the answers even if they aren’t what you were seeking.

Avoiding Metric Manipulation

Metrics should be actionable and tied to business goals as opposed to being purely “vanity metrics”—those metrics that may make everybody feel good, but don’t reflect the true user experience and the consequent impact on the business.

Specific to measuring web performance, there are countless metrics that can be selected to determine whether a user experience is positive or negative. If you choose to measure the time to the onload event as the core metric, you can recode a page to defer items to after the onload event. The metric will go down, teams will celebrate, but did this have any impact on the user experience? Was the goal really to reduce onload time or was it to better satisfy end users through a faster site in their eyes, increasing conversions and time spent on site?

Here is a quick checklist you can use to choose the right user performance metrics:
- Do improvements or declines in this metric impact what really matters: the user perception and business performance? Can this correlation be clearly made? How will this metric show progress towards the businesses goals and objectives?
- Can the metric be gamed or influenced? Once something is being measured, people may look for ways to game the system and show improvement when in actuality there is none.
- Is the metric “good enough”—i.e., the best one available, although it may not be perfect? Though not a performance-related example, popular website Medium’s choice of top-line metric illustrates this approach. While most websites rely on unique site visitor numbers as the ultimate gauge for their success, Medium, which views high user engagement as their key success factor, instead measures the time users spend reading articles on the site. This may not reflect the totality of user engagement (visitors who come to the site, but may just scan, not read) but it’s good enough and a more realistic indicator than alternatives.
Whether we like it or not, people are heavily guided by bias and emotion, and they often manipulate reality (even subconsciously) to support their own motivations. Performance metrics are and always will be central to evaluating software performance, but it’s not enough to just lay out the facts. Organizations must frame and present metrics appropriately and sufficiently, and focus on those that are the most relevant and reliable. These are the keys to delivering the most complete, impartial canvas of performance information, helping guide the best decisions in the interest of the business.

Tweets by dparzych

About the Author / Dawn Parzych

Dawn Parzych is Director of Product and Solution Marketing at Catchpoint. She enjoys researching, writing and speaking about trends related to application performance, user perception, and how they impact the digital experience. In 15+ year career, Dawn has held a wide variety of roles in the application performance space at Instart Logic, F5 Networks and Gomez. Connect with her on LinkedIn.
May 24, 2017
3 Approaches to End-User Experience Monitoring
The volume of transactions running through websites and mobile apps make customer-facing applications crucial to online businesses. If these applications perform well for their users, they generate revenue for the business. If they don’t, they affect the credibility of the business, which in turn affects the overall revenue. It is therefore imperative that businesses using monitoring to understand how well their revenue-critical applications are behaving for their end users.

From an IT team’s point of view, understanding the user experience of their applications is becoming more challenging as technology evolves. Newer and more complex applications are being written using an assortment of languages. These applications are being deployed on a wide variety of infrastructure components. To add to that, today’s users access these modern applications on a variety of devices such as the web, smartphones, tablets and smart watches.

Fortunately, there are a few means available through which businesses can determine the user experience of their web applications. Let’s take a look at three common approaches below.

Real User Monitoring (RUM)

Real user monitoring is a passive monitoring approach that involves collecting metrics at the browser level to accurately determine the application performance as perceived by the end users. Monitoring at the browser level is achieved by injecting JavaScript snippets into the header and footer of the HTML code of the web application. This code will ascertain the full page-load experience—including downloading the assets from the content delivery network (CDN), rendering the page and executing the JavaScript from the browser’s perspective. Additional instrumentation can be used to collect more metrics by injecting additional JavaScript code.

The data gathered through RUM provides answers to questions about user experience such as:
- How long did it take to load the full page?
- What is the response time from a network perspective (redirection time, DNS resolution time, connection time)?
- What is the time interval between sending the request and receiving the first byte of response?
- What is the time taken by the browser to receive the response and render the page?
- Are there any problems on the page? If yes, what caused the problem?
- How is the performance when the application is accessed from different countries?
- What is the response time across different browsers? Do new application updates affect the performance in a specific version of the browser?
- How does the application perform on different platforms such as desktop, web and mobile?
The biggest advantage of monitoring real user data is that it relies on actual traffic to take measurements. There is no need to script the important use cases, which can save a lot of time and resources.

Real user monitoring captures everything as a user goes through the application, so performance data will be available irrespective of what pages the user sees. This is particularly useful for complex apps in which the functionality or content is dynamic.

Server-Side Monitoring

Although user experience is best tracked at the browser level, application performance monitoring at the server side also provides insight into end-user performance. Server-side monitoring is mostly used in conjunction with real user monitoring. This is because problems originating on the server side can only be efficiently detected using server-side monitoring.

Monitoring performance on the server side involves agent-based instrumentation technology for acquiring and transmitting data. This monitoring approach is used to watch user transactions in real time and troubleshoot issues such as slowness or application bugs.

Developers have to install agents on the application server to help capture and visualize transactions end to end, with performance statistics across all components, from the URL down to the SQL level. This visual breakdown reveals the flow of all the user transactions being executed in each layer of the application infrastructure.

Server-side monitoring helps track response time and throughput taken by each application component, with the option to trace transactions end to end via code analysis. This helps the IT operations/DevOps teams identify slow web transactions and then isolate performance issues down to the level of the specific application code that caused them. The underlying database is also monitored most of the time to determine slow database calls, database usage and overall database performance. With server-side monitoring, users will be able to identify the SQL queries executed during a transaction and thus identify the worst-performing queries.

Synthetic Transaction Monitoring

Synthetic transaction monitoring is an active monitoring technique based on the concept of simulating the actions of an end user on a web application. This method involves the use of external agents executing prerecorded scripts that mimic end-user behavior at regular time intervals. The monitoring agents are usually very light and do not create any additional load on network traffic.

Most application performance monitoring solutions provide recorder tools to capture the actions or paths a typical end user might take in an application, such as log in, view product, search and check out. These recordings are saved as scripts, which are then executed by the agents from different geographical locations.

Technically, there are two different approaches to generating requests. Some solutions replay recorded HTTP traffic patterns, while others drive real browser instances. The second approach is more useful for modern applications that make a lot of JavaScript, CSS and Ajax calls.

Since synthetic transaction monitoring involves sending requests across the network, it can measure the response time of application servers and network infrastructure. This type of monitoring does not require actual web traffic, so you can use this approach to test your web applications prior to launch—or anytime you like. Many companies use synthetic monitoring before entering production in the form of automated integration tests with Selenium.

Synthetic monitoring does have its limitations, though. Since it is based on predefined transactions, it does not monitor the perception of real end users. Transactions have to be “read-only” because they would otherwise set off real purchase processes. This limits the usage to a certain subset of your business-critical transactions.

The best approach is to use synthetic transaction monitoring as a reference measurement that will help identify performance degradation, detect network problems and notify in case of errors.

Every business is different and has its own requirements that can help to choose which type of monitoring to implement. An ideal strategy would be to use active and passive monitoring techniques side by side so that no stone is left unturned in the pursuit to monitor end-user experience.

About the Author / Sridhar Iyengar

Sridhar Iyengar is vice president, product management, at ManageEngine, a division of Zoho Corp. For more information on ManageEngine, the real-time IT management company, please visit www.manageengine.com; follow the company blog at http://blogs.manageengine.com, on Facebook at http://www.facebook.com/ManageEngine and on Twitter @ManageEngine. Follow Sridhar on Twitter @iSridhar.
January 18, 2017
Making Performance More Than a Best Practice

Yes, you read that correctly: SRE means that strong application performance—speed, reliability and availability—no longer is simply a best practice. It is a must. Site reliability engineering, or SRE, is a term Google coined several years ago, and while there is no universal definition, SRE can be thought of as a discipline that blends software engineering with IT operations management. At the heart of the SRE model is a site reliability engineer who knows how to code as well as handle ops. The SRE concept is similar to DevOps, which is intended to bridge the divide between development and operations teams, but until now has not caught on the same way DevOps has.

The Need for SRE

The rise of the digital economy is now propelling end-user application performance to the top of the IT priority list. According to a recent EMA Survey, 55 percent of IT professionals rank end-user experience monitoring as their top application management priority. At the same time, growing IT complexity, including the cloud and multi-platform applications, are making it more difficult than ever to ensure strong user performance and identify the root source of problems before they escalate. We believe this performance imperative is driving the SRE resurgence, giving DevOps teams the necessary “teeth” to govern and resolve performance-related disconnects, swiftly and decisively.

Performance issues traditionally have been a lightning rod of conflict for even the most well-oiled DevOps teams. Developers, relentlessly focused on rolling out new products and features, keep throwing their “completed” work over the fence to operations. Operations teams, conversely, are focused on minimizing change and maintaining stability as much as possible. These opposing desires naturally create friction.

Performance problems only exacerbate this. Developers, who have already moved on to the next must-have feature, say it’s operations’ fault. Operations points their fingers at the developers, saying that poorly written code is to blame. No one is assuming responsibility and the developers and operations teams are stuck in a stalemate. Meanwhile, users are suffering, the call center is being inundated, revenues likely are circling the proverbial drain and the situation is quickly reaching a boiling point.

SRE is valuable because it finally brings an end to this suffering through a set of clear, irrefutable, mathematically based rules to govern all DevOps efforts and decisions. If a new piece of software achieves a targeted performance level, further rollouts can proceed. If not, future releases will halt until the first piece of software is fixed. The site reliability engineer, who is well-versed in both development and operations, serves as an independent arbiter who provides a clear assessment of where the root cause lies—on the development or operations side of the house. With guidelines firmly established and a central, unbiased person in charge of determining the right course of action, the developer/operations friction can be avoided and problem resolution can commence.

In an SRE model, developers and IT operations also share a staffing pool. If there’s budget for one hire, and a product is not delivering an agreed-upon performance level, the hire goes to the IT operations. If the product is delivering the required performance level, the hire can go to development, which will help the development team roll out new features and products.

The real beauty of SRE is that both sides have a vested interest in achieving strong application performance, ideally right out of the gate. If whichever side owns the problem does not fix it, they can forfeit any hopes of adding manpower to their team, at least in the near-term. There’s another more serious implication: for developers, there will be no further development; and for operations teams, less software to support may translate to lower headcount requirements.

An SRE approach has many advantages, including fostering a vested interest in performance across the entire DevOps team, and holding feet to the fire. Performance cannot be an afterthought—performance must be considered and measured from the very beginning phases of ideation and development all the way through production and post-production modifications. Users don’t care how fast or efficient your DevOps team was if the ultimate work product does not perform—in fact, this means the whole effort likely was in vain. Like a strict adjudicator, SRE may just be what DevOps teams need to bring to an end to performance-related squabbles once and for all.

About the Author / Mehdi Daoudi

Mehdi Daoudi is CEO and co-founder of Catchpoint Systems, provider of web performance testing and monitoring solutions. Before Catchpoint Systems, he spent 10+ years at DoubleClick and Google, where he was responsible for Quality of Services, buying, building, deploying, and using monitoring solutions to keep an eye on an infrastructure that delivered billions of transactions daily. Connect with him on LinkedIn and Twitter.

November 4, 2016
Managing Your DevOps Releases Efficiently

The Top 5 Things You Need to Know When Selecting a DevOps Release Management Solution

DevOps is a modern software delivery movement that encompasses agile principles and encourages automation in application delivery. Why adopt it? It allows teams to reduce errors due to manual steps and break down silos between teams to improve communication and collaboration between all stakeholders within the business.

Whether you’re knee deep in a DevOps transformation or just getting started, implementing a DevOps release management solution is an important step along the journey. Why? Because in today’s on-demand economy, organizations must capitalize on any opportunity to improve application delivery throughout the organization, irrespective of the development processes in place.

Based on a recent discussion between Michael Azoff, principal analyst at Ovum, and Anders Wallgren, CTO of Electric Cloud, I was able to glean why DevOps release management is a must for enterprises to modernize the software delivery process and compete at a higher level. More specifically, Michael and Anders discussed the top five requirements for selecting a release management solution, which I’ve laid out for you below.

No. 1: Application Manifest: Model and version applications, infrastructure and middleware.

This is what you’re looking for in an enterprise grade solution—a solution with ease of use in defining an application deployment blueprint, and being able to reuse it and version it and have variations to meet the complex and ever-changing needs of your organization. If you are doing continuous delivery and DevOps correctly, you should never have to make a change to a deployed application by hand—ideally, changes are made to the application model and then re-released into a production environment. This allows you to make and test changes in one place, and easily keep track of everything in production. Having an application manifest is a key facet for a great release management solution.

No. 2: Pipeline Design: Model, version and refactor pipelines, workflows and processes.

This is not only an important consideration for selecting a release management solution, but also is at the very heart of continuous delivery—the ability to define and manage delivery pipelines for complex legacy applications or newer microservices. For large organizations with lots of technical and process debt, being able to flexibly model and manage that sort of complexity is essential.

Ultimately, the whole concept behind DevOps comes down to the idea that there is the “what,” the “how” and the “where.” The “what” is the application manifest, mentioned above. The “how” is the pipeline design. What are all the stages this particular application or component or service goes through? Understanding your end-to-end pipeline is very important. You need to have the end to end of what your software goes through—not just conceptually, but even physically written down somewhere. If you don’t have that that process completely nailed down, you don’t really have a full understanding of what it takes to ship your software. Without this complete understanding, it can be much more difficult to have success. By modeling these pipelines, you allow teams to visualize the flow of value through the life cycle, and make iterative improvements on it in a collaborative and safe manner.

No. 3: Pipeline Execution: Predictably and efficiently deliver legacy and CD-style pipelines and releases at scale.

One of the most important things when practicing DevOps is enabling fast feedback, so getting visibility into pipeline execution as they’re occurring is very important. This provides teams an easy way to troubleshoot problems quickly, and then refactor and optimize the pipeline over time. Enterprise pipelines can be very complex and touch a lot of tools—your Dev team might be using Jenkins and Chef and Selenium, and your Ops team might be using ServiceNow and Azure cloud and Puppet. We have customers that have more than 60 tools as part of their ultimate DevOps toolchain. For each one of these tools or services you need to make sure you’re getting the best performance possible, and operating them as efficiently as you possibly can. As you execute them, the ability to see those executions live as they happen, then collect information about them and optimize your pipeline helps to make the entire process more efficient.

No. 4: Governance, Security: Role-based access control, traceability and auditability.

This is one of the key functions to consider for an enterprise-grade solution. If you just tie together your release capability with tools that still require some manual steps, you’re not able to scale that. This is where a large-scale organization, especially one that is regulated and has auditors, will want a solution that can demonstrate clearly that the whole process is governed such that no one can make a change to the process, environments or binaries without it being logged, and that any change that is made has gone through a QA and testing process. Those are the sorts of things that are really crucial for the Ops people, as they are handed responsibility for ensuring a low-risk environment.

When DevOps was starting, the overwhelming belief around security and governance was, “Gee, this is going to really bother the auditors.” However, it turns out it is quite the opposite—to get good at DevOps and continuous delivery, you really need to automate everything. What do auditors want? They want companies to do two things:

1) Document their process and

2) Demonstrate they are using that documented process.

In the process of sitting down and automating your software delivery pipeline, you are essentially documenting that process. Executing that pipeline gives you the record of what you did: How did we deploy? When? Who did it? What was the pipeline that was used? What was the testing? All of those things are now available to be audited.

No. 5: Integrations: Works with the tools you already use

You want a solution that fits in with the tools and process that you have. It would be a non-starter to show up and say, “Throw away all of your current tools and let’s use this new thing.” It would also be inefficient to have to change your process to fit into some tool’s preconceived notion of how your enterprise should run. Make sure you don’t have to change the way you do business, and that can help the DevOps adoption curve quite a bit.

By keeping these top five considerations in mind when selecting a release management solution, you can help ensure your journey into DevOps and continuous delivery is a much smoother, more efficient and more fruitful one. Regardless of the tools your organization decides to use, consider first how you can make your pathway to production a competitive advantage and reap the benefits of an efficient delivery pipeline!

If you have the chance, take a listen to the full conversation between Michael and Anders.

About the Author/Sam Fell

Sam Fell is the head of Marketing at Electric Cloud, responsible for driving awareness and demand for the company’s DevOps release automation and acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling and implementing DevOps release automation, IT change management and application performance management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.

Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.

July 20, 2016
Managing Application Performance in Hybrid Clouds
Keeping pace with changes to your networks, systems and applications can feel like a full-time job. As applications support more data types in more distributed environments—often in real time—it becomes imperative to have a clear picture of your end-to-end computing environment.

Just as important is making sure your apps take advantage of the adaptability and efficiency of microservices, document data models and other cloud-focused technologies.

All those much-touted benefits of cloud computing—efficiency, agility, scalability—come to nothing if your applications don’t perform as expected. The growing prevalence of hybrid cloud infrastructures makes managing app performance trickier than ever. According to a recent survey conducted by Riverbed and reported in a Jan. 29 article in Data Center Journal by Riverbed Marketing Director Steve Brar, 89 percent of IT pros claim poor application performance hinders their operations, with 58 percent report application performance glitches each week and 36 percent experience application performance problems each day.

Even worse, 71 percent of the IT managers surveyed are “in the dark” about why the apps are running so poorly, and 37 percent have turned to unsupported apps to fill the breach when such problems occur, which exacerbates the growing problem of shadow IT. On the plus side, the managers believe that making application performance more visible improves productivity (58 percent), customer service (54 percent), product quality (49 percent), employee engagement (46 percent) and revenue generation (43 percent).

Brar identifies five requirements to ensure end-to-end application performance visibility:
1. Network- and app-aware path selection directs traffic to one of three branches: one MPLS-based, one IPSec-protected Internet link and one that exits directly to the Internet.
2. Dynamic tunneling via a central control plane allows backhauling of branch data to the data center over an IPSec link.
3. Use secure web gateways in conjunction with advanced threat detection.
4. Use a QoS function that manages traffic from the source (inbound) rather than from the destination (outbound) to avoid slowing business-critical inbound data flows unnecessarily.
5. Implement a unified management plane that has an intuitive interface and is based on such high-level abstractions as applications, sites, uplinks or networks, depending on the unique characteristics of your IT infrastructure.
Cloud Application Management: The IT Basics Still Apply

It isn’t unusual for IT departments to feel they’re losing control of their network infrastructure when they migrate applications to the cloud. Cahit Akin writes in an April 22, 2015, article on Network Computing that capacity management, change control and other IT fundamentals are just as important for managing your cloud infrastructure—if not more so, considering the likely increase in network traffic that results.

The key is to consider the cloud part of your internal network architecture. Three WAN-optimization techniques transfer easily to cloud infrastructure management:
1. Caching images and other common elements on the local device helps ensure network bandwidth is reserved for the most important data.
2. Deduplication minimizes your backups and other secondary network traffic by ensuring only changed data is updated.
3. Compression removes unnecessary data from files to make them smaller and reduce overall bandwidth use.
The same features of a typical WAN optimization tool apply to improving the performance of cloud-based applications, notes TechTarget.

The challenge for IT is to keep pace with the tremendous changes in the nature of applications themselves. Data is collected, aggregated and analyzed from diverse sources, including IoT sensors, clickstreams, logs and social media data, as Ravi Dharnikota writes in a Feb. 5 article on DataInformed. Dharnikota states that IT has to support “anything, anytime, anywhere.”

Rather than a point-to-point approach to integration, you have to rearchitect your systems based on microservices that communicate via lightweight REST APIs. This way you distribute execution of integrations, which lowers costs and increases efficiency. If you aren’t already, you need to break out of the row-and-column rut and adopt document data models that support semi-structured and unstructured data.

Design Apps to Leverage Batch and Real-Time Processing

The only way to deliver an infrastructure that meets the anytime, anywhere nature of modern apps is to be adaptable enough to support both batch processing and real-time processing. Along with this comes the ability to determine which apps require real-time attention, and which can be shifted into batch-processing mode. Dharnikota cites the Lambda architecture as an example of one that accommodates batch and real-time processing by balancing latency and throughput.

However, the Lambda architecture’s shortcomings are explained by LinkedIn’s Jay Kreps in a July 2, 2014, article on O’Reilly Radar. Ultimately, you have to maintain code that produces the same result in two complex, distributed systems. According to Kreps, it’s much simpler and efficient to improve the stream processing system to support both batch and real-time modes. Doing so would entail increasing the system’s inherent parallelism by “replaying history very, very fast.”

An alternative to the dual-processing-mode Lambda architecture enhances the stream processing of a single-mode system to reprocess the full data log to mimic both batch and real-time modes.

In this model, reprocessing is required only when the code changes. Rather than two full duplicates of your code, you simply update the single set. The recomputation is done by a job that is merely an improved version of the same code: it runs on the same framework and takes the same input data, although the parallelism needs to be increased to ensure fast performance.

To optimize performance further, you could combine two output tables. However, having two separate tables, at least for a brief period, lets you revert to the old logic in an instant via a button that redirects the application to the older output table. To prevent the new version of the code from degrading performance in comparison to the old version, add an automatic A/B test or bandit algorithm that lets you control the cutover.
May 24, 2016
How Mobile Testing Converts to Greater Earnings

From a business’ sales strategy to the type of coffee it decides to stock in the company lounge, every decision boils down to this: How will it impact this year’s earnings? That’s what makes testing critical for any business with a mobile app: Having a poor-performing app is just like throwing money away.

There are three primary ways mobile testing translates into more cash for the company: corporate image, performance and speed to market. Read on for the details.

Testing and Corporate Image

Treat your mobile application like the face of your brand.

The majority of time people spend on anything digital is over a mobile application. Users spend more time on their smartphones than they do on their desktop and even television. From a business perspective that means any customer, both real and potential, will experience your brand over a mobile app more than on your TV commercials, physical billboards and even website.

They will see you over their phone more than in your store.

Mobile testing makes sure that the lights are on in your business, and that the air conditioner is working. We take for granted that when we enter a place of business everything is working properly. If something is off, we immediately recognize it. The same holds for a mobile application. If a function is not working right or is performing slowly, it will impact the user’s decision whether or not to become a customer.

If it is working perfectly, the larger audience that mobility commands will generate a larger customer interest in your brand.

Testing and Application Performance

The faster the app, the happier the customers.

The instinct for testing applications is to make sure the code itself is working. This is the basis of functional testing. In the age of desktop apps that work directly over the computer’s operating system, or even web apps that work over a local connection, the speed at which your application moved was usually assured.

Mobility has changed the rules. A mobile app working on a portable device can operate over any of the 400 mobile networks worldwide. It can have to brave poor network conditions, being confined to an elevator, or even riding through a tunnel. All of these different environments affect the speed at which your functions execute, which is no longer static.

If a function moves to slowly, the app will be considered broken. In fact, 90 percent of the mobile applications on a phone right now won’t be there in a year’s time. This is the need for performance, namely network virtualization testing: It makes sure your application provides potential customers with a smooth experience.

A smooth experience is the best way to guarantee return business, and retaining a customer is 5 times more cost-effective than acquiring a new one.

Testing and Speed to Market

Time is more important than money—with the right tools.

There are 20,000 mobile devices out there, running on four different type of mobile operating systems, all with their own set of versions both new and old. Every day there are devices and operating systems enhancing their capabilities with expanded capacity and new features. This demands that your mobile application adapt by including new features and capacities that capitalize on what the platforms are now offering.

The key to DevOps is to develop, test, and release the most cutting-edge version of your mobile application as quickly as possible without sacrificing quality in speed or execution.

Even if it is for only a short time, offering features your competitors are not ready to release is like having monopoly on a part of your market: You stand alone. Those customers looking for the best app will have only you to go to.

Mobile testing is the most arduous step in the DevOps process. A quality test automation tool that includes both performance and functional testing, connecting to a mobile lab enabled by a mobile cloud-testing tool, will accelerate your mobile testing while shortening the release time for your latest app incarnation.

Conclusion

In the age of mobile, everything that impacts your mobile application impacts your bottom line. Mobile testing reduces expenses, retains customers and enables your development team to design and release an application that can add solid growth to your company’s coffers.

April 25, 2016