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)
DevOps and Solution Architecture Framework

In traditional environments, the development team and the IT operations team work in silos. The development team gathers requirements from business owners and develops the applications. System administrators are solely responsible for operations and for meeting uptime requirements. These teams generally do not have any direct communications during the development life cycle and each team rarely understands the processes and requirements of the other team.

Each team has its own set of tools, processes, and approaches that are redundant, and sometimes, efforts are conflicting. For example, the development and quality assurance (QA) teams can be testing the build on a specific patch of the operating system (OS). However, the operations team deploys the same build on a different OS version in the production environment, causing issues and...