Book Image

Solutions Architect's Handbook

By : Saurabh Shrivastava, Neelanjali Srivastav
Book Image

Solutions Architect's Handbook

By: Saurabh Shrivastava, Neelanjali Srivastav

Overview of this book

Becoming a solutions architect gives you the flexibility to work with cutting-edge technologies and define product strategies. This handbook takes you through the essential concepts, design principles and patterns, architectural considerations, and all the latest technology that you need to know to become a successful solutions architect. This book starts with a quick introduction to the fundamentals of solution architecture design principles and attributes that will assist you in understanding how solution architecture benefits software projects across enterprises. You'll learn what a cloud migration and application modernization framework looks like, and will use microservices, event-driven, cache-based, and serverless patterns to design robust architectures. You'll then explore the main pillars of architecture design, including performance, scalability, cost optimization, security, operational excellence, and DevOps. Additionally, you'll also learn advanced concepts relating to big data, machine learning, and the Internet of Things (IoT). Finally, you'll get to grips with the documentation of architecture design and the soft skills that are necessary to become a better solutions architect. By the end of this book, you'll have learned techniques to create an efficient architecture design that meets your business requirements.
Table of Contents (18 chapters)

Planning the RTO and RPO

Any application needs to define service availability in an aspect of a Service-Level Agreement (SLA). Organizations define SLAs to ensure application availability and reliability for their users. You may want to define an SLA, saying my application should be 99.9% available in a given year or the organization can tolerate it if the application is down for 43 minutes per month, and so on. The RPO and RTO for an application is mostly driven by the defined SLA.

The RPO is the amount of data loss an organization can tolerate in the aspect of time. For example, my application is fine if it loses 15 minutes' worth of data. The RPO helps to define a data backup strategy. The RTO is about application downtime and how much time my application should take to recover and function normally after failure incidence. The following diagram illustrates the difference between the RTO and RPO:

RTO and RPO

In the preceding diagram, suppose the failure occurs at 10 A.M. and...