At QCon London, Adam Tornhill presented “A Crystal Ball to Prioritise Technical Debt”, and discussed that although the technical debt metaphor has taken the software world with storm, most organizations find it hard to prioritise and repay their technical debt. A key takeaways from the talk…
At QCon London , Adam Tornhill presented  » A Crystal Ball to Prioritise Technical Debt « , and discussed that although the technical debt metaphor has taken the software world with storm, most organizations find it hard to prioritise and repay their technical debt. Key takeaways from the talk included: methods to identify ‘hotspots’ of code complexity and churn; the benefit of continually evaluating the suitability of the architecture for the current system, for example, by examining ‘temporal coupling’ of components or microservices; and that the cost of inter-team coordination can often be learned from examining the social metadata associated with code commits within a version control system.
Tornhill , founder and CTO at Empear, began the talk by quoting Martin Fowler in regards to the problems caused by technical debt: « Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development ». In relation to this, three propositions were stated: technical debt interest rate is a function of time spent working on the system; that all technical debt is not created equal; and most technical debt is not actually ‘technical’ – there is a strong link between technical debt and the organisation that produced the code.
Tornhil continued by suggesting that a ‘wish list’ of questions and information required to effectively priortise technical debt would include:
The code with the highest technical debt interest rate may be found using ‘hotspot’ analysis, which can be used to visually represent areas of the code base that are large, complex, or have high churn rates. Size and complexity of code can be determined with traditional tooling, such as Sonar Qube or Code Climate , and churn rates and other social information can be obtained from the version control system (VCS) in which the codebase resides by using tools such as Tornhill’s Code Maat. Visualisation and analysis tools, such as Moose or CodeScene , can be used to explore and understand the findings from hotspot analysis.
With a nod to George Orwell’s Animal Farm, Tornhill quipped that « all code is equal, but some code is more equal than others », and demonstrated graphically that over the long term the high churn within the codebases of several popular languages was clearly localised to several areas of the code (with a corresponding long tail). Citing the example file gc.cpp from the open source. NET coreclr project, this localisation of churn can also be seen to be true at a function/method level as much as at the Class/file level. Concluding this section of the talk, it was suggested that these ‘hotspots’ should be priortised for refactoring in order to reduce the technical debt interest rate, and that corresponding complexity trends of this code be supervised over time.
Next, the question of « Does the architecture support the way the system evolves?  » was explored. Each system has a ‘tipping point’, in which complexity grows to be unmanageable, and code modifications become extremely difficult. Complexity should be regularly supervised, and the tipping point identified and avoided by appropriate redesign and refactoring. Analysing ‘ Temporal Coupling ‘ is extremely useful for identifying if two or more components (classes, layers, modules, microservices) are constantly being modified at the same time – implying a architectural dependency that is not obvious from simply analysing the code itself. The ‘microservices shotgun surgery pattern’ should be identified and avoided, and if additions or changes to the application regularly require the coordinated change across multiple services, then the architectural service boundaries may have been specified incorrectly.
The final part of the talk focused on the social side of developing software, and began by stating that there is often high ‘process loss’ from the potential productivity of all developers combined working on the codebase. Team coordination, or the ‘diffusion of responsibility’, can be measured using VCS analysis looking for areas of the code where commits from developers across multiple team overlaps. Tornhill proposes that this is a way to visualise and measure  » Conway’s Law « . The use of feature teams can lead to large areas of the codebase requiring inter-team coordination, which is costly and often results in inconsistently applied standards and styling. It was strongly suggested to « align your architecture and your organisation » in order to reduce the increase of technical debt.
The talk was concluded with a strong recommendation to make design, implementation and refactoring decisions influenced by data. Tornhill believes that as the systems that are being developed increase in complexity, this is becoming an essential practice, and accordingly has distilled his thinking into the Pragmantic Programmer’s book  » Your Code As a Crime Scene « .
The slides for Adam Tornhill’s QCon London talk,  » A Crystal Ball To Prioritize Technical Debt « , can be found at the conference website. The public availability of the conference talk recordings can also be found on the QCon London website.

© Source: http://www.infoq.com/news/2017/04/tornhill-prioritise-tech-debt?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=news
All rights are reserved and belongs to a source media.

At QCon London, Sarah Wells presented “Avoiding Alerts Overload from Microservices”, and cautioned that developers and operators must fundamentally change the way they think about monitoring when building a microservice system. Key takeaways included: build a system that can be supported; focus on ‘stuff that…
At QCon London , Sarah Wells presented  » Avoiding Alerts Overload from Microservices « , and cautioned that developers and operators must fundamentally change the way they think about monitoring when building a distributed microservice-based system. Key takeaways included: build a system that can be supported; focus on monitoring ‘stuff that matters’, such as core user journeys and business functionality, when creating monitoring and alerts; and continually and proactively cultivate and improve alerts.
Wells , a Principal Engineer at Financial Times, began the talk by stating that knowing when there is a problem is not enough, an alert must only be triggered when an action by a human is required. A microservices architecture may allow the development team to move fast, but there is an operational cost, and the number (and complexity) of alerts generated by a microservice-based system can be overwhelming.
The FT.com website is powered by a microservice backend, primarily utilising the Java and Go programming languages, packaged and deployed with Docker and CoreOS onto the Amazon Web Services (AWS) platform. Data stores included mongoDB, elastic, neo4j and Apache Kafka. There are 99 functional services (with 350 running instances at any given time), and 52 non functional services (with 218 running instances). Wells stated that if each of the 568 service instances were checked every minute, this would result in 817,920 checks per day. Running containers on shared Virtual Machines (VMs) requires 92,160 system-level checks, for a total of 910,080 checks per day. In addition, any microservice-based application is a distributed systems, and accordingly services do not run independently. If something fails, it can often lead to cascade failures, which further complicates monitoring and alerting.
With a microservice-based application, which is inherently a distributed system, you have to change how you think about monitoring
In order to adapt to the challenges of monitoring a microservices-based application, Wells suggested a three-pronged approach: build a system that can be supported; concentrate on « stuff that matters »; and cultivate alerts and the information they contain.
In order to build a system that can be supported, the following basic tools are required:
FT.com microservices alert dashboard, which is powered by the dashing.io framework
When developing polyglot services, logging and monitoring integration must be made easy for any language that is used. The expectations, or operational contract, must be specified, and each service owner is responsible for implementing functionality to meet this requirement. For example, the FT healthcheck standard requires that every service expose a healthcheck endpoint over HTTP, ‘http://service/__health’, which returns a 200 if the service can run the healthcheck, and a JSON document containing multiple checks that can contain additional information but must return ‘ »ok »:true’ or ‘ »ok »: false’.
A core goal of monitoring and alerting is to know about problems before clients do, and accordingly the practice of running ‘ synthetic requests ‘ that mimic user functionality behaviour is vital. If functionality relating to a key user journey is broken, for example, an FT editor cannot publish a new article, then this must be fixed immediately i.e. « concentrate on the stuff that matters ». The FT technical team have also created dashboards showing core client statistics, such as number of errors, and response latency, but Wells stressed that it is « the end-to-end [business functionality] that matters ».
A microservices architecture lets you move fast, but there is an associated operational cost. Make sure it’s a cost you’re willing to pay
Alerts must continually be cultivated, and if an alert is received that doesn’t make sense, or does not require human interaction, it must be corrected or removed. If an issue occurs, and there was no alert, then one should be added as part of the fix. Key information must be included within each alert, for example, an overview of the business impact, the associated run book location, and corresponding transaction ids that triggered the issue. The FT team use dedicated ‘Ops Cops’ (on-call members of the development team, rotated regularly) to watch for issues with monitoring, and have integrated alerting within the team’s Slack messaging system. A pre-defined list of emojis are used to indicate when and how an issue is being managed and resolved.
Concluding the talk, Wells suggested that creating alerts should be part of the normal development workflow « code, test, alerts ». In order to ensure that the development team know if an alert stops working, tests should be added to validate the alert. The FT technical team subscribe to the philosophy of chaos testing, and inspired by Netflix’s Simian Army and Chaos Monkey, they have created a ‘Chaos Snail’ (which is « smaller than a monkey, and written in Bash shell »!). Wells cautioned that proactivity is required when maintaining and dealing with alerts in a non-trivial system, and out of date information can be worse than none at all. Automate updates wherever possible, and find ways to share what is changing.
The slides for Sarah Wells QCon London talk,  » Avoiding Alerts Overload From Microservices  » can be found on Speaker Deck. The public availability schedule of the conference talk recordings can be found on the QCon London website.

© Source: http://www.infoq.com/news/2017/04/avoid-alert-overload-services?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=news
All rights are reserved and belongs to a source media.