Chapter 2. Designing a System for Microsoft Azure

There are challenges in designing any software system, whether it is a small system with a single website and database backend or a large distributed multi-tier system with multiple applications and storage solutions that span multiple business domains and geographic locations. We face some of the same issues and challenges while designing a system for Microsoft Azure as we would face on an on-premises system, such as how to divide our system into different applications, services, and databases, and we may have some new or different challenges such as making the system scalable (larger organizations often support scalability to some degree with multiple web servers and load balancing, but Microsoft Azure offers advanced scaling options such as scheduled and metric-based scaling) and tackling authentication on a cloud system.

All real-life systems are rarely implemented using the same technology and are likely to incorporate new and legacy...

Designing scalable and resilient systems

One of the main features of the Microsoft Azure technology is scalability. By carefully designing our system, we can build it to manually or automatically scale (elastic scaling) to meet our business requirements as the business grows, or to cope with peaks in system load. Databases and storages can also be designed to be distributed across databases and storage partitions, allowing large volumes of data to scale while maintaining performance.

Note

Scale out means increasing computing capacity by increasing the number of compute instances in a system (for websites and cloud services, this would mean increasing the number of virtual machines). Scale up means increasing the computational resources of a compute instance (for websites and cloud services, this would mean more CPU/memory/disk allocation for a virtual machine instance).

By breaking down large systems into smaller, decoupled subsystems, which interact with each other in an asynchronous fault...

Systems architecture

IT systems can vary dramatically in their scale, the number of business domains they span, the number of platforms they include, and the number of geographical locations they serve. Some parts of the system may need to communicate with each other; some parts are entirely self-sufficient and need no interaction with other systems. When working on a larger system, we are likely to be integrating existing legacy systems into a new system or integrating new systems into a legacy system.

The complexity and size of many systems can reflect the level of automation versus a manual process within a business. Commonly, larger organizations will have the capital to invest in automated systems, which relieve the requirement for a number of manual processes, but will introduce some more specialized administrative overhead.

A large system may look very complicated as a whole, but we can break down any system into smaller subsystems, making it easier to design and helping to create a...

A case study of a small business system

A small business, for example, an independent stationary shop that consists of a few employees with a shop (bricks and mortar) and an online shop (website) requires a small system, which can allow customers to order stationary online, track orders, manage stock for both shops, and produce monthly reports.

System requirements

If we break down the business requirements, we can understand more about the type of system:

• Customer website

• Administration system

• Manually order stock from suppliers

• Manually arrange delivery

• Low order volume (less than 100 units per day)

• No need for legacy system integration requirement

• No interest in owning IT infrastructure

• Very limited budget for IT

Although it is listed last, the budget requirement will probably be the main factor in designing a system. If service providers have an initial budget of $5,000 to get a system built, and they only want to spend a maximum of $100 a month on running the system, then we're not looking at a...

A case study of an enterprise system – Azure Bakery

I've tried to come up with a good case study, which will allow us to implement a large number of Microsoft Azure features and services in a realistic way. I wanted to use something that will have long-running processes over distributed systems so that we could incorporate features from websites through Service Bus queues, worker processes, and mobile applications. I came up with an idea of an industrial bakery, which should be a concept that is easy to understand and doesn't need specialist domain knowledge as with many of the systems we work on in our daily jobs!

System requirements

The Azure Bakery makes products such as cakes and pies and deals with large customers such as supermarkets and smaller bakeries that require additional stock (this justifies the supply business unit). To make the bakery more realistic, it's split into three distinct business domains:

• Sales: This domain is responsible for selling products to customers

• Production...

Designing platform environments

While we're preparing our development environment, it's a good time to talk about planning our platform environments (in an on-premises or IaaS system, we may say server environments). These environments are used to host our system during the different phases of their life cycle between development and production (or live).

The scales of a business and budget are the major factors in this decision process; if we have a large business and a large system, it might take a number of testers to test the changes made to a system and do full regression tests when needed. If the budget for a system is tight, it may not be possible to have a perfect set of environments, so compromises may have to be made. We also need to remember that we're not just talking about a single website; we need to include databases, table storage, worker roles, Service Bus queues and topics, and so on. We'll look at different types of environments and examples of environment sets for different...

Summary

We've been through quite a lot of theory around how to design a system for Microsoft Azure and also introduced the Azure Bakery case study, which we will build on throughout the book. From this point on, we'll be diving deeper into building a number of systems for the case study.

In this book, we'll concentrate on code examples to cover as many different Microsoft Azure services as possible without duplicating things too much; for example, we'll be building two websites for the sales system, we'll look at the customer website in detail, but only look at the Azure AD integration for the admin website. There will be three worker roles across the system, and again, we'll only look at the sales one in detail, and then look at relevant features of the others. In the code samples, everything will be included, so we can run orders end to end.

In the next chapter, we'll start laying the foundations for building the Azure Bakery system, starting with preparing the development environment and...

Questions

1. Why must websites be stateless in order to be scalable?

2. Which Azure services can be used to implement decoupled messaging between system tiers?

3. What does the term sharding mean in storage?

4. If we were building a small business system on a limited budget, which needs a customer website and administration system, why should we choose to build a website for the administration system?

5. What is the cheapest web tier for hosting a site with a custom domain?

6. Why is it important to identify the most critical parts of a system?

7. If we need to store large volumes of structured but nonrelational data, what will be a suitable storage option?

8. What purpose does a QA environment serve for a system?

9. Why do we need to be careful when using deployment slots on websites?

10. If we use a cloud service staging slot as a QA environment, what should we remember to do after we swap it with live?

11. Think about a small system you have worked on in the past and try to design it to run on Azure. Break down the system into logical...

Answers

1. Websites that use technology such as session state and server-side caching cannot be scaled out easily since the stored data is not synchronized across multiple server instances.

2. Service Bus queues and topics and storage queues.

3. This is horizontal scaling of a database or storage, where data is split across multiple databases or storage providers with the same structure. Data is stored with a partition key, which is used to help you split the data across storage containers.

4. We already have a customer website, so it makes sense to create another website using the same technology as we will need the same development skills and deployment path.

5. Shared.

6. It helps us choose the appropriate service tiers and scalability options for the most critical systems and save cost on less critical or noncritical systems.

7. Table storage as it is a low cost, no SQL alternative to an SQL Server but it still provides structured storage.

8. QA environments are commonly used for user acceptance testing on a system...