John Sharp

Larry Brader

Trent Swanson

Alex Homer

Masashi Narumoto

Cloud applications have a unique set of characteristics. They run on commodity hardware, provide services to untrusted users, and deal with unpredictable workloads. These factors impose a range of problems that you, as a designer or developer, need to resolve. Your applications must be resilient so that they can recover from failures, secure to protect services from malicious attacks, and elastic in order to respond to an ever changing workload. This guide demonstrates design patterns that can help you to solve the problems you might encounter in many different areas of cloud application development. Each pattern discusses design considerations, and explains how you can implement it using the features of Windows Azure. The patterns are grouped into categories: availability, data management, design and implementation, messaging, performance and scalability, resilience, management and monitoring, and security. You will also see more general guidance related to these areas of concern. It explains key concepts such as data consistency and asynchronous messaging. In addition, there is useful guidance and explanation of the key considerations for designing features such as data partitioning, telemetry, and hosting in multiple datacenters. These patterns and guidance can help you to improve the quality of applications and services you create, and make the development process more efficient. Enjoy!

Prescriptive Architecture Guidance for Cloud Applications

Cloud Design Patterns

Jose Luis Soria Teruel

Roberta Leibovitz

You're expected to produce releases at an ever-increasing rate. You're under pressure to add new features and deploy to customers sometime between your first cup of coffee in the morning and lunch, if you have time to eat it. In the meantime, you have the same release processes you've always had and it's got problems. Maybe there's some automation, but there's room for lots of improvement. Manual steps are everywhere, everyone has a different environment, and working all weekend to get a release into production is normal. One of the biggest problems is that changing how your software is released won't happen by waving a magic wand or writing a memo. It comes through effort, time, and money. That takes commitment from every group involved in the software process: test, development, IT (operations), and management. Finally, change is scary. Your current release process bears no similarity to the well-oiled machines you've seen in a dozen PowerPoint presentations, but it's yours, you know its quirks, and you are shipping. This book is here to help you with some of these challenges. It explains how to progressively evolve the process you use to release software. There are many ways to improve the release process. We largely focus on how to improve its implementation, the release pipeline, by using and customizing the default build templates provided by Team Foundation Server (TFS) and Lab Management. We move forward in small iterations so that no single change you make is too drastic or disruptive. The goal of this book is to put you on the road toward continuous delivery. By continuous delivery, we mean that through techniques such as versioning, continuous integration, automation, and environment management, you will be able to decrease the time between when you first have an idea and when that idea is realized as software that's in production. We also hope to show that there are practical business reasons that justify every improvement you want to make. A better release process makes economic sense.

Building a Release Pipeline with Team Foundation Server 2012

Larry Brader

About

Books

Join the club