TC-017-FINAL

>> In this video, we'll talk about some big picture considerations that go into designing a great Azure architecture. So let's dig in. First, you want to start your requirements by asking these questions. How many requests per second is the system expected to handle? How much downtime is really acceptable? And hint, in most systems, the answer is not actually zero. And finally, what is the maximum time the application can be unavailable in the event of a failure? Now knowing these requirements, it's time to start thinking about high level design. So you'll want to choose a proven architectural pattern. Let's review three popular architectural patterns. Web-queue-worker, in this architecture, a web frontend handles HTTP requests while a backend web-worker performs long running operations. And the frontend talks to the worker through a messaging queue. And this is a good pattern for web applications using past services. Micro services, a micro services architecture is comprised of many small independent services. And this architecture can be highly resilient and scalable with very fast release cycles. But there is a tradeoff in additional complexity. Stream processing, in this architecture, streams of data are captured in real time and processed with minimal latency. The volume and velocity of data may be extremely high. Internet of Things applications usually have a stream processing component. Once, you know, the type of architecture you're building, you can choose the right Azure technologies. It's important to keep these broad categories in mind. Compute, this refers to the hosting model for the computing resources. This could be either virtual machines where you deploy and manage all the software yourself or manage past services such as Azure functions. Data stores, this includes relational database systems, no SQL databases, blob storage, and any other place where you might store data. Messaging, the subsystem in a cloud application often communicate by exchanging asynchronous messages. Azure offers several messaging services, each designed for a particular scenario. Finally, you'll need to evaluate your design with these five quality pillars. Scalability, the ability to handle increased load. Availability, the percentage of time that the system is functional and working. Resiliency, the ability to recover from failures and continue to function. Disaster recovery, the ability to recover from wide scale failures. And of course, security. Remember, all these characteristics must be judged in the context of your business requirements. If your application absolutely requires 99.99% uptime, you may need to active deployments in order to failover during an outage, but for others, the added complexity and cost of this design might not make sense. We hope you now understand why following a structured iterative process is key. And since this is a huge topic, we will definitely be diving more deeply into the subject in other modules. So stay tuned for more information coming your way.