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: This domain is responsible for manufacturing products
• Supply: This domain is responsible for delivering products to customers

An illustration of the three domains is as follows:

All systems will be self-sufficient and won't rely on data from any other system to function.

Sales requirements

The Sales business unit is responsible for the following functions:

• Selling products to customers via a website
• Managing customer orders
• Maintaining product inventory
• Supplying Production with product orders automatically
• Keeping customers up-to-date with their orders via a number of channels including a mobile phone application

Customer orders will automatically be sent to production, products will be manually maintained, and customers will be automatically notified of the order's progress.

Production requirements

The Production business unit is responsible for the following functions:

• Processing product orders
• Planning batch production
• Maintaining stock levels
• Producing products
• Notifying Sales and Supply on product status

The system will be automated as far as possible, providing production staff with batch schedules and reports. The system will have the capability to integrate with on-premises systems.

Supply requirements

The Supply business unit is responsible for the following:

• Creating and printing tracking barcodes
• Delivering orders to customers
• Notifying Sales of the delivery status

Delivery jobs will be sent to a tablet application, which will have the facility to print barcodes and address labels, view customer addresses, and update order status. Jobs must be archived for audit purposes.

Identifying subsystems

Due to the scale of the case study and the requirement to make each business domain autonomous so that it doesn't depend on data from other business domains, we'll examine each system individually.

Sales subsystems

From the business requirements, we can see that we need the following sales subsystems:

• Sales customer website: This is required for allowing customers to register, view products, create orders, and view order status
• Sales administration system: This is required for the staff to manage orders and product catalog
• Sales order process system: This will automatically update the order data and notify customers of the order progress
• Sales customer phone app: This is required for allowing customers to view orders and receive notifications on order progress

Production subsystems

The production system can be broken down into the following subsystems:

• Production order processor: This will automatically process orders coming from sales, allocate ingredients, create batch schedules, and order ingredients. This system will be fully automated.
• Production management system: This is required for the production staff to view batch schedules and update batch progress. This system will also have the capability of interfacing with on-premises systems for displaying plant data.

Supply subsystems

The supply system can be broken down into the following subsystems:

• Supply processing system: This will automatically process the delivery requests coming from production, work out how to geographically group orders, allocate them to vehicles and drivers, and create address labels and barcodes for printing. This system will be fully automated.
• Supply tablet application: A tablet application is required for the supply staff, allowing them to work easily while performing activities around the warehouse. It will allow them to print address labels and barcodes for deliveries and allocate deliveries to vehicles and drivers.

System design

Now that we've broken down the enterprise system into its subsystems, we've simplified the design process so that we don't have to try and think about how the whole thing works at once. Actually, the two sales websites look nearly identical to the websites of the small business system, with the slight difference that order messages must be sent to the messaging middleware for the production system.

As the websites are very similar and to save time, we'll just look at the system designs for the sales order processing system and the sales customer phone app, and miss out on the production and supply during the design phase, although with a real system, we would apply the process for the entire system.

System design – the sales customer phone app

The phone app needs to allow customers to do the following:

• Register and log in (the same account as the customer website)
• View products
• Make orders
• View order progress
• Receive notifications of new products
• Receive notifications of order progress

The app will interact with data via a secure web service and will receive push notifications for the product updates and order progress, as shown in the following diagram:

For consistency with the websites, customers should be able to authenticate themselves using existing credentials from a well-known identity provider such as Facebook or Twitter, making it more likely for them to make orders from the website and lowering the user admin overhead in the system.

System design – sales order processor

The order processor system will automatically perform the following tasks:

• Receive order status messages from middleware
• Update order status in the sales system
• Send push notifications to customers for order status change

The working of the order-processing system is shown in the following diagram:

The process will run without requiring any user intervention, but will provide diagnostic and error log information.

Sales system integration

As with the small business case study, there is a lot of overlap in terms of storage, and because we are building a small system with a low order throughput, we can bring our costs down without impacting the performance, by sharing the same storage mechanism.

There is no real overlap between the two websites, so there is no strong driver for sharing a website; for security reasons, it is better to have them separated.

Identifying critical services

There are a number of critical services, which have a direct impact on a company's revenue and need special consideration when selecting service tiers and scalability; these critical services are as follows:

• Sales customer website: This is the most critical system; if customers cannot make an order, the business loses revenue, and customers may take their business elsewhere.
• Production order processor: This is the point at which orders come into the production system, so it is very important; if it fails or cannot meet the load demands, orders will not automatically come through to the production management app.
• Production management Web API: This API allows the production management application to access production data. Production staff need this to see product batch schedules and ingredient stock levels, so they know what to bake, and when and what ingredients need replacing.
• Production database: The criticality of the database matches with the processing system and management app API as it links the two together.
• Supply process: As with the production order processor, this is the source of work for the supply business domain, so this is very important.
• Supply mobile API: This API allows the supply tablet app to access data for order delivery, so this is important for completing the order process.
• Supply deliveries table: As with the production database, the criticality of the table matches with the processing system and management app API as it links the two together.

The other systems are still important but a failure or performance degradation will not have a disastrous impact on the whole system. They are as follows:

• Sales admin website
• Sales database
• Sales mobile API
• Sales order processor

These systems can be deployed on more economical service tiers without impacting the performance or availability of the whole system.

Selecting Microsoft Azure Services

Now that we've identified all the services with the system and their criticality, we can start selecting the Microsoft Azure Services and service tiers.

Selecting common services

Because all the domain systems need to integrate together to form the full enterprise system, we need to choose services for the middleware messaging layer, which allow the systems to communicate with each other in a disconnected loosely-coupled way. We also need to look at authentication mechanisms so that we can centralize the user account and access control.

Messaging services

We have a requirement for processes that span the whole system to be able to consume order status messages, so we will use a Service Bus topic, which allows multiple consumers to subscribe to filtered messages. If we want a queue, we will need to decide whether to use a Service Bus queue or storage queue, so this simplifies the decision-making process at this point, but we'll talk about this more later in the book.

Authentication

For the noncustomer systems, we will use Azure Active Directory, which will allow user authentication and application access to be centrally controlled across all three sites and also make it easier for staff to access systems on different business domains if needed.

Selecting sales services

In this section, we are going to select individual services for the sales business domain:

• The customer website: As with the small business case study, the website is fairly simple and has no special requirements for it to have a web role, so we will use a normal website. We're expecting a fairly high volume of orders through this system. It's an extremely important system as customer sales are the primary revenue stream for the company, so we will start with two medium-sized instances (two cores, 3.5 GB RAM) on a STANDARD tier. We get the following benefits:
  • Redundancy and load balancing with two instances
  • Good performance for generating high volume, data-driven, server-side web content with medium-sized instances
  • Staging slot support with a STANDARD tier to allow the site to be warmed up before swopping to production after deployment
  • Custom domain and SSL certificate support in a STANDARD tier
  • The system will be evaluated under load testing to see how well it performs, then the base instance count can be adjusted and auto scaling will be applied on go-live
• The admin website: Again, the website has no special requirements for it to have a web role, so we will use a normal website. This site will have a fairly low volume of traffic and will be used by a small number of users, so we will start with two small instances (one core, 1.75 GB RAM) on a BASIC tier to save cost. However, this site still gives us higher availability over one instance. The system will be evaluated under moderate load testing to see how well it performs, and will then be adjusted if required. We will not use auto scaling here as we will have a very consistent usage profile.
• The order processor: The order processor needs to automatically update the order status in the sales database and make push notification requests for the customer phone application when the order status messages are received on its Service Bus topic subscription. A worker role is the natural choice for this type of system as it provides a scalable solution for long-running, unattended processes. This service is not business-critical as it is only updating order statuses and notifying customers and not impacting directly on order throughput through the system, so we will start with two small instances (1.6 GHz CPU, 1.75 GB RAM) that give us the following benefits:
  • Redundancy and load balancing with two instances
  • Reasonable performance for processing order updates with small-sized instances

  As with the website, the system will be evaluated under moderate load testing to see how well it performs, and then the base instance count can be adjusted and auto scaling can be applied on go-live.

• The mobile API: The mobile API allows the customer phone app to securely interact with system data. We'll use a .NET mobile service, which makes the OAuth2 implementation straightforward and will allow us to reuse the data access layer components from the website. We'll use the free service tier for this as it's not critical and it's not the main customer interface to the system. If we find that we're exceeding the 500K API calls limit, we can change the service tier.
• Storage: We have a requirement for a relational data model, so the natural choice is to use an SQL Server over other storage options such as tables, blobs, or disk storage. The database will be shared between both websites. Once we have a more detailed application design, we can try and estimate storage requirements in more detail, but for now, we'll opt for a single (no partitioning) 30 GB database. There will be an additional storage overhead for diagnostic data for which we will use the lowest tier of table storage.
• Security: The customer website and phone application will implement OAuth2 security, and the admin website will implement Azure Active Directory authentication.

Selecting production services

Now, we are going to select individual services for the production business domain:

• The order processor: The order processor needs to automatically add the order into the batch schedule and allocate ingredients in the production database when order status messages are received on its Service Bus topic subscription. As with the sales order processor, a worker role is the natural choice for this type of system. This service is business-critical as it controls the batch schedule, which governs when the products are baked, so we will start with two medium instances (2 x 1.6 GHz CPU, 3.5 GB RAM) giving us the following benefits:
  • Redundancy and load-balancing with two instances
  • Good performance for processing orders with medium-sized instances

  The system will be evaluated under high-volume load testing to see how well it performs; then, the base instance count can be adjusted and auto scaling can be applied on go-live.

• The Web API: The Web API allows the production management app (this will be an on-premises desktop application, which can interact with plant on-site) to securely interact with system data. We'll create an MVC Web API website deployed to a Microsoft Azure website. This site will have a fairly low volume of traffic and will be used by a small number of users, so we will start with two small instances (one core, 1.75 GB RAM) on a BASIC tier. The system will be evaluated under moderate load testing to see how well it performs, and then adjusted if required. We will not use auto scaling here as we will have a very consistent usage profile.
• Storage: Again, we have a requirement for a relational data model, so the natural choice is to use an SQL Server. The database will be shared between the order processor and the Web API. Once we have a more detailed application design, we can try and estimate storage requirements in more detail, but for now, we'll opt for a 30 GB database. There will be an additional storage overhead for diagnostic data, for which we will use the lowest tier of table storage.

Selecting supply services

Finally, we are going to select individual services for the sales business domain:

• Order processor: The order processor needs to automatically allocate orders to vehicles and drivers to create delivery jobs when the ready for dispatch order status messages are received on its Service Bus topic subscription. As with the sales order processor, a worker role is the natural choice for this type of system. This service is business-critical as it controls the dispatch jobs for delivering orders to customers so we will start with two medium instances (2 x 1.6 GHz CPU, 3.5 GB RAM), giving us the following benefits:
  • Redundancy and load balancing with two instances
  • Good performance for processing orders with medium-sized instances

  The system will be evaluated under high-volume load testing to see how well it performs, then the base instance count can be adjusted, and auto scaling can be applied on go-live.

• The mobile API: The mobile API allows the supply tablet app to securely interact with system data. We'll use a .NET mobile service, which can now provide Azure Active Directory authentication support.
• Storage: We don't have a requirement for a relational data model here, so we will use table storage for our data. We will use 200 GB locally redundant storage as we are operating in a single location.

Conclusion of an enterprise system case study – Azure Bakery

We've been through a methodical approach in designing our system to be built on Microsoft Azure, and come out with the exact service we require and how much it will cost us monthly. The next step would be to go into the application design phase; however, we will stop at this point with the small case study and move on to the main enterprise case study.

The following diagram shows us how all the selected services fit together:

As we draw diagrams of the business and think about how its systems fit together using Microsoft Azure, it's easy to see how it can be extended and scaled up. In our case study, we're not going to worry about where the product designs come from, but it's quite easy to imagine that we have a product development department with their own systems; they have an experimental kitchen, where they come up with new product designs and work out recipes for production; then, when they are ready, they can send the product description to the sales system and the recipes to the production systems.