Advancing application reliability with the Azure Well-Architected Framework

If you want to start a good discussion or argument about reliability at work, ask a colleague this question.

"When is architecture more important for the reliability of a service, product, or application? Before it is deployed to production, or afterward?"

Well, “surely”—you say—“if we don’t build the service with reliability in mind, it may not have the right components included to increase stability. It may not have redundancy to improve fault tolerance. Perhaps we will have left out robust retry logic, circuit breakers, or other known patterns for reliable systems.”

But maybe your colleague counters, “Well, I can’t deny that it is important to attempt to try and build things right from the beginning. But one thing I’ve learned about reliability is it is almost never achieved on the first go around. Even if you have done a phenomenal job at the whiteboard, designing with failure in mind, there are still going to be outages. And while nobody likes outages, if we handle them and a subsequent post-incident review correctly, we can learn a great deal that helps us make a service more reliable in the long term. On top of this, wouldn’t you agree that observability is an iterative process that involves changing what we measure and monitor as we learn more about the system while it is running? All these things would fall under the mantle John Reese and Niall Murphy called 'the wisdom of Production'. And all of these things surely need us to bring to bear all the architecture skills we have to do this right.”

If you are having a really good discussion, this goes back and forth across the table at least a few times. One side notes that “bolting on reliability after the fact” works about as well as “bolting on security after the fact” (that is to say, not well at all). The other side might bring up the lessons we’ve learned from chaos engineering showing us that experiments on a dev or staging environment can be very useful, but they don’t always yield some of the unique results we get from testing in production.

“But what about the value of continuous integration and continuous delivery (CI/CD) to reliability—trying to catch reliability issues before they get to production?”, gets asked. Then in response, “CI/CD is tremendously useful, but it didn’t catch our last issue because tests for large distributed systems are notoriously hard to get right.” And so on, and so on.

By now you’ve probably come to the same conclusion the people in this argument are bound to reach. Architecture is important in both the pre-production and post-production lifecycle stages. But that conclusion still leaves us in a peculiar spot because we don’t normally think about architecture or the role of an architect after something has been built. We don’t expect the architect who helped us build our house to show up at the doorstep a year later to say “OK, let’s do some more architecting.”

With the applications we build (or purchase) to run, things are different. There we have an expectation that the software will be changed at a much more rapid pace. It will be refactored, it will be enhanced, it will be upgraded. At each of these points, we must apply everything we know from the realm of architecture if we expect the result to be reliable. So let me tell you about one way to settle the debate we’ve been discussing, and also show you a tool that can help with your reliability even as we are squaring that circle.

The Azure Well-Architected Framework

The Well-Architected Framework is a set of guiding tenets that can be used to improve the quality of a workload. The framework consists of five pillars of architecture excellence: Cost Optimization, Operational Excellence, Performance Efficiency, Reliability, and Security. Incorporating these pillars helps produce high-quality, stable, and efficient cloud architecture.

But there’s that word “architecture” again, basically sitting right in the middle of the name and taunting us with an image of an architect who only participates at the beginning of the lifecycle.

Here’s the key to unlocking this conundrum: For reliability (and the other four pillars) the goal is to work towards and remain in a “well-architected state.”

That’s a state that strives to embody and make use of the best practices and all the accumulated knowledge from architecture meticulously embedded in the Well-Architected Framework. This guidance is meant to be useful to you at all stages of a cloud solution. It is useful to you in the beginning when you are designing your workloads. It is useful to you when you begin your periodic review of the workload as part of the refactoring, scaling, enhancing, or upgrading process. And finally, it can help when the cycle starts anew for the next major version of your workload.

How to get there

Anyone who has worked in the reliability space, even for a short while, knows that while a large body of guidance like the Well-Architected Framework is great, the tricky part is applying that knowledge to your specific workloads and efforts in flight. Just navigating a large document set like the Well-Architected Framework and determining where to start can be a challenge. I’d like to introduce you to a tool that I believe can bridge your ground truth and the guidance we offer. It can serve as our compass to this material.

The Well-Architected Review is a self-guided assessment tool that will walk you through the Well-Architected Framework reliability pillar and the other four Well-Architected Framework pillars. This is a great process to do either by yourself, with your friendly neighborhood Cloud Solutions Architect, or supporting partners. It will ask you a set of questions about your reliability efforts—then, based on your responses, it offers suggestions on areas to focus on with direct links to our WAF documentation on those areas.

Here’s an example set of results:

Let me offer a few tips that might not be obvious at first look for getting the most out of the Well-Architected Review:

1. Pay attention to the questions: You might think the results of the review are the biggest reward, but I’m here to tell you that the most valuable thing you may be able to take away from the review is the questions. Reliability can be a tricky area to tackle because there are so many possible ways to begin working on it, so many different places to start. Just knowing which questions to ask can be difficult. The Well-Architected Review can give you those questions.

2. Return to the review again and again: If you sign into the review platform with your Microsoft credentials, you can save the results. This means that in six months, or whenever you feel ready to conduct another review, you will be able to compare your new review to your previous information. This can be tremendously helpful for judging your progress across each pillar.

3. Share the results with your team: One thing many people don’t know about the Well-Architected Review is if you have signed in (see tip number two above), it will allow you to export your results as a Microsoft PowerPoint presentation. Take this draft, customize it, and you now have a ready-made presentation to take to your next team meeting so everyone can get behind your reliability efforts.

The Well-Architected Framework in action

If you would like to see some examples of the Well-Architected Framework in action, including some excellent sessions about reliability, I encourage you to check out the videos in the Well-Architected series of our Azure Enablement show. There’s some good online course material about the subject in Microsoft Learn, and guiding principles in our documentation. If you want to dive deeper into the architecture side of Well-Architected, I recommend checking out the Azure Architecture Center.

Source: microsoft.com

Continue reading

Advancing resiliency threat modeling for large distributed systems

At a high level, our goal is to avoid self-inflicted and/or avoidable outages, but even more immediately, our goal is to be able to reduce the likelihood of impact to our customers as much as possible. In this context, an outage is any incident in which our services fail to meet the expectations of (or negatively impact the workloads of) our customers, both internally and externally. To avoid that, we needed to improve how we uncover risks before they impact customer workloads on Azure. But Azure itself is a large, complex distributed system—how should we approach resiliency threat modeling if our organization offers thousands of solutions, comprised of hundreds of “services,” each with a team of five to 50 engineers, distributed across multiple different parts of the organization, and each with their own processes, tools, priorities, and goals? How do we scale our resiliency threat modeling process out, and reason across all these individual risk assessments? To address these challenges, it took some major changes to join the reactive approach with the more proactive approach.

Starting our journey

We started the shift left with a premortem pilot program. We looked back at past outages and developed a questionnaire that helped not only to start discussions but also to provide a structure to them. Next, we selected several services of varying purpose and architecture—each time we sat down with a team, we learned something new, got better and better at identifying risks, incorporated feedback from the teams on the process, then tried again with the next team. Eventually, we started to identify the right questions to ask as well as other elements we needed to make this process productive and impactful. Some of these elements already existed, others needed to be created to support a centralized approach to resiliency threat modeling. Many that existed also required changes or integration into an overall solution that met our goals. What follows is a high-level overview of our approach, and the elements we discovered were necessary to continue improving the space.

Read More: MS-203: Microsoft 365 Messaging

We created a culture of continuous and fearless risk documentation

We realized that there would need to be a large up-front investment to find out where our risks were. Thorough premortems take time—the valuable and "in high demand" engineer kind of time, the "we are working within a tight timeline to deliver customer value and can’t stop to do this" kind of engineer time. Sometimes we needed to help them understand that, even though their service only had one outage in two years, there are dozens of other services in the dependency chains of our solutions that have also only had one outage in the past two years. The point is that, from our customers’ perspective, they have seen more than “just” two outages.

We should be skeptical that low risk is something we can safely ignore. We must embark on healthy, fearless searching inventory of risks to outages. We needed a process that not only supports detailed discussions of lingering issues, and an assessment of the risks without fear of reprisal, but also informs investments in common solutions and mitigations that can be leveraged broadly across multiple services in a large-scale organization consisting of hundreds or thousands of services.

Our goal is a continuous search for risks, and to have "living risks" threat models instead of static models that are only updated every X months. Once the initial investment to find that initial set of risks lands, we wanted to keep things up to date with a well-defined process. The key at first was not to be deterred by how large the initial investment "moat" was, between us and our goals. The real benefit we see now is that risk collection is built into our culture. This enables risks to be collected from many diverse sources and built into our organizational processes.

So, how best to start the process of identifying risks?

We used both reactive and proactive approaches to uncovering risks

We leveraged our postmortem analysis program

While looking for risks, it makes sense to look at what has happened in the past and search for clues to what can happen again in the future. A solid postmortem analysis program was key in this regard. We already had a team that analyzed postmortems, looking for common themes and surfacing them for deeper analysis and to inform investments. Their analyses helped us not only route teams to quality programs or initiatives that could help address the risk, but also highlighted the need for other investments we did not know we needed until we saw how prevalent the risk was. The types of risk categories they identified from postmortem analysis became a subset of our focus areas when we looked for risks that had not happened yet. It is worth noting here that postmortem analysis is only as good as the postmortem itself.

We leveraged our postmortem quality review program

The quality of a postmortem determines its usefulness, therefore we invested in a Postmortem Quality Review Program. Guidance was published, training was made available, and a large pool of reviewers would rate each "high impact" outage postmortem after it was written. Postmortems that had low ratings or needed more clarity were sent back to the authors. High impact postmortems are reviewed weekly in a meeting that includes engineers from other teams and senior leaders, both of whom ask questions and give feedback around the right action plans. Having this program vastly increased our ability to learn from and act on postmortem data.

However, we knew that we could not limit our search for risks to the past.

We got better at premortems to be more proactive

Some may have heard the term “premortem,” which is a similar process to a Failure Mode Analysis (FMA).

According to the Harvard Business Review (September 2007, Issue 1), “A premortem is the hypothetical opposite of a postmortem. A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient. A premortem in a business setting comes at the beginning of a project rather than the end so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure.”

In the context of Azure, the goal of a premortem is to predict what could go wrong, identify the potential risks, and mitigate or remove them before the trigger event results in an outage. According to How to Catch a Black Swan: Measuring the Benefits of the Premortem Technique for Risk Identification, premortem techniques can identify more quality risks and propose more quality changes; it is a more effective risk management technique compared with others.

Conducting a premortem is not a terribly difficult endeavor, but you must be sure you involve the right set of people. For a particular customer solution, we gathered the most knowledgeable engineers for that solution and, even better, brought the new ones so they can learn. Next, we had them brainstorm as many reasons as possible why they may be woken up at 4:00 AM because their customers are experiencing an outage that they must mitigate. We like to start with a hypothetical question, “Imagine you were away on vacation for two weeks and came back hearing that your service had an outage. Before you find out what the contributing factors were for that outage, attempt to list as many things as possible you think could be the likely causes.” Each of those was captured as a risk, including documenting the triggers that cause the outage, the impact on customers, and the likelihood of it happening.

After we identified the risks, we needed to have an action plan to address them.

We created “Risk Threat Models”

If premortem is the searching and fearless inventory of risks, the risk threat model is what combines that with the action plan. If your team is doing failure mode analysis or regular risk reviews, this effort should be straightforward. The risk threat model takes your list of risks and builds in what you expect to do to reduce customer pain.

After we identified the risks, we needed to have a common understanding of the right fixes so that those patterns could be used everywhere there was a similar risk. If those fixes are long-term, we asked ourselves “what can we do in the meantime to reduce the likelihood or impact to our customers”? Here are some of the questions we asked:

◉ What telemetry exists to recognize the risk when it is triggered? 

◉ What if this happens tomorrow? What guardrails or processes are in place until the final fix is completed?

◉ How long does it take to do this interim mitigation and is it automated? Can it be automated? Why not?

◉ Has the mitigation been tested? When was the last time you tested it?

◉ What have you done to ensure you have added the most resiliency possible, for instance, if your critical dependencies have an outage? Have you worked with that dependency to ensure you are following their guidance and using their latest libraries?

◉ Are there any places where you can ask for an increase in COGS to be more resilient?

◉ What mitigations are you not doing due to the cost or complexity or because you do not have the resources?

Risk Mitigation Plans were documented, aligned with common solutions, and tracked. Any teams that indicated the mitigations would need more developers or money to implement needed mitigations were provided a forum to ask for it in the context of resiliency and quality. Work items were created for all the tasks needed to make the service as resilient as possible and linked to the risks we documented so we could follow up on their completion.

But how do we know we are precluding the risk correctly? How do we know what the "right" mitigation strategies are? How could we reduce the amount of work it took, and prevent everyone from solving the same problem in a custom way?

We created a centralized repository of all risks across all services

Risks Threat Models are more effective when captured and analyzed centrally

If every team went off and analyzed their postmortems, conducted a premortem, created a risk threat model, and then documented everything separately there is no doubt we would be able to reduce the number of outages we have. However, by not having a way for teams to share what they found with others, we would have missed opportunities to understand broader patterns in the risk data. Risks in one service were often risks in other services as well, but for one reason or another, it did not make it into the risk threat models of all services that were at risk. We also would not have noticed that unfinished repairs or risks in one service are risks to other services. We would have missed the chance to document patterns that will prevent this risk from appearing elsewhere when a new service is spun up. We would not have realized that the scope of a premortem should not be limited to individual service boundaries, but rather done across all the services that work together for a particular customer scenario. We would have missed opportunities to propose common mitigation strategies and invest in broad efforts to address mitigations at scale using the same mitigation plan. In short, we would have missed many opportunities to inform numerous investments across service boundaries.

We implemented a common way of categorizing risks

In some cases, we knew we needed to understand what "types" of risks we were finding. Were they Single Points of Failure? Insufficiently configured throttling? To that end, we created a hierarchical system of shorthand “tags” that were used to describe categories of issues on which we wanted to focus. These tags were used for analyzing postmortems to identify common patterns, as well as marking individual risks so that we could better look across risks in the same categories to identify the right action plans.

We had regular reviews of the Risk Threat Models

Having the completed Risk Threat Models enabled us to schedule reviews in front of senior leadership, architects, members of the dedicated cross-Azure Quality Team, and others. These meetings were more than just reviews, they provided an opportunity to come together as a diverse team to identify areas for which we needed common solutions, mitigations, and follow-up actions. Action items were collected, owners assigned, and risks were then linked with the action plans so we could follow up down the road to determine how teams progressed.

It all came together, time to take it to the next level and do this for hundreds of services!

In summary, it took more than just spinning up a program to identify and document risks. We needed to inspire, but also have the right processes in place to get the most out of that effort. It took coordination across many programs and the creation of many others. It took a lot of cross-service-team communication and commitment.

Accelerating the resiliency threat modeling Program has already yielded many benefits for our critical Azure services, so we will be expanding this process to cover every service in Azure. To this end, we are continuously refining our process, documentation, and guidance as well as leveraging past risk discussions to address new risks. Yes, this is a lot of work, and there is no silver bullet, and we are still bringing more and more resources into this effort, but when it comes to reliability, we believe in “go big”! 

Source: microsoft.com

Continue reading

Power your genomic data analysis on Azure with Azure CycleCloud

Researchers around the world have access to a greater variety and volume of genomics data than ever before. Genomics is now available to a vast majority of researchers, pushing forward the discovery at a tremendous pace and changing people’s lives. This growth is happening because of the perfect storm between genomic testing and technological improvements. In the span of a few decades, the cost of human genome sequencing has gone from millions of dollars to hundreds of dollars.

At Microsoft, we recognize the challenges faced by the genomics community and are striving to build an ecosystem (backed by open source and Microsoft products and services) that can facilitate genomics computing work for all. We’ve focused our efforts on 3 main core areas: research and discovery in genomics data, building out a platform to enable rapid automation and analysis at scale, and optimized and secure pipelines at a clinical level. One of the core Azure services that has enabled us to leverage an HPC environment to perform the genomic analysis is Azure CycleCloud.

Genomic analysis at scale requires hyperscale compute

Sequencing a single individual’s genome, or even that of a small cohort of individuals, generates a significant amount of data and requires a massive amount of computational power to analyze. The computing power required to effectively analyze, share, and disseminate this data has historically been constrained by what could be provided on-premises for research organizations. For most researchers, the scarcity of availability of high performance computing (HPC) clusters has hamstrung their research potential, threatening high upfront infrastructure investments and long-term maintenance costs. Furthermore, to capture an accurate representation of population health, research studies today need to be globalized meaning that genomic data needs to be securely stored, shared, and transmitted across the world—creating a computing demand that is a heavy lead for even the most sophisticated on-premises. As such, the lack of adequate computing technology has delayed and constrained the ability of genomic research communities to easily collaborate and share findings. 

Cloud computing and the broader digital transformation of the health industry have been powerful enablers of modern genomic breakthroughs, unleashing a practically limitless—and more widely and affordably available—ability to meet the computing demands needed by research organizations and medical institutions to advance genomic science.

HPC on Azure and Azure CycleCloud for genomic analysis

Azure CycleCloud is an enterprise-friendly tool for orchestrating and managing HPC environments on Azure. With Azure CycleCloud, users can provision infrastructure for HPC systems, deploy familiar HPC schedulers, and automatically scale the infrastructure to run jobs efficiently at any scale. Through Azure CycleCloud, users can create different types of file systems and mount them to the compute cluster nodes to support HPC workloads. With dynamic scaling of clusters, the business can get the resources it needs at the right time and the right price, with Azure CycleCloud’s automated configuration enabling IT to ultimately focus on providing high-value services to the business users.

Workflow managers (like Cromwell, Galaxy, Nextflow, and Snakemake) are used for accelerating genome analysis by making them more efficient and scalable. For instance, a typical next-generation sequencing machine can sequence anywhere from 12 to 192 samples per run and creates an output file (called Binary Base Call [BCL] are the raw data generated by NGS). This output file is converted into several FastQ files (FastQ file is a text-based format for storing both a nucleotide sequence and its corresponding quality score). Each FastQ must be further converted into BAM Format (a binary format for storing sequence data) and then Variant Call Format (VCF), which specifies the format of a text file used in bioinformatics for storing gene sequence variations. A bioinformatician or a clinical scientist then picks these files up for further analysis. The sequence of conversion steps from BCL to FASTQ files can take between several hours to several days on commodity hardware. One way to drastically reduce this timeline is to use Azure CycleCloud or Azure Batch to configure these steps as a set of jobs that can be run in parallel.

Accelerating germline testing by optimizing secondary analysis using Azure CycleCloud

Belfast Health and Social Care Trust is the largest integrated health and social care trust in the United Kingdom. They deliver integrated health and social care services to approximately 340,000 citizens in Belfast and provide many regional specialist services to all of Northern Ireland. Belfast Trust also comprises the major network of teaching and training hospitals in Northern Ireland.

Within Belfast Trust, the Regional Molecular Diagnostics Service Northern Ireland (RMDS) has been funded to develop and deliver a service that provides molecular testing of germline and somatic disorders through the introduction of a comprehensive portfolio of Next Generation Sequencing (NGS) panels and exomes aimed at improving patient outcomes in Northern Ireland.

The main goal of this strategic initiative is to enhance high-quality patient care by improving the turnaround time for genomic analysis in accordance with the best practice guidelines by The Association for Clinical Genomic Science and delivering an equitable molecular service in line with mainland United Kingdom labs.

Initially, the sheer complexity and size of the genomic data generated were considered a major computational barrier to the delivery of the service. To meet the computational demand, Belfast Trust developed an accredited germline computational pipeline using the Snakemake workflow manager on Azure. The initial pipeline analyzed only targeted panels, which are smaller in size than clinical exomes, whole exomes, or whole genomes. To convert the raw data to the format necessary for genomic analysis, the jobs were configured for sequential execution on a single virtual machine.

The challenge arose when analyzing clinical exomes, whole exomes, or whole genomes, whose larger size made the analysis more complex and time-consuming. For instance, a 12-sample targeted panel analysis could be completed in two hours. However, it took 48 hours to execute a complete analysis of a 12-sample clinical exome. To solve this problem, Belfast Trust worked with Microsoft Consulting Services to identify ways to reduce the complexity and time for analyzing these larger data sets. Azure CycleCloud was leveraged to parallelize the pipeline execution.

The resulting solution was executed on several virtual machines in parallel to analyze the sample pipeline jobs, with astounding results. A 12-sample targeted panel analysis was completed in 20 minutes and a 12-sample clinical exome analysis was completed in 4 hours and 30 minutes, a 6 to 10 times improvement in analysis duration. The virtual machines utilized in the solution were also smaller in size compared to what was previously used, which brought down the cost of the entire pipeline by roughly 3 times.

“We were able to extend our service by overcoming computational barriers for testing of germline disorders by leveraging HPC on Azure. In collaboration with Microsoft Consulting Services, the Belfast Trust has developed an end-to-end Azure Cloud-based solution for data transfer, pipeline analysis, tertiary analysis, and storage solutions for genomic data. Through this collaboration, and leveraging Azure CycleCloud for analysis, we were able to save analysis time by 6 to 10 times and reduce the cost of analysis by roughly 3 times. This will enable us to expand our capacity to undertake more analysis and testing.”—Shirley Heggarty Ph.D. FRCPath, Director, Regional Genetics Laboratory, Belfast City Hospital

This optimized solution will allow Belfast Trust to manage resources and scale up its sequencing runs more efficiently in the future.

Genomics research is playing an increasingly central role in precision medicine—refining diagnoses, prescribing personalized treatments for patients, and helping us have an even deeper understanding of human health. The advancements of on-demand, geographically available, and affordable HPC services will play a critical role for research organizations and technology partners alike to continue to build with purpose—and to chase new breakthroughs in the field of genomics.

Source: microsoft.com

Continue reading

Bring cloud experiences to data workloads anywhere with Azure SQL enabled by Azure Arc

From edge to cloud, companies are eager to find innovative solutions that meet them where they are. Today’s business environment is increasingly complex, and customers tell us they need solutions that are multi-cloud, platform-agnostic, and offer integrated apps and services that are always up to date. We’ve seen firsthand the best solution combines a company’s existing infrastructure with the simple, distributed computing power of the cloud. Our unique approach to hybrid gives businesses choice and flexibility in managing their entire data estate while complying with data sovereignty, regulation, and latency requirements.

Read More: AZ-600: Configuring and Operating a Hybrid Cloud with Microsoft Azure Stack

Tune in to the Azure Hybrid and Multi-cloud Digital Event from 9:00 – 11:00 AM Pacific Time to learn more about the latest announcements about Azure Arc-enabled data services. And today, we’re announcing the general availability of Azure SQL enabled by Azure Arc to help customers manage their data and databases simply and efficiently. Customers can deploy cloud services on-premises and in multi-cloud environments—effectively modernizing in place by running Azure SQL on any infrastructure.

Cloud solutions that simplify the most complex hybrid data scenarios

Deploying cloud-based solutions to on-premises and multi-cloud environments helps deliver consistent, portable, and unified management across a company’s entire data estate. Our customers are seeing improved productivity and operating efficiency by using hybrid technology to manage their data and app development at scale.

For example, SKF provides reliable rotation to industries all over the world, offering products and services around the rotating shaft including bearings, seals, lubrication management, artificial intelligence, and wireless condition monitoring. SKF has been on a journey to digitally transform the company’s backbone through harnessing the power of technology, interconnecting processes, streamlining operations, and delivering industry-leading digital products and services for customers. SKF uses Azure Arc, along with Azure Stack HCI and Azure SQL Edge, to scale solutions and standardize processes across their 91 manufacturing sites, resulting in 40 percent savings on hardware costs and 30 percent savings in OT-related machine downtime.

“SKF’s focus is on digitalizing all segments of the value chain and interconnecting them to unlock the full potential of digital ways of working for our business and customers. Azure Arc-enabled SQL Managed Instance is providing us worry-free and always up-to-date SQL operations. These types of services provide us a tremendous jumpstart into digitalization.”—Sven Vollbehr, Head of Digital Manufacturing, SKF

The “anywhere” solution for hybrid cloud applications

Beginning July 30, 2021, the general-purpose tier of Azure Arc-enabled SQL Managed Instance will be generally available, providing database-as-a-service (DBaaS) functionality on any infrastructure. Businesses will be able to deploy Azure SQL databases on any infrastructure and on any Kubernetes to:

◉ Stay current with automated updates and deploy evergreen feature and security updates to on-prem databases with no end-of-support.

◉ Automate routine database administrator (DBA) tasks at scale with built-in management capabilities including high availability, backup, and restore.

◉ Optimize data workload performance by bringing cloud elasticity on-premises for existing infrastructure, using only the resources needed to dynamically scale up, down, without application downtime.

◉ Access Azure industry-leading security and governance capabilities for your on-premises data workloads using to protect your data.

New product features and capabilities will be rolled out on a continuous basis, and customers will be able to opt-in to preview additional Azure Arc-enabled services, such as PostgreSQL, and easily integrate as they become generally available. Additionally, customers will have the opportunity to test out future road map preview features and provide early feedback.

Develop breakthrough applications with our network of trusted partners

In support of Azure Arc-enabled data services' general availability, we are announcing an expanded network of trusted partners and validated solutions to help customers get started.

Our team works closely with technology providers to validate popular platforms to work with Azure Arc, and our many service providers are here to provide customers with the latest innovations for hybrid data solutions on-premises or in multi-cloud environments.

Whether you are just getting started with migration and modernization efforts or in the middle of a multi-year digital transformation, our consulting services partners can help you choose the validated infrastructures and applications that are specifically configured and tested to work with Azure Arc.

Source: microsoft.com

Continue reading

Practical Guide for Microsoft MB-300 Exam Preparation

The Dynamics 365 certification confirms developers' skills working with Finance and Operations apps in Microsoft Dynamics 365. It gauges their skill to use standard functionality, manage Finance and Operation data, and implement tools. The certification expects the applicants to give fully realized solutions. An applicant needs to take two exams to obtain this certification, i.e., Microsoft Dynamics 365: Core Finance and Operations (MB-300) and Microsoft Dynamics 365: Finance and Operations Apps Developer (MB-500). Here in this post, we will talk about the MB-300 exam.

MB-300 Exam Information

MB-300 exam evaluates an individual's skill to completely use standard functionality and implementation tools, configure security, manage finance and operation data, and validate and support solutions. This exam is available in English and Japanese and costs $165 to take. Although there are no official prerequisites to this certification, applicants should feel affluent and confident in the exam syllabus topics before attempting the exams.

MB-300 Exam Structure

• Number of questions: 40-60 Multiple-Choice Questions per exam
• Passing score: 700/1000
• Exam Time: 120 minutes per exam
• Exam Languages: English, Japanese

Targeted Audience

Applicants for this exam are functional consultants who analyze business needs and interpret those needs into entirely realized business processes and solutions that implement industry best practices. Candidates serve as a critical resource in implementing and configuring applications to satisfy business needs.

Applicants for the MB-300 exam have a basic understanding of accounting principles and financial operations of businesses, client service, field service, manufacturing, retail, and supply chain management concepts.

Applicants for this exam usually specialize in one or more feature sets of Microsoft Dynamics 365 Finance and Operations, including finance, manufacturing, and supply chain management.

Preparing for a Microsoft MB-300 exam

Microsoft provides many study material and training programs to prepare for the Microsoft MB-300 exam.

To make your preparation more productive, it is suggested that you utilize MB-300 practice tests. Practice tests will help you to have a solid grasp of what to expect in the real exam and will also help you acquire skills and proficiency in the exam-taking process.

Many applicants have benefited from practice tests. It would surely be the most interesting learning experience to perform MB-300 practice tests, find out your mistakes, and working on them before the actual exam.

Ignoring your errors and working on what you got right is meaningless. Whenever you answer the question wrong, you need to figure out what went wrong and have a solid grasp of the exam concept to evade the same mistake again.

Along with practice tests, you should enroll in Microsoft's official training courses. Online training courses will give you an in-depth understanding of each exam objective.

Is Microsoft Certified - Dynamics 365 - Finance and Operations Apps Developer Associate CertificationWorth It?

Getting a Microsoft Certified - Dynamics 365 - Finance and Operations Apps Developer Associate is absolutely worth it if you aspire to become a Dynamics 365 certified developer. Passing the MB-300 exam becomes a great asset when you apply for developer job posts. Its advantage also counts on your career objectives and where you stand now. Eventually, the distinct benefits you avail of from this Microsoft certificate will be different at each stage of your career. For instance, if you are searching for your first Microsoft-tech-related job in the IT field, passing this Microsoft exam is the best way to win over a recruitment manager that you are the person to hire.

On the contrary, if you are a seasoned IT professional, you can utilize this Microsoft certification to evolve professionally and make progress in your career. Something as easy as this certificate might give you the extra motivation you need to ask your boss for a salary hike or promotion. Seasoned professionals with lengthy jobs in the field also take advantage of this certification. It indicates you are not on stand-by, seeing the swift, evolving world of Microsoft tech pass you by. You can use this certificate to retain a high, lucrative profile and keep up with the most advanced trends.

Continue reading

Use New Relic One to effortlessly monitor applications in Azure Spring Cloud

Over the past 18 months, we worked with many enterprise customers to learn about their scenarios. Many of these customers have thousands of Spring Boot applications running in on-premises data centers. As they migrate these applications to the cloud, they need to instrument them for application performance monitoring (APM) using tools that their developers are familiar with, and have been using for years, and they must ensure continuity for desktop and mobile applications which are already pre-instrumented for end-to-end monitoring using agents like New Relic One. With the integration of New Relic One in Azure Spring Cloud, you can continue your journey and easily instrument your Spring Boot applications with New Relic One.

More Info: DP-900: Microsoft Azure Data Fundamentals

Most organizations that deploy Spring Boot applications today share a similar goal: maximize the benefits of running Spring Boot applications at virtually any scale, using automation and application performance monitoring. While Azure Spring Cloud excels at abstracting away much of the toil associated with managing containerized workloads, the challenge of monitoring and maintaining the performance and health of these applications, or of troubleshooting issues when they occur, can be daunting—especially as organizations deploy these applications at massive scale. To help you succeed and continue your New Relic One journey, we integrated and upgraded your ability to instrument, monitor, and deliver observability using New Relic One across your Azure Spring Cloud instances. That begins with setting up instrumentation quickly and easily. Then you can analyze the performance and health of your applications, Java Virtual Machines (JVM), transactions, and more to identify and troubleshoot performance issues.

Instrument your Spring Boot applications

Run a "provisioning" automation for a completely hands-off experience for instrumenting and monitoring any new applications that you create and deploy—using Terraform or ARM Template. Or you can run it on-demand using the Azure CLI for greater flexibility and control.

az spring-cloud app update --name customers-service \

    --jvm-options="-javaagent:/opt/agents/newrelic/java/newrelic-agent.jar" \

    --env NEW_RELIC_APP_NAME=customers-service NEW_RELIC_LICENSE_KEY=<key>

Explore Spring Boot application performance

After instrumenting, you can explore Spring Boot application performance through the New Relic One portal. You can view your applications in action through the Service Maps. For example, the screenshot below shows all the applications in the popular Petclinic project:

Figure 1: shows all the applications in the popular Petclinic project.

You can observe your application’s performance by navigating through application-by-application in the New Relic One portal. For example, the screenshot below shows transactions processed by customers-service, its throughput, and error rate:

Figure 2: shows transactions processed by customers-service, its throughput, and error rate.

You can look deeper into the underlying Java Virtual Machines by navigating to the “JVMs” blade on the New Relic One portal. For example, the screenshot below shows how many Java Virtual Machines for all the customers-service application instances:

Figure 3: shows how many Java Virtual Machines for all the customers-service application instances.

You can analyze application dependencies, including database transactions by navigating to the “Databases” blade in the New Relic One portal. For example, the screenshot below shows all the database transactions for customers-service:

Figure 4: shows all the database transactions for customers-service.

You can look at the stack trace of each thread through the New Relic One Thread Profiler and understand times consumed by Java methods. This provides insights into the "hot" functions of the applications where most time is spent. For example, the screenshot below shows a stack trace of a thread in the customers-service application:

Figure 5: shows a stack trace of a thread in the customers-service.

Deliver value to your end-users

Once instrumented, as you scale out to multiple Spring Boot application instances, any new application instances are automatically monitored for you. You spend less time managing the agent installation and maintenance, and more energy on identifying and resolving incidents faster. Azure Spring Cloud service is on-point for periodically updating the agent.

View of your Spring Boot application instances

New Relic One Navigator offers you an at-a-glance view of the operational health of your application instances. This bird's eye view of your estate is automatically available to you, no configuration required. Navigator makes it easy for you to explore huge numbers of instances as it intuitively displays your instances in a dense honeycomb view with traffic light colors based on alerts that you define. Quickly identify alerting instances and uncover root causes in addition to seeing which dependent systems might be affected.

As an illustration, the following Navigator view groups your instances across Azure Spring Cloud instances, allowing you to quickly compare your operations in a multi-region deployment. You can group and filter across your instances to quickly zero in on issues. You can also drill down into any instance to see a summary of its activity and any violations along with key metrics and metadata including custom attributes:

Figure 6: show how Navigator view groups your instances across Azure Spring Cloud instances.

Detect anomalies in your Spring Boot application instances

New Relic Lookout provides an intuitive view of your instances that are deviating from normal behavior, using circle visualization with color indicating the severity of recent signal change and sized proportionally to the magnitude of the metric signal. Lookout automatically compares signals within the last five minutes against the previous hour.

Build your solutions and monitor them today

Azure Spring Cloud is jointly built, operated, and supported by Microsoft and VMware. It is a fully managed service for Spring Boot applications that abstracts away the complexity of infrastructure and Spring Cloud middleware management, so you can focus on building your business logic and let Azure take care of dynamic scaling, patches, security, compliance, and high availability. With a few steps, you can provision Azure Spring Cloud, create applications, deploy, and scale Spring Boot applications, and start monitoring in minutes. We will continue to bring more developer-friendly and enterprise-ready features to Azure Spring Cloud.

We would love to hear how you are building impactful solutions using Azure Spring Cloud. Get started today—deploy Spring applications to Azure Spring Cloud using quickstart.

Source: azure.microsoft.com

Continue reading

Advancing safe deployment with AIOps—introducing Gandalf

In our earlier blog post “Advancing safe deployment practices” Cristina del Amo Casado described how we release changes to production, for both code and configuration changes, across the Azure platform. The processes consist of delivering changes progressively, with phases that incorporate enough bake time to allow detection at a small scale for most regressions missed during testing.

Read More: PL-900: Microsoft Power Platform Fundamentals

The continuous monitoring of health metrics is a fundamental part of this process, and this is where AIOps plays a critical role—it allows the detection of anomalies to trigger alerts and the automation of correcting actions such as stopping the deployment or initiating rollbacks.

In the post that follows, we introduce how AI and machine learning are used to empower DevOps engineers, monitor the Azure deployment process at scale, detect issues early, and make rollout or rollback decisions based on impact scope and severity.

Why AIOps for safe deployment

As defined by Gartner, AIOps enhances IT operations through insights that combine big data, machine learning, and visualization to automate IT operations processes, including event correlation, anomaly detection, and causality determination. In our earlier post, "Advancing Azure service quality with artificial intelligence: AIOps," we shared our vision and some of the ways in which we are already using AIOps in practice, including around safe deployment. AIOps is well suited to catching failures during deployment rollout, particularly because of the complexities of cross-service dependencies, the scale of hyperscale cloud services, and the variety of different customer scenarios supported.

Phased rollouts and enriched health signals are used to facilitate monitoring and decision making in the deployment process, but the volume of signals and level of complexity involved in deployment decision making exceeds what any human could reasonably reason over, across thousands of ever-evolving service components, spanning more than 200 datacenters in more than 60 regions. Some latent issues won’t manifest for several days after their deployment, and global issues that span different clusters but manifest only minutely in any individual cluster are hard to detect with just a local watchdog. While loose coupling allows most service components to be deployed independently, their deployments could have intricate impacts on each other. For example, a simple change in an upstream service could potentially impact a downstream service if it breaks the contract of API calls between the two services.

These challenges call for automated monitoring, anomaly detection, and rollout impact assessment solutions to facilitate deployment decisions at velocity.

Figure 1: Gandalf safe deployment

Gandalf safe deployment service: An AIOps solution

Rising to the challenge described above, the Azure Compute Insights team developed the “Gandalf” safe deployment service—an end-to-end, continuous monitoring system for safe deployment. We consider this part of the Gandalf AIOps solution suite, which includes a few other intelligent monitoring services. The code name Gandalf was inspired by the protagonist from The Lord of the Rings, as shown in Figure 1, it serves as a global watchdog, which makes intelligent deployment decisions based on signals collected. It works in tandem with local watchdogs, safe deployment policies, and pre-qualification tests, all to ensure deployment safety and velocity.

As illustrated in Figure 2, the Gandalf system monitors rich and representative signals from Azure, performs anomaly detection and correlation, then derives insights to support deployment decision making and actions.

Figure 2: Gandalf system overview

Data sources

Gandalf monitors signals across performance, failures, and events as described below. It pre-processes the data to structure them around a unified data schema to support downstream data analytics. It also leverages a few other analytics services within Azure for health signals, including our Virtual Machine failure categorization service and near real-time failure attribution processing service. Signal registration with Gandalf is required when any new service components are onboarded, to ensure complete coverage.

◉ Performance data: Gandalf monitors performance counters, CPU usage, memory usage, and more – all for a high-level view of performance and resource consumption patterns of hosted services.

◉ Failure signals: Gandalf monitors both the hosting environment of customer’s virtual machines (data plane) and tenant-level services (control plane). For the data plane, it monitors failure signals such as OS crashes, node faults, and reboots to evaluate the health of the VM’s hosting environment.  At the same time, it monitors failure signals of the control plane like API call failures, to evaluate the health of tenant-level services.

◉ Update events: In addition to telemetry data collected, Gandalf also keeps its finger on the pulse of deployment events, which report deployment progress and issues.

Detection, correlation, and decision

Gandalf evaluates the impact scope of the deployment—for example, the number of impacted nodes, clusters, and customers—to make a go/no-go decision using decision criteria that are trained dynamically. To balance speed and coverage, Gandalf utilizes an architecture with both streaming and batch analysis engines.

Figure 3: Gandalf Anomaly Detection and Correlation Mode

Figure 3 shows an overview of the Gandalf Machine Learning (ML) model. It consists of two parts—anomaly detection and correlation process (to identify suspicious deployments) and a decision process (to evaluate customer impact).

Anomaly detection and correlation process

To ensure precise detection, Gandalf derives fault signatures from input signals, which can be used to uniquely identify the failure. Then, it detects based on the occurrence of the fault signature.

In large-scale cloud systems like Azure, simple threshold-based detection is not practical both because of the dynamic nature of the systems and workloads hosted and because of the sheer volume of fault signatures. Gandalf applies machine learning techniques to estimate baseline settings based on historical data automatically and can adapt the setting through training as needed.

When Gandalf detects an anomaly, it correlates the observed failure with deployment events and evaluates its impact scope. This helps to filter out failures caused by non-deployment reasons such as random firmware issues.

Since multiple system components are often deployed concurrently, a vote-veto mechanism is used to establish the relationship between the faults and the rollout components. In addition, temporal and spatial correlations are used to identify the components at fault. Fault age, which measures the time between rollout and detection of fault signature, is considered to allow more focus on new rollouts than old ones since newly observed faults are less likely to be triggered by the old rollout.

In this way, Gandalf can detect an anomaly that would lead to potential regressions in the customer experience early in the process—before it generates widespread customer impact. 

Decision process

Finally, Gandalf evaluates the impact scope of the deployment such as the number of impacted clusters/nodes/customers, and ultimately makes a "go/no-go" decision. It’s worth mentioning that Gandalf is designed to allow developers to customize signals’ weight assignment based on their experience. In this way, it can incorporate domain knowledge from human experts to complement its machine learning solutions.

Result orchestration

To balance speed and coverage, Gandalf utilizes both streaming and batch processing of incoming signals. Streaming processing consumes data from Azure Data Explorer, a cloud storage solution supporting analytics with fast speed. Streaming processing is used to process fault signals that happen 1 hour before and after each deployment in each node and runs lightweight analysis algorithms for rapid response.

Batch processing consumes data from Cosmos, a Hadoop-like file system that supports extremely large volumes of data. It’s used to analyze faults over a larger time window (generally a 30-day period) with advanced algorithms.

Both stream and batch processing are performed incrementally with five-minute intervals. In general, the incoming telemetry signals of Gandalf are both streamed into Kusto and stored into Cosmos hourly/daily. With the same data source, occasionally there could be inconsistent results from the processing pipeline. This is by design since batch processing makes more informed decisions and covers latent issues that the fast/streaming process cannot detect.

Deployment experience transformation

The Gandalf system is now well integrated into our DevOps workflow within Azure and has been widely adopted for deployment health monitoring across the entire fleet. It not only helps to prevent bad rollouts as quickly as possible but has also transformed the engineers’ and release managers’ experience in deploying software changes—from looking for scattered evidence to using a single source of truth, from ad-hoc diagnoses to using interactive troubleshooting—and in so doing, many of the engineers who interact with Gandalf have had their opinions on it transformed as well, evolving from skeptics to advocates.

In many Azure services, Gandalf has become a default baseline for all release validations, and it’s exciting to hear how much our on-call engineers trust Gandalf.

Source: azure.microsoft.com

Continue reading