The Importance of APM for Developers

Software developers are the modern equivalent of medieval craftsman. In the old days, masters of the constructive arts — such as those who transformed trees into furniture — would take responsibility for the entire user experience. They did everything from design and configuration to implementation and delivery. If a chair leg broke or wobbled, the craftsman  would also be responsible for resolving the fix.

Clearly, the ways of the old masters are not possible at scale. They’re more equivalent to a waterfall approach than what’s possible with modern software. Now, software developers usually stop upon check-in and are oblivious to the QA builds. When their code reaches production-ready status it’s thrown over the fence to the operations team who keeps the applications deployed and running smoothly. Mass production line methodology has replaced the unsustainable  artisan approach. Fortunately, modern runtime advancements are removing the barriers throughout the Software Development Life Cycle (SDLC), bridging more of the divide between development, operations, and strategy responsibilities, and an APM solution further augments that divide with valuable insights.

Development/Operations Conflicts

Problems can arise if developers have little or no contact with operations. When they do interact, functional priorities and lack of strategy may lead to conflicts. Developers are typically compelled to introduce the new features that customers want, while operations is expected to shut down code pushes with features that aren’t 100-percent (or at least five-nines) reliable.

This disconnect between teams that should be aligned is where systemic errors begin to breed. There’s a rupture in the feedback loop that should cycle from operations to developers and back again. Departments with disconnected tools bring back disjointed data. A broken SDLC can breed symptoms such as the following:

  • Customer surveys dictating strategy

  • QA reports providing minimal insight into a true view of application performance

  • Developers lacking insight into the usage of their features

  • Developers guessing how to fix their code issues in production

  • Operations teams relying on inaccurate logs to communicate with developers

  • Product management teams not aligning with development on a prioritized roadmap strategy

Introducing APM and Business Transactions

The most successful digitally-defined companies connect developers with the goals of the business by introducing application performance monitoring (APM) to developers. APM measures how applications behave under various conditions. It rigorously tests application code throughout all phases of the SDLC and directs developers to the source of issues before their code hits production. Developers using APM can make substantial gains in issue resolution and test how a fix will impact the rest of the code before anything else fails.

A key concept within APM is Business Transaction management. Business Transactions create a unified perception that technical and business teams can align on. It takes developers outside their normal thinking processes and examines the software from the user’s perspective. Instead of breaking down the software by functional areas, such as processing, navigation, and communication, the Business Transaction approach follows individual users’ actions as they move through the application and all the intricate dependencies that exist within a distributed ecosystem.

APM and the SDLC

There are significant improvements that APM can suggest at each of the five steps in the SDLC.

1. Research and Analysis – As you collect data on what stakeholders want to achieve and problems they need to solve, Business iQ can measure the business impact of your application against dynamic benchmarks.

2. Design – This is where wishlists become practical solutions. A roadmap strategy defines what kinds of projects will be necessary to achieve specific functionality. APM and the business transaction approach help developers and product management plan out a common metric for how they view the application.

3. Testing – Still in pre-production, this is where QA takes center stage. The agile process just became much more agile as an APM solution filters potential production issues before they impact customers.

4. Implementation – Perhaps this is the most critical stage for APM, because it can identify and prevent errors or latency from ever reaching the customer. Feel free to unleash production-level load stress tests to mimic a real-world scenario and watch as your APM solution catches bottlenecks in real-time.

5. Support and Maintenance – Now, operations takes control but can have more meaningful exchanges with developers, who are already familiar with APM. The winner is the business, that is able to exceed customer expectations thanks to cross-functional alignment.

The Agile Development Bed

In this new connected world, demands are on constant improvements in speed, features, and security. Production environments are agile development beds where code pushes and app updates run on a regular schedule. APM brings developers, operations, QA, and product strategy into alignment around a singular set of tools and goals — just as the master craftsmen did a millennium ago.

Stay tuned for more from AppDynamics as we continue to strive to help developers improve code, improve SDLC efficiency, increase application performance, and reduce their MTTR.

Dev and Ops Continue to Revisit Their Roles in the Enterprise in 2017

If there are two departments that have undergone huge changes in recent years, it’s development and operations, and 2017 looks likely to see this trend continue. What’s on the horizon for the often dev-centric DevOps teams and operations in particular?

A test of faith for DevOps

According to Gartner Research, DevOps is at the peak of inflated expectations and staring at the trough of disillusionment? Is this correct? During the Gartner Data Center London event last month, it was revealed that 38% of Gartner Circle members stated that they were already using DevOps today but equally, as presented at the aforementioned event, Gartner conferences witnessed 87% of attendees stating that DevOps has not delivered the benefits they were expecting. “Changing the behaviors and culture are fundamental to the success of a bimodal IT approach. We estimate that, by 2018, 90 percent of I&O organizations attempting to use DevOps without specifically addressing their cultural foundations will fail,” according to Gartner Research Director Ian Head. So, a lot of buzz surrounds the topic, which at my count earlier this month returned nearly 17.5 million search results.

Making the move to a DevOps approach is not for the faint-hearted or easily discouraged. It takes persistence, belief, and superior internal sales skills to lead others on the journey. The good news is there is now a critical mass of enterprises who have made the move and are experiencing significant benefits. It just needs a tactical approach to advocate and oversee change in the face of opposition, momentum-sapping inertia, or difficulty adapting. In doing so, initial wins can be achieved, upon which further initiatives can be built.

An equal partner with the business

As DevOps makes its impact (high-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times for example), the relationship between IT and the business becomes intrinsically interlinked. The capabilities which deliver better quality, more robust applications faster, and with less waste open up significant potential for new customer offerings, improved customer relationships, and time-to-market. In short, DevOps adoption can mean a critical competitive edge. The decision around what to build, when to release it, and when to update it should be the result of an ongoing peer to peer dialogue between tech and business leads. In parallel, IT teams overall need to position themselves as enablers of transformation, not inhibitors.

Organizational change

A few years ago, any DevOps introduction would almost inevitably include a classic “silo” picture of the dev team on one side and the ops folks on the other (and yes, I was one of those offenders). This situation is evolving now as new roles that blur this division emerge such as DevOps Engineer, Site Reliability Engineer, and Cloud Architect. They don’t sit easily 100% in one camp or another and possess hybrid skills that can prove a real asset in delivering robust, scalable, and rapidly deployable applications. Expect new structures to emerge that resemble a flotilla of speedboats rather than an ocean liner in terms of ability to respond to changing demands.

No metric blind spots

In an increasingly data-driven world, the complexity of today’s applications should not be an excuse for the unavailability of insights into how they are performing. Whether or not an organization has chosen public, private, or hybrid cloud, experimenting with microservices or embracing the potential of containers, rich, detailed, yet easy to understand metrics around every aspect should be at hand in real-time.

IoT and DevOps: a brave new world

The IoT topic has been around for several years, but 2017 could be the inflection point. Gartner Research estimates that by 2020, more than half of major new business processes and systems will incorporate some element of the Internet of Things. While wearables may have the consumer eye, industrial IoT usage dwarfs that in consumer markets. As a counterpoint to industries that have led in digital transformation (retail, banking, and telecommunications), the heaviest IoT users are likely to be in oil, gas, utilities, and manufacturing industries, according to a global survey released March 3 by Gartner. No sector is immune to the need to review and evolve its application development approaches. In parallel, the DevOps relationship to IoT is an interesting one, particularly around the end user experience (it’s a myriad of small devices now, not a tablet or smartphone) and security (think public wifi issues) to name but a few. Expect more DevOps teams to work on applications with an IoT use case and go through a major learning curve.

DevOps and its relationship with data

It’s not just big data, all data, including databases themselves (which came up often at AppSphere 2016 as a cause for latency and downtime) that will matter. From the rise of the role of data scientist to the explosion of IoT data, DevOps teams cannot ignore this all too important area, and need a POV regarding how it should be managed. One particularly interesting area will be the increased use of business algorithms, with a lot of the data needed to build these held within the remit of IT operations teams. Machine learning APIs can have a significant role here, as they help developers to apply machine learning to a dataset enabling predictive features to be added to the applications they are building. One example of this is Google Prediction API, a cloud-based machine learning and pattern matching tool. It helps with the upsell of opportunity analysis, provides details of customer sentiment and churn analysis, and detects spam, amongst many other features. Stephen Thair of DevOpsGuys has a written a solid exploratory piece on this topic, which may not be as hot as containers, but is still an essential consideration. Data Ops experts share a related goal (faster time-to-market) and DevOps centric organizations would be wise to have a line of communication between the two teams.

Security

This subject could be a blog all on its own. How can DevOps work more closely with security teams as data breaches threaten to damage a brand as much as a slow responding app? What can DevOps do to ensure applications are built with security in mind from day one? How can anomalies or outliers in business transactions provide an early warning system to fraud? The potential for APM insights to assist in fraud detection is an interesting use case which PayU, one of our customers, raised in their presentation at AppSphere 2016. Look out for more data breach headlines in 2017, though maybe not at the scale of the recently announced Yahoo hack, which is understood to have involved one billion accounts.

But what about operations, specifically? In some ways, the less prominent player in DevOps adoption, ops teams are perhaps more likely to undergo even greater changes than their dev counterparts in 2017.

Move from being a cost center to an innovation hub

Enterprise technology spending in 2017 is set to rise 3%, with $3.5 trillion on technology expected to be invested, according to Gartner Research. Yet within this environment, operations leads will still need to pivot from being seen as an area that risks being cut year-on-year to one that helps build the business and is in step with its goals. This requires many behavioral shifts — from running a tight ship to being a negotiator and intermediary between multiple cloud, software, and infrastructure vendors, and lines of business themselves. The ability to market one’s team and its contributions becomes almost as important as deep technical knowledge when pursuing investment. The established focus on being the data center guardian and only objectivized on stability has to shift towards accepting that the I&O has to be anti-fragile, rather than simply unchanging. This will take a fine balance between calculated gambles on new approaches and technologies, and acceptance of the fact that, as Ian Head of Gartner Research pointed out, a small amount of risk has to be accepted as it is impossible to innovate otherwise.

No ops team is an island

Having just misquoted John Donne, those in operations will need to accept that they will both lose and gain going forward. As Gartner Research pointed out at the Data Center Summit, infrastructure and operations environments have traditionally been the center of the ops team’s world view. However, as the organization expands, operations staff will find that while the number of activities they become involved with increases, their ultimate control over specific areas reduces at the same time. Organizations are now taking a more collaborative approach. This means the creation of flexible and agile networks and ecosystems become ever more important, with the innate capability to scale and rollback investment areas as the business demands. This requires an astute ambassador with a business-savvy mind, building agility into the I&O mindset rather than a rigid enforcer who views change with suspicion.

Customer experience is key

As DevOps delivers an improved customer experience, there is potential for more insights as to exactly what the end user sees and interacts with, bringing development in particular closer to understanding exactly whether what they have built works, or doesn’t, with its target audience. At AppDynamics, we have seen how end user monitoring of experiences across mobile, tablet, and PC platforms and devices, for example, is essential for understanding how, when, and where customers are engaging with an application. This has been critical in preventing a degradation in response times ahead of impacting customers and the company’s reputation.

The skills gap

How do enterprises build and nurture teams that are equipped for the digital business platform? Relying on rockstars and contractors are short-term fixes. How can the classic Gartner Research I&O employees working on predominantly Mode 1 refresh their skill sets and feel part of the “new way”? How can up and coming young talent be attracted not just by salaries, but a culture where they feel valued and listened to? DevOps can’t be just for the rockstars and stellar contractors — buy-in needs to come from colleagues who see the move as inclusive and non-elitist. There are many external consultancies who can provide some excellent stewardship and direction in the tricky subject of enterprise DevOps, but the best ones are those who teach others how to fish, pair up, and coach them — rather than treating knowledge transfer as an inhibitor to additional consulting fees.

If there is one standout theme for 2017, it’s the overwhelming need to revisit how dev and ops view their role in the organization, how they contribute value, their scope of responsibility, and the new mindsets needed to thrive in an ultra-high velocity world. In the words of Stephen Covey, continually “sharpen the saw”.

Be hungry to learn, question perceived wisdom if it doesn’t fit with evolving demands, and remain open to trying new approaches without fear of failure inhibiting new platform initiatives, onboarding technology partners, and being objectivized on more outcome-based metrics.

Learn More

Download the eBook, 10 Things Your CIO Should Know About DevOps.

Pokémon Go: A Developer’s Perspective

Every app developer dreams of the kind of success that Pokémon Go is enjoying right now. A month ago, it was just a rumor. Just 24 hours after it was released, it was the number one top grossing app, even though it was free to download and play. Within a single week, Pokémon Go servers were slammed with traffic from 21 million players while they tried to fix production errors.

Today it has 3X more Android downloads than Tinder, nearly as many daily active users as Twitter and users spend twice as much time in the app as they do in the phenomenal Snapchat. Even Facebook can’t hold up against the Pokémon onslaught. By any mobile app performance metrics you want to use, Pokémon Go has been a smashing success. It’s also at the center of a media firestorm.

How did they do it? Why are so many people so upset about it? What lessons about better software performance can you take away from the whole experience? Here’s your instant history of an app that tapped into far more demand than the developers could handle. It’s both a best-case scenario and a cautionary tale.

The Birth of Pokémon

It’s just a game for kids. Really, that’s all it is, but that’s exactly what people said when Nintendo released Pokémon 20 years ago. It’s a game where you capture little monsters and make them fight each other – part insect collection and part sci-fi gladiator arena. Kids continued to love it as they grew up and then came the anime manga, the trading cards, the TV cartoons, the dolls and the movies. Now, the Pokémon franchise is worth over $46 billion.

In 2014, as an April Fool’s Day prank, Nintendo teamed up with Google Maps to make Pokémon monsters appear in real places using augmented reality. The response was so enthusiastic that suddenly everyone got real serious about it.

Monsters Unleashed

Enter Niantic, an augmented reality game maker led by former Google Earth developers. It’s best known for Ingress, a real-world/sci-fi mashup where gamers travel to real places using Google maps and fight for supremacy of “portals” in the app. A portal could be a business, a school, a park, etc. If it could be mapped, it became a battleground. Pokémon Go was built on the skeleton of Ingress and former portals became “gyms” for training monsters or “Pokestops.”

Niantic CEO John Hanke said they started building the game based on a data set of public artwork that they chose from among geo-tagged photos inside Google Earth. “We basically defined the kinds of places that we wanted to be part of the game,” Hanke said. “Things that were public artwork, that were historical sites, that were buildings with some unique architectural history or characteristic, or a unique local business. There are portals in Antarctica and the North Pole, and most points in between.”

Tech Specs and Coding Languages

There’s no official word about the code base of Pokémon Go, but the greatest probability is that the game was coded mostly in Java/libgdx because that’s what Niantic used to create Ingress. Although the bulk of the game may be Java on the server side, many coders who have played it suspect that there has clearly been some work in Objective-C/Swift for the iOS version so that it runs as a native app.

The strongest piece of evidence to support this comes from the Niantic employment page, which reads: “Create the server infrastructure to support our hosted AR/Geo platform underpinning projects such as Pokémon Go using Java and Google Cloud.” Niantic is also looking for coders with “Key Skills: Unity3D (Unity 3D), C# — You will work with a proven and experienced team of mobile and cloud developers to turn the entire world into a gameboard.”

The database supporting the game is NoSQL running inside Google Cloud Services. That implies that the game is probably integrated with Cloud Bigtable or Cloud Datastore, perhaps using JSON or CSV for data handling. While many other apps interface with their se RESTful APIs, Pokémon Go seems to be relying on an RPC interface for its server interactions using Protocol Buffers.

Safety and Privacy

In terms of data safety, the iOS version initially asked customers for full access to their Google accounts. That means it could have gotten into user Gmail histories (which often contain passwords and other private information), classified information in Google Docs/Drive or very personal info from Google Calendar. Niantic had to issue an apology and said it never intended to collect all that private data, but industry watchdogs just have to take their word for it.

At one point, due to this privacy problem, their sign-up process was broken and the company had to turn away new signups. That can be particularly bad from a developer perspective because most apps lose 60 percent of their customers over the first month, and 96 percent after a year. New sign-ups are the only way to stay alive.

When the Servers Crashed

Pokémon Go started out with a great deal of talent, serious backing from major industry players and a built-in audience of brand fanatics. What could go wrong? A lot, it turns out. A few days after Pokémon Go’s official release, Forbes posted an analysis that declared, “The launch has been an unmitigated disaster. The list of things that have gone wrong with the launch goes on and on. Players unable to login; players in the U.S. unable to download the game to begin with; game crashes; maps bereft of any and all Pokémon, gyms, etc. Everything from sign-in issues to overwhelmed servers have plagued the game’s launch.”

This is the perfect example of the danger of popularity. Normally, the last days leading up to pre-launch can be frantic. App developers have often used the days after launch to work out the kinks. That clearly couldn’t happen under the crush of new user sign-up traffic that hit their servers. Others have made the same mistakes, though.

As for the production team at Pokémon Go, could they or should they have anticipated so much traffic? Yes, and Niantic’s launch problems might have been catastrophic if it were another business critical application. The average cost of a critical application failure per hour is $500,000 to $1 million, according to a research by analyst firm IDC. It is even more important to get things right and deliver exceptional end user experience when applications are primarily consumed via a mobile App. Nearly a quarter of apps are only opened once.

Many enterprises are using AppDynamics to avoid such catastrophic situations and to minimize the negative impact on their brand reputation. With AppDynamics, they are empowered to have real-time insights into application performance, user performance and business performance so they can move faster in an increasingly sophisticated, software-driven world.

Where Pokémon Is Going

Pokemon Go brought reality to the concept of meshing the virtual with the real, so you should expect augmented reality to develop quickly now that it’s finally become profitable. Expect a huge second mover advantage in the world of app development because you can be prepared to address the server traffic spikes, the user privacy issues and the public safety controversies.

The days of actual immersive virtual reality, complete with a 3D experience, might not be far off, but preparation is everything, especially with app developers, programmers, and IoT experts. The most important takeaway from the story of Pokémon Go is that companies of all sizes need to prioritize performance monitoring before errors start impacting customers. The best way to do that is to simulate heavy traffic and deploy tools like AppDynamics to filter out common errors and exceptions as soon as possible and long before the app hits production. In this case, the users kept coming, but not every app maker will be so lucky.

What kind of developer are you? [QUIZ]

Are you a code maverick? Maybe you’re a buzzword bandit quick to use “SoMoClo” and other trendy terms? Or maybe you’re just not sure which stereotypical bucket you fall under. That’s why we created this highly scientific personality quiz to assess your true developer personality.

This quick test asks about your food preferences, tools you use, and even your TV show habits. What can we say, it’s pretty accurate.

Are you a developer looking for a new and exciting challenge? You’re in luck, we’re hiring!

Cracking the Code: A Holistic Look at the Developer Industry [INFOGRAPHIC]

Are software developer jobs on the rise? Which cities are the most popular for tech workers? Are Computer Science degrees spiking with the tech boom? Which coding language earns developers the highest salary?

These are a few of the questions we set out to answer and showcase with our Cracking the Code infographic.

Some of the answers were expected, like San Francisco and San Jose topping the tech cities list. However, some answers surprised us, especially to see Ruby and C developers earning more annually than a Java or .NET developer.

Check out the full infographic below:

Are you a developer looking for a new challenging role? Check out Careers page!