Welcome!

@DevOpsSummit Authors: Elizabeth White, Zakia Bouachraoui, Pat Romanski, Liz McMillan, AppDynamics Blog

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Post

Four Key Takeaways for Application Performance and Monitoring | @DevOpsSummit #APM #DevOps

The latest Guide to Performance & Monitoring covers the verifiable & unknowable sides of building & maintaining performant apps

Designing for performance is absolutely essential; but runtime is so crazy a variable that we can reasonably blame too-early optimization for a non-negligible chunk of lousy UX and unmaintainable code.

The latest Guide to Performance and Monitoring covers both the static and dynamic, the verifiable and the unknowable sides of building and maintaining performant applications.

As Tony Hoare notoriously observed, "Premature optimization is the root of all evil:" that is, the benefits of absolutely maximal optimization are usually much lower than the increased cost of maintenance and debugging that results from the brittleness caused by that optimization. On the other hand, the natural tendency of OOP to prioritize form over performance can generate a codebase that is highly readable but partitioned such that performance-oriented refactoring may prove extremely difficult. To help you steer between the Scylla of overeager optimization and the Charybdis of runtime-indifferent code structure, we've split this publication between ways to design performant systems and ways to monitor performance in the real world. To shed light on how developers are approaching application performance, and what performance problems they encounter (and where, and at what frequency), we present the following points in summary of the four most important takeaways of our research.

1) Application code is most likely to cause performance problems frequently; database performance problems are most challenging to fix:

DATA: Frequent performance issues appear most commonly in application code (43% of respondents) and in databases second most commonly (27%). Challenging performance issues are most likely to appear in the database (51%) and second in application code (47%).

IMPLICATIONS: Enterprise application performance is most likely to suffer from higher-level, relatively shallow suboptimalities. Deep understanding of system architecture, network topology, and even pure algorithm design is not required to address most performance issues.

RECOMMENDATIONS: Optimize application code first and databases second (all other things being equal). On first optimization pass, assume that performance problems can be addressed without investing in superior infrastructure.

2) Parallelization is regularly built into program design by a large minority (but still a minority) of enterprise developers:

DATA: 43% of developers regularly design programs for parallel execution. Java 8 Parallel Streams are often used (18%), slightly more frequently than ForkJoin (16%). ExecutorService was most popular by far, with 47% using it often. Race conditions and thread locks are encountered monthly by roughly one fifth of developers (21% and 19% respectively). Of major parallel programming models, only multithreading is often used by more than 30% of developers (81%).

IMPLICATIONS: Enterprise developers do not manage parallelization aggressively. Simple thread pool management (ExecutorService) is much more commonly used for concurrency than upfront work splitting (ForkJoin), which suggests that optimization for multicore processors can be improved.

RECOMMENDATIONS: More deliberately model task and data parallelization, and consider hardware threading more explicitly (and without relying excessively on synchronization wrappers) when designing for concurrency.

3) Performance is still a second-stage design consideration, but not by much:

DATA: 56% of developers build application functionality first, then worry about performance.

IMPLICATIONS: Extremely premature optimization is generally recognized as poor design, but performance considerations are serious enough that almost half of developers do think about performance while building functionality.

RECOMMENDATIONS: Distinguish architectural from code-level performance optimizations. Set clear performance targets (preferably cascading from UX tolerance levels) and meet them. Optimize for user value, not for the sake of optimization.

4) Manual firefighting, lack of actionable insights, and heterogeneous IT environments are the top three monitoring challenges:

DATA: 58% of respondents count firefighting and manual processes among the top three performance management challenges. 49% count lack of actionable insights to proactively solve issues. 47% count rising cost and complexity of managing heterogeneous IT environment.

IMPLICATIONS: Performance management is far from a solved problem. Monitoring tools and response methods are not providing insights and solutions effectively, whether because they are not used adequately or need feature refinement.

RECOMMENDATIONS: Measure problem location, frequency, and cost, and compare with the cost (both monetary and performance overhead) of an additional management layer. Consider tuning existing monitoring systems or adopting new systems (e.g. something more proactive than logs).

More Stories By John Esposito

John Esposito is Editor-in-Chief at DZone, having recently finished a doctoral program in Classics from the University of North Carolina. In a previous life he was a VBA and Force.com developer, DBA, and network administrator. John enjoys playing piano and looking at diagrams, and raises two cats with his wife, Sarah.

@DevOpsSummit Stories
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost and increase in speed. Sometimes in order to reduce complexity teams compromise features or change requirements
GCP Marketplace is based on a multi-cloud and hybrid-first philosophy, focused on giving Google Cloud partners and enterprise customers flexibility without lock-in. It also helps customers innovate by easily adopting new technologies from ISV partners, such as commercial Kubernetes applications, and allows companies to oversee the full lifecycle of a solution, from discovery through management.
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rather than mimicking legacy server virtualization workflows and architectures.
Using serverless computing has a number of obvious benefits over traditional application infrastructure - you pay only for what you use, scale up or down immediately to match supply with demand, and avoid operating any server infrastructure at all. However, implementing maintainable and scalable applications using serverless computing services like AWS Lambda poses a number of challenges. The absence of long-lived, user-managed servers means that states cannot be maintained by the service. Longer function invocation times (referred to as cold starts) become very important to track, because they impact the response time of the service and will impose additional cost. Additionally, the transition to smaller individual components (much like breaking a monolithic application into microservices) results in a simpler deployment model, but makes the system as a whole increasingly complex.
In 2014, Amazon announced a new form of compute called Lambda. We didn't know it at the time, but this represented a fundamental shift in what we expect from cloud computing. Now, all of the major cloud computing vendors want to take part in this disruptive technology. In his session at 20th Cloud Expo, John Jelinek IV, a web developer at Linux Academy, will discuss why major players like AWS, Microsoft Azure, IBM Bluemix, and Google Cloud Platform are all trying to sidestep VMs and containers with heavy investments in serverless computing, when most of the industry has its eyes on Docker and containers.