Upload
others
View
99
Download
11
Embed Size (px)
Citation preview
WA2325 Solution Architecture(SA) Practitioner’s Guide
(Extended)
Web Age Solutions Inc.USA: 1-877-517-6540Canada: 1-866-206-4644Web: http://www.webagesolutions.com
The following terms are trademarks of other companies:
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
IBM, WebSphere, DB2 and Tivoli are trademarks of the International Business MachinesCorporation in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
For customizations of this book or other sales inquiries, please contact us at:
USA: 1-877-517-6540, email: [email protected]: 1-866-206-4644 toll free, email: [email protected]
Copyright © 2018 Web Age Solutions Inc.
This publication is protected by the copyright laws of Canada, United States and any other country where this book is sold. Unauthorized use of this material, including but notlimited to, reproduction of the whole or part of the content, re-sale or transmission through fax, photocopy or e-mail is prohibited. To obtain authorization for any such activities, please write to:
Web Age Solutions Inc.439 University AveSuite 820TorontoOntario, M5G 1Y8
Table of ContentsChapter 1 - Solution Architecture Overview.......................................................................7
1.1 Why is Solution Architecture Important?.................................................................71.2 Communications Vehicle Among Stakeholders.......................................................81.3 The Project is Organized Around Architectural Elements........................................81.4 What is a System?.....................................................................................................91.5 Why Focus on Structure?..........................................................................................91.6 Solution Architecture Context.................................................................................101.7 Solution Architecture & Domains...........................................................................111.8 SA Spans All Domains............................................................................................111.9 Relationship to EA Architecture Development Process.........................................121.10 Solution Architecture............................................................................................131.11 Example: Solution Architecture Stakeholders......................................................141.12 Solution Architecture Deliverables.......................................................................151.13 EA Involvement in SA..........................................................................................161.14 Architecturally Significant....................................................................................171.15 Group Discussion: Architecture ...........................................................................171.16 Resource: Software Engineering Institute (SEI)...................................................181.17 Resource: SWEBOK.............................................................................................181.18 Resource: OpenUp................................................................................................191.19 Resource: Microsoft Library.................................................................................201.20 Group Discussion: Methodologies........................................................................201.21 Summary...............................................................................................................21
Chapter 2 - Core Solution Architecture Methods..............................................................232.1 Shared Vision..........................................................................................................232.2 Example Shared Vision...........................................................................................242.3 Draw the Boundary.................................................................................................252.4 Well-defined Interface............................................................................................252.5 Example: Context Diagram.....................................................................................262.6 Identify the External Interfaces...............................................................................272.7 Subsystems..............................................................................................................272.8 Subsystem Context Diagram...................................................................................282.9 Layers......................................................................................................................292.10 Example: Subsystems with Layers........................................................................302.11 Components...........................................................................................................312.12 Decomposing the System......................................................................................322.13 Partitioning Patterns..............................................................................................322.14 Example Partitioning Based on Patterns...............................................................332.15 Example: Healthcare SOA Framework.................................................................342.16 Requirements Allocation.......................................................................................342.17 Group Discussion: Requirements Allocation........................................................352.18 Configuration Management Implications.............................................................352.19 Release Management Implications.......................................................................362.20 Testing Implications..............................................................................................372.21 Work Pattern & Skill Set Implications..................................................................38
2.22 Work & Build Dependencies................................................................................392.23 Increment/Sprint Planning....................................................................................402.24 Sizing Implications................................................................................................412.25 More Than Executable Architecture ....................................................................412.26 Development Architecture ...................................................................................422.27 Operations Architecture .......................................................................................442.28 Group Discussion: Integrating Operations Architecture ......................................452.29 Summary...............................................................................................................46
Chapter 3 - Building Modern Applications.......................................................................473.1 Next Generation Methodologies, Approaches, Tools, and Applications................473.2 Web 2.0...................................................................................................................483.3 Rich Internet Client Applications............................................................................483.4 Single Page Applications (SPA) with AngularJS...................................................493.5 Two-way Data Binding (the AngularJS Way)........................................................503.6 Other Client Side MV(C) Frameworks...................................................................503.7 "Rich Client" - "Thin Server" Architecture ............................................................513.8 Mobile Platforms.....................................................................................................513.9 Types of Mobile Applications.................................................................................523.10 Native Mobile Applications..................................................................................523.11 Mobile Web Applications.....................................................................................523.12 Hybrid Mobile Applications.................................................................................533.13 Hybrid App Tools and Frameworks .....................................................................533.14 RIA as a Driving Force to Turn the "Thin Server" into Microservice(s)..............543.15 So, How Can Microservices Help Me? ................................................................543.16 The Data Exchange Interoperability Consideration .............................................553.17 Microservices in Their Purest Form: AWS Lambdas...........................................553.18 The Microservices Architecture Design Principles ..............................................563.19 Decentralized Processing .....................................................................................573.20 Crossing Process Boundary is Expensive!............................................................573.21 Managing Microservices ......................................................................................573.22 Traditional Enterprise Application Architecture (Simplified)..............................583.23 Microservices Architecture Example (Simplified)...............................................603.24 Design for Failure.................................................................................................603.25 Fault Injection During System Testing.................................................................613.26 Architecting in the Cloud......................................................................................613.27 The Building Blocks of a Fault-tolerant Application on AWS.............................623.28 Dev and Ops Views...............................................................................................623.29 What is DevOps?...................................................................................................633.30 More DevOps Definitions.....................................................................................633.31 DevOps and Software Delivery Life Cycle..........................................................633.32 Main DevOps Objectives......................................................................................643.33 The Term "DevOps" is Evolving!.........................................................................643.34 Infrastructure as Code...........................................................................................653.35 Prerequisites for DevOps Success ........................................................................653.36 Alignment with Business Needs...........................................................................663.37 Collaborative Development .................................................................................66
3.38 Continuous Testing and Integration......................................................................673.39 Continuous Release and Deployment ..................................................................673.40 Continuous Application Monitoring.....................................................................673.41 Standing Up DevOps.............................................................................................683.42 Select DevOps Techniques and Practices.............................................................683.43 Select DevOps Techniques and Practices.............................................................693.44 Select DevOps Techniques and Practices.............................................................693.45 Select DevOps Techniques and Practices.............................................................703.46 Select DevOps Techniques and Practices.............................................................703.47 Containerization and Virtualization......................................................................713.48 Machine Images On Demand ...............................................................................713.49 Virtualization.........................................................................................................723.50 Hypervisors...........................................................................................................723.51 Docker Containers ................................................................................................723.52 Docker Containers vs Traditional Virtualization..................................................733.53 Docker Containers vs Traditional Virtualization..................................................733.54 Docker as Platform-as-a-Service...........................................................................743.55 Docker Integration................................................................................................743.56 Docker Application Container Public Repository.................................................753.57 Kubernetes.............................................................................................................753.58 Other Containerization Systems ...........................................................................753.59 Where to Use Virtualization and Containerization...............................................763.60 Summary...............................................................................................................76
Chapter 1 - Solution Architecture Overview
Objectives
After this chapter, you will be able to:
Identify reasons why a Solution Architecture is important;
Describe the concept of a System;
Understand the relationship between Solution Architecture and Enterprise Architecture;
Explain applicability of architecture domains;
Define the relationship of the Solution Architecture process to the Enterprise Architecture process; and
Leverage additional industry resources.
1.1 Why is Solution Architecture Important?
1. An architecture will inhibit or enable a system’s driving quality attributes.
2. The decisions made in an architecture allow you to reason about and manage change as the system evolves.
3. The analysis of an architecture enables early prediction of a system’s qualities.
4. A documented architecture enhances communication among stakeholders.
5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions.
6. An architecture defines a set of constraints on subsequent implementation.
7. The architecture dictates the structure of an organization, or vice versa.
8. An architecture can provide the basis for evolutionary prototyping.
9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule.
10.An architecture can be created as a transferable, reusable model that forms the heart of a product line.
11.Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.
12.By restricting design alternatives, architecture channels the creativity of developers,
Chapter 1 - Solution Architecture Overview
reducing design and system complexity.
13.An architecture can be the foundation for training a new team member.
Source: [Bass, 2012]
1.2 Communications Vehicle Among Stakeholders
Architecture provides a common language in which the architect can communicate with the stakeholders, and stakeholders can communicate with each other.
This happens when
Negotiating requirements with users and other stakeholders
Keeping the customer informed of progress and cost
Implementing management decisions and allocations
Informing stakeholders about design decisions and tradeoffs
1.3 The Project is Organized Around Architectural Elements
The architecture influences the organizational structure for development & maintenance efforts. Examples include:
Division into teams
Assignment of work
Units for budgeting, planning by management
Basis of work breakdown structure
Organization of documentation
Organization of CM libraries
Basis of integration
Basis of test plans, testing
Basis of maintenance
Incremental deployment
8
Chapter 1 - Solution Architecture Overview
1.4 What is a System?
System A
System B System C
System G
System H
System D
System E
System F
What is a system?
A system can be:
• The Enterprise
• Line of Business
• Segment Architecture
• Application
IEEE defines system as “A collection of components organized to accomplish a specific function or set of functions”
IEEE “system” best practices relate to all system types
• Stakeholders
• Views, Viewpoints
System of Systems
The Software Engineering Institute (SEI) describes a concept of “System of Systems”. The concept of “System of Systems” explains the relationship between Strategic Enterprise Architecture, Segment Architecture, and Solution Architecture. Solution architecture is the lowest level “system” in the hierarchy of “System of Systems”. A Solution Architecture can be what SEI calls a “Product Line Architecture” or this could be specified as a Segment architecture depending on an organization's approach.
SEI is a great resource for understanding complex architectures: http://www.sei.cmu.edu/.
1.5 Why Focus on Structure?
By concentrating on structure, we treat the pieces as atomic, as black boxes. This reduces detail we have to tend to, and we can postpone that consideration until later.
It separates concerns between structure (the pieces) and the details of implementing the pieces (which is a job we give to programmers).
Suppressing the internal details of the elements does not affect how the elements are used or how they relate to or interact with other elements.
9
Chapter 1 - Solution Architecture Overview
It makes an architecture an abstraction of a system – which is a simplification.
1.6 Solution Architecture Context
Enterprise Strategic Architecture (relevant to enterprise)• Principles• Policies
Segment Architecture (relevant to multiple solutions)• Reference Models• Patterns• Standards• Guidelines (Best Practices)
Solution Architecture • System Requirements (i.e. testable)• Design Models• Executable Frameworks
10
Chapter 1 - Solution Architecture Overview
1.7 Solution Architecture & Domains
Business Architecture
Application Architecture
Data Architecture
Technology Architecture
A solution architecture covers all domains.
A software/application architecture focuses on the application architecture.
A data architecture focuses on the data architecture.
A technical architecture focuses on the technology architecture.
1.8 SA Spans All Domains
Like EA, Solution Architecture spans all domains.
11
Chapter 1 - Solution Architecture Overview
1.9 Relationship to EA Architecture Development Process
Target ArchitectureBaseline Architecture
Architecture Roadmap
Solution ArchitectureDevelopment
Solution ArchitectureDevelopment
Orchestratessequence of
Guides and constrains
Each releaseupdates
Notes
• The architecture roadmap sequences the solution architecture deliveries to incrementally deliver capabilities.
• Solution Architecture plays a vital role in delivering new and changed business and technology capabilities that move the enterprise toward the desired, target architecture.
• Each Solution Architecture delivery changes the Architecture Baseline.
• Lessons learned from each Solution Architecture delivery may update the Target Architecture (via a new ADM cycle or an architecture change request).
12
Chapter 1 - Solution Architecture Overview
1.10 Solution Architecture
Architecture, which is the partitioning of a whole into parts, with specific relations among the parts, is what allows groups of people – often groups of groups of people separated by organizational, geographical, and even temporal boundaries – to work cooperatively and productively together to solve a much larger problem than any of them would be capable of individually.
Architecture serves as a means of education
Architecture serves as a primary vehicle of communications among stakeholders
Architecture serves the basis for system analysis
- Documenting Software Architectures: Views and Beyond [Clements 2000]
13
Chapter 1 - Solution Architecture Overview
1.11 Example: Solution Architecture Stakeholders
Application Architect
Architecture Manager
Architecture Sponsor
Business Analyst
Business Architect
Data Architect
Data Modeler Network Engineer
Database Administrator Operations Architect
Designer Program Manager/Project Manager
Developer/Software Engineer Regulator
Development Manager Security Architect
Domain SME Service Architect
End User Service Designer
Enterprise Architect Quality Assurance Staff
Integration Specialist Test Manager
IT Designer Tester
Network Architect Trainer
Stakeholders
The stakeholder types will vary based on the solution size and characteristics. Sources of candidate stakeholder types include:
• TOGAF Skills Framework (http://pubs.opengroup.org/architecture/togaf9-doc/arch/)
• Open Group SOA Reference Models (http://www.opengroup.org/soa/source-book/gov/sgrm.htm)
• Business Analysis Book of Knowledge (http://www.iiba.org/babok-guide.aspx)
• Data Management Book of Knowledge (http://www.dama.org)
14
Chapter 1 - Solution Architecture Overview
1.12 Solution Architecture Deliverables
Architecture Use Cases/ Scenarios
Requirements Specification
Architecture & Design Patterns
Standards
Guidelines (Best Practices)
Architecture Description Document (Business, Application, Data, Technology)
System Process Flows
Architecture Decision Document
Architecture Deliverables
Architecture Deliverables are very similar between the Enterprise Architecture and the Solution Architecture. The difference is the target audience (i.e. stakeholders) and the level of specification.
15
Chapter 1 - Solution Architecture Overview
1.13 EA Involvement in SA
EA Relationship To Solution Architecture Analysis Workflow
This graphic shows the EA deliverables as input to the Solution Architecture analysis workflow. The Solution Architecture analysis activities also provide feedback to the EA activities. EA incorporates thisfeedback into future releases of EA models, practices, patterns, and requirements. It is an iterative and collaborative process. There is an EA compliance review to ensure that all solution architectures meet the mandatory policies and practices. EA participation and reviews also enables the EA function to identify opportunities for reuse across the enterprise.
16
Chapter 1 - Solution Architecture Overview
1.14 Architecturally Significant
Designers focus on models which are complete representations of the system.
Architects focus on the architecturally significant elements.
An architecturally significant element has a wide impact on the structure ofthe system and on its performance, robustness, evolvability, and scalability. It is an element that is important for understanding the system.
Architecturally significant elements include the following:
Major classes, in particular the classes that model major business entities
Architectural mechanisms that give behavior to these classes, such as persistency mechanisms and communication mechanisms
Patterns and frameworks
Layers and subsystems
Interfaces
Major processes, or threads of control
Architectural views are like slices cut through the various models, illuminating only the important, significant elements of the models.
1.15 Group Discussion: Architecture
What architecture roles are defined in your organization? Enterprise Architect? Solution Architect?
What is the relationship between these various architecture roles?
17
Chapter 1 - Solution Architecture Overview
1.16 Resource: Software Engineering Institute (SEI)
Research Areas
Architecture
Architecture Reviews
Commercial-off-the-Shelf (COTS) Architecture
Product Line Architecture
Quality Attributes
System of Systems Architecture
1.17 Resource: SWEBOK
Guide to the Software Engineering Body of Knowledge (SWEBOK)
Based on IEEE standards
Knowledge Areas
Software Requirements
Software Design
Software Construction
Software Testing
Software Maintenance
Software Configuration Management
Software Engineering Management
Software Engineering Process
Software Engineering Tools & Methods
Software Quality
Software Engineering Body of Knowledge (SWEBOK)
http://www.computer.org/portal/web/swebok/
18
Chapter 1 - Solution Architecture Overview
1.18 Resource: OpenUp
Free
A lean Unified Process that applies iterative and incremental approaches within a structured lifecycle.
Embraces a pragmatic, agilephilosophy that focuses on the collaborative nature of software development.
Tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
OpenUp
Provides information on these architecture topics:
• Shared Vision
• Use Cases & Scenarios
• System-wide Requirements
• Abstraction
• Patterns
• Incremental Design & Development
http://epf.eclipse.org/wikis/openup/
19
Chapter 1 - Solution Architecture Overview
1.19 Resource: Microsoft Library
Free
Extensive library of architecture articles
Ties architecture concepts to Microsoft products
Useful for all architects
Excellent for organizations that use a lot of Microsoft technologies for their core solutions
Primary focus on application & technology architectures
1.20 Group Discussion: Methodologies
What architecture or software development methodologies are in use today in your organization?
20
Chapter 1 - Solution Architecture Overview
1.21 Summary
An Enterprise and Solution are both Systems, and therefore many of the same architecture practices apply to both;
The Enterprise Target Architecture guides and constrains the Solution Architecture;
The Enterprise Architecture Roadmap orchestrates the sequence of solution deliveries;
Solution delivery updates the Enterprise Architecture Baseline; and
There are many additional resources available for solution architects.
21
Chapter 2 - Core Solution Architecture Methods
Objectives
After this chapter, you will be able to:
Develop a shared vision;
Draw the solution boundary using a context diagram;
Identify external interfaces and understand their importance;
Use partitioning to manage complexity; and
Allocate requirements to ensure quality and alignment.
2.1 Shared Vision
Architecture is a team effort.
All stakeholders must collaborate for success.
A “shared vision” is a critical success factor.
The “shared vision” must be understood & embraced by all stakeholders.
Chapter 2 - Core Solution Architecture Methods
Grady Booch
An architecture is just a collective hunch, a shared hallucination, an assertion by a set of stakeholders about the nature of their observable world, be it a world that is or a world as they wish it to be. An architecture therefore serves as a means of anchoring an extended set of stakeholders to a common vision of that world, a vision around which they may rally, to which they are led, and for which they work collectively to make manifest. When I say that an architecture is a shared hallucination, I mean that an architecture-as-artifact is a naming of the mutually agreed-upon set of design decisions that shape a software-intensive system. While an architecture is just an abstraction of reality, an architecture-as-artifact is a declaration of that shared reality. In this way, that shared hallucination represents a common vision among a set of stakeholders as observed simultaneously through severaldifferent points of view and represented by a set of interlocking models.
Source: [Shared]
2.2 Example Shared Vision
24
Chapter 2 - Core Solution Architecture Methods
2.3 Draw the Boundary
The first step in defining a software solution is to understand the boundaries ofthe solution
Without clear boundaries, a solution will bea moving target
Enables separating the components that reside internally within a solution and the components that reside externally
Boundaries are defined by understanding:
The overall intent of the solution
The external events that trigger the solution's functionality
The external processes on which the solution has dependencies
2.4 Well-defined Interface
“well defined interfaces” has been an architecture principle for many architecture styles throughout the past 30 years
Structured analysis and design
Message-based architecture
Object-oriented
Enterprise Application Integration(EAI)
Service-oriented architecture (SOA)
25
Chapter 2 - Core Solution Architecture Methods
2.5 Example: Context Diagram
Notes
• A fundamental activity for any architecture analysis is to define the system boundaries.
• After the system boundaries are identified, identifying your business partners and your system interfaces with them is the 2nd step.
• A Context diagram is a top-level Data Flow diagram that has just one Process element representing the system being modeled, showing its relationship to external systems.
• Understand industry standards to facilitate interoperability with partners,
26
Chapter 2 - Core Solution Architecture Methods
2.6 Identify the External Interfaces
Interface specifications are critical to define interface frequency, protocols, and expected volume
Must specify data elements: format as well as business meaning
Must specify acknowledgment & error handling mechanisms
Must be reviewed & approved by all impacted stakeholders
2.7 Subsystems
A subsystem is a collection of classes, interfaces and components that make up a development package
Defined such that they can be assigned todifferent development teams
Should have high cohesion and low coupling to ensure maintainability
Subsystems describe the design/build-time system structure, interfaces and dependencies
Subsystems
One of the most important functions of the architect and the architecture team is the careful partitioning of classes, interfaces and components into subsystems and the management of the dependencies between these subsystems.
Subsystems can be farmed out to different development teams for detailed design and implementation. A good architecture will maximize cohesion within a subsystem and minimize the amount of coupling between the subsystems. This makes it much simpler for the development teams as they can spend less time communicating, negotiating and understanding the interfaces between the teams. The larger the project, the more important this becomes, especially if the teams are
27
Chapter 2 - Core Solution Architecture Methods
geographically dispersed.
Subsystems are the level at which design, development, builds and testing are performed. Development teams should ensure that the build time directories and structures map to the subsystemstructure defined in the architecture.
If the development team finds it prudent to further divide a subsystem into finer-grained subsystems, the development team is responsible for the documentation for the fine-grained subsystems, not the architecture team.
2.8 Subsystem Context Diagram
Subsystem diagrams illustrates system components that are designed, developed, and released independently.
28
Chapter 2 - Core Solution Architecture Methods
2.9 Layers
The layers architectural pattern decomposes the functions of a software system into defined groups
Higher layers depend on lower layers
Advantages of layering:
Enhance portability
Can skip builds of lower layers when they have not changed
Facilitate communication by suppressing detail
Layers
Layers build on subsystems and provide additional organization. This leads to additional advantages such as improved portability, the ability to build higher level layers without the need to build lower levels that potentially change less frequently, and allows architects and designers to “rollup” subsystems of the architecture into very simple, high-level views, which make it easier to communicate system wide concepts.
Higher level layers can depend on lower level layers but not vice versa. This keeps the architecture straightforward and helps to ensure that the rebuild of an upper layer does not require the rebuild of a lower layer.
Formal or strict layering is a paradigm where any layer can depend only on the layer immediately below it. Relaxed layering allows a layer to depend on any layer below it.
Layering is very common and has been proven to be a very successful technique.
29
Chapter 2 - Core Solution Architecture Methods
2.10 Example: Subsystems with Layers
<<layer>> Business Domain
<<subsystem>>Settlement
<<subsystem>>Customer
<<layer>> Foundation
<<subsystem>>XML Parser
<<subsystem>>Date-time
<<subsystem>>Database
<<subsystem>>Mortgage
Dependency
Example: Subsystems with Layers
Subsystems and layers allow the system to be structured into smaller, more manageable, organized parts.
Layers and subsystems are both represented using UML packages. The example above illustrates how a subsystem can depend on other subsystems in the same layer. It can also depend on subsystems in layers below it. You can imagine how convoluted the architecture would be if we allowed lower layers to depend on upper layers!
30
Chapter 2 - Core Solution Architecture Methods
2.11 Components
A component is a modular and easily replaceable implementation construct
Provides services through a set of interfaces
Can be made up of several classes, interfaces and resources
Depends on a component framework to provide start-up and communication
Encapsulates both state and behavior
Describes the run-time system
Components
Component-based development makes it easier to integrate off the shelf software, encourages reduced coupling and simplifies the process of replacing parts of the application without impacting the rest of the system.
Components execute in a component framework which provides startup and communication services. There are several component models available including EJB, Java Beans, CORBA and COM. Thesemodels all require certain standard interfaces to be implemented so that the component is easily replaced by a more appropriate component (that implements the same interfaces) if the need arises.
• Components are often:
• Purchased rather than developed
• Started in a separate process or thread
• Configurable
Developed, tested and delivered separate from other components
Found at run-time using location transparent naming services
Components can be very coarse-grained and made up of smaller components. Components can be of many different types such as databases, tables in databases, source files, jar files, EJBs, servlets, web browsers, Java applications, etc. This allows for high-level discussions about the major components of a system as well as detailed discussions regarding fine-grained components.
31
Chapter 2 - Core Solution Architecture Methods
2.12 Decomposing the System
The architect is responsible for decomposing the system into subsystems, layers and components
The architectural style/pattern chosen typically specifies the allocation of responsibilities to components and their relationships (e.g. SOA, MVC)
General architectural patterns provide guidance on general partitioning strategies
2.13 Partitioning Patterns
Source: [POSA]
32
Chapter 2 - Core Solution Architecture Methods
Software Partitioning Strategies
There are many different ways to approach partitioning. The diagram illustrates some of the patterns related to partitioning. Each software architectural style (e.g. event driven architecture, SOA) has different strategies for partitioning a system.
2.14 Example Partitioning Based on Patterns
Model-View-Controller - the solution is composed of collection of model components, view components, andcontroller components
SOA - the solution typically consists of business processes, sub-processes, composite services, and atomic services
Master-Slave – the responsibilities are allocated between the controlling master component and slaves that handle each transaction
Pipe & Filter – the responsibilities are allocated based on a sequential sequence of work where output from one process is input to the next process
3 Layer – the responsibilities are divided into 3 general categories: User interface, business logic, and data access. Each layer has multiple components. The UI layer typically has components by UI object and event, theapplication/business logic is based on domain objects and methods and the data access layer is based on the data model.
33
Chapter 2 - Core Solution Architecture Methods
2.15 Example: Healthcare SOA Framework
HL7 System Functions Direct Care Supportive Information Infrastructure
Other
Business Process
Value Chains
CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core BusinessServices
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
EntityServices
Information Management
Information Management
Information Management
Information Reporting and Management
Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)
ApplicationServices
Ambulatory Care Systems,In Patient Care Systems
Logistics SystemsFinancial Systems
Decision Support Systems
Data MartsRepositories
Business Objects
ImplementationProfiles
Integrated Healthcare Enterprise (IHE) Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
Example SOA Partitioning
The diagram illustrates the HL7 SOA Framework that shows the component types per architecture layer.
2.16 Requirements Allocation
Regardless of how the system is partitioned, the requirements must be allocated to the defined partitions (e.g. subsystems, layers, components)
Requirements can be allocated to software components, hardware components, or manual procedures (i.e. non-automated tasks)
Requirements may be associated with multiple components
Requirements may be split into multiple system requirements and then allocated to components, maintaining traceability to the original requirement
Requirements allocation ensures the component satisfies the requirements the component is “responsible for”
34
Chapter 2 - Core Solution Architecture Methods
2.17 Group Discussion: Requirements Allocation
To what level are requirements allocated today?
Is testing performed at the component level?
How are global requirements (e.g. apply to many components) handled?
2.18 Configuration Management Implications
Development Baseline
Implementation
Application
Data
App_Core
App_TestApp_Utilities App_Conversion
Subsystem 1 Subsystem ... Subsystem N
Component A Component ... Component .Z
For large systems ...decompose into components
Data_CoreData_TestData_Utilities Data_Conversion
Database 1 Database ... Database N
For large systems ...decompose into components
uses
Environment
Env_SpecificVariant
Env_CoreEnv_Specific
Variant
uses
SourceObject
ExecutableDocumentation
SourceObject
ExecutableDocumentation
SourceData
Documentation
Can by of type
contains
contains
InstallationApplication
ManagementDatabase
ManagementOutput
Management SchedulingSecurity
AdministrationBackup &Recovery
Notes
The design of the configuration management repository is based on the architecture partitioning. The build process is a bottom-process where the lowest level components are built first and then assembled to compose subsystems.
35
Chapter 2 - Core Solution Architecture Methods
The partitioning has an impact on:
• The granularity of the software that can be released independently
• The security (i.e. access control) placed on each subsystem and component items
• The number and complexity of the interface and build dependencies
2.19 Release Management Implications
Release Management Considerations
The dependencies between the components must be considered when identifying the environments needed and the flow of software releases. The diagram illustrates a typical flow of releases considering a shared architecture and database schema.
36
Chapter 2 - Core Solution Architecture Methods
2.20 Testing Implications
Test Strategy
The diagram illustrates a typical test strategy, where the test mirrors the bottom-up development process, where testing is performed at multiple levels.
37
Chapter 2 - Core Solution Architecture Methods
2.21 Work Pattern & Skill Set Implications
Persistence DesignInterface Development
Create Activity Diagram
Persistence Interface Development
Discover Resources
Develop Custom Processes
Discover Resource Handlers
Develop Resource Interfaces
Develop Resource Handler Interfaces Generate XML from
Rational Rose
GUI Prototype
Design Web Interface
Develop Web Interface
Prototype Web Interface
Requirements & Analysis
Develop Use CaseDevelop Analysis
Object Model
Develop Sequence Diagrams for Complex
Processes
Requirements
Develop JSP
Unit Test Processes
Persistence Development
Develop Logical Data Model
Generate BC4J Entities &
Associations
Generate BC4J Views and View
Links
Develop Design Object Model
Business Rules Development
Develop Entity Business Rules
Generate Application
Modules
Integration Testing
Test Service
Develop Cross-Entity Business
Rules
Unit Test Application
Module
Develop Java Classes
Test Application
Develop Resource Handler
Implementations
Develop Resource Implementation
Develop Physical Data Model
Unit Test Entities & Views
Unit Test Resource Handler
Map Use Cases to Services
Team Specialization
The diagram illustrates how teams are formed around the architecture and focus on specific component types.
38
Chapter 2 - Core Solution Architecture Methods
2.22 Work & Build Dependencies
Component Dependencies
The architect must understand the component dependencies and the impact on the development and build processes.
39
Chapter 2 - Core Solution Architecture Methods
2.23 Increment/Sprint Planning
Increments & Sprints
In order to plan increments and sprints for large initiatives the architecture dependencies must be considered. Scaffolding or stubbing techniques can be used to facilitate incremental development.
40
Chapter 2 - Core Solution Architecture Methods
2.24 Sizing Implications
Element Type # elements Deliverables Work allocation by roleUpdate Business Manager
Simple Window # simple windows 4 Updated classes Y Design Analyst 50%
Developer 50%
Medium Window # medium windows 8 Updated classes Y Design Analyst 50%
Developer 50%
Complex Window # complex windows 12 Updated classes Y Design Analyst 50%
Developer 50%
Develop Window OID
Simple==read only # Windows 8 Window OID Y Design Analyst 80%
Developer 20%
Medium==CRUD functions # Windows 16 Window OID Y Design Analyst 70%
Developer 30%
Complex > CRUD functions # Windows 32 Window OID Y Design Analyst 60%
Developer 40%
Develop letter object interaction diagram # Letters 8 Letter OID Y Design Analyst 100%
Develop form object interaction diagram # Forms 8 Form OID Y Design Analyst 100%
Develop batch program OID # Batch programs 8 Batch Driver OID Y Design Analyst 100%
Develop business manager OID # Business Managers 8 Business Manager OID Y Design Analyst 100%
Estimating Development Costs
The architecture and partitioning strategy has an impact on how work is performed, by which role, and the number of development items needed.
The above example illustrates that estimating the work takes into account the number of development items by type, their complexity, and the role/skills required. Items types to consider:
• User Interface items (e.g. windows)
• Component types based on pattern (e.g. business managers, controllers, views)
• Domain objects, with complexity based on # and complexity of business rules
• Database tables based on data model
• Letters and forms generated
• Reports
2.25 More Than Executable Architecture
So far we have focused on the architecture required to meet the functionalrequirements
There are two (2) other architectures to be considered:
Development Architecture which is the processes, software, & hardware required to support the solution development, test, and deployment
41
Chapter 2 - Core Solution Architecture Methods
Operations Architecture which is the processes, software & hardware required to support the monitoring & operations of the solution
Consider additional architectural components needed for testing (e.g. test data generation, test harnesses, load simulation), data conversion, and data quality verification
2.26 Development Architecture
Development Environment Tool Integration
The more seamless the integration is between the development tools, the easier it is to perform new releases.
# Tool Type Description
1 Requirements Management
Tracks requirements, relationships between requirements and relationships to use cases
42
Chapter 2 - Core Solution Architecture Methods
# Tool Type Description
2 Analysis & Design Modeling for analysis & design artifacts – use case diagrams, class diagram, class descriptions, sequence diagrams
3 Integrated Development Environment (IDE)
Develop code elements, including Java and XML files
4 Configuration Management
Provide version management of all lifecycle deliverables – requirements, design, code, test
5 Build Extract configuration items from CM repository, build executable elements, place executable elements in CM repository
6 Test Management Define test cases, test scripts, and test data and manage relationship between these items and requirements & design elements
7 Defect Tracking Define defects, assign defects, manage defects through lifecycle, and associate defects to any configuration item within CM repository
8 Code Analysis Analyze code for common problems – memory error, leak detection, application performance profiling, security issues, code coverage analysis
9 Test Automation Automate test scripts for regression testing and load testing
43
Chapter 2 - Core Solution Architecture Methods
2.27 Operations Architecture
Operations Architecture Considerations
The solution must integrate with the Operations Architecture to meet key architecture qualities and requirements. Examples:
• Performance can only be measured if the solution can be instrumented or an operations component is able to monitor the performance of the solution components.
• Supportability typically requires the solution's ability to send alerts to a central Event & Alert Management component (e.g. management console/service) using a standard protocol (e.g. SNMP).
• Availability is achieved through automated backup and recovery capabilities.
• Centralized security administration is achieved through administration of an identify repository that the solution accesses using a standard protocol (e.g. LDAP).
• Coordinated, automated job execution is achieved through an enterprise job scheduling capability that executes solution jobs in a defined sequence based on established SLA time frames.
44
Chapter 2 - Core Solution Architecture Methods
Establishing Solution Architecture Standards
A recommended method to ensure the operational quality attributes are considered (e.g. manageability, supportability), is to establish a standard set of requirements that all solutions must address. A sample of these requirements are provided:
The solution shall support IETF Simple Network Management Protocol (SNMP) traps as a mechanismfor event notification.
The solution shall include a command line interface to allow automation of system processes (e.g. service startup, service shutdown).
The solution should use access control information stored in an external LDAPv3 complaint directory.
Security event logging will be enabled to provide a record of security related events that relate to major system security events, administrator functions, access to critical files, and user authentication activity.
The solution must support fail-over to another instance or another server in the event of a failure.
The solution must provide the ability to migrate setups/data between environments with minimal reconfigurations, reentry of data, or installs.
The solution must support version control of the product's development, test, or production configurations via an external management software product.
The solution should provide end-to-end traceability of each transaction. Each message element of a transaction should be loggable each time it enters or leaves a host system of the solution.
2.28 Group Discussion: Integrating Operations Architecture
In what ways is the executable solution architecture integrated with the operations architecture?
How does the solutions architecture impact operations?
45
Chapter 2 - Core Solution Architecture Methods
2.29 Summary
In this chapter we explored core solution architecture methods, starting with the importance of establishing a Shared Vision;
Next we discussed establishing the system boundaries;
Then we looked at the principle of well-defined interfaces using subsystems, layers, and components;
We discussed partitioning strategies and requirements allocation;
We looked at the impact of architecture on configuration management, release management, and testing; and
Finally reviewed development & operations architectures that should be considered.
46
Chapter 3 - Building Modern Applications
Objectives
Key objectives of this chapter:
Explain Rich Internet Applications (RIA)
Mobile platforms overview
"Rich Client" - "Thin Server" architecture
Design for Failure
DevOps
Virtualization and Containerization
3.1 Next Generation Methodologies, Approaches, Tools, andApplications
The design of modern applications is dictated by dramatic advancements in many IT areas, including methodologies, tools, and new approaches for designing and building applications
In order to stay relevant, IT professionals need to not only learn new things, but, more importantly, to be able to critically re-evaluate the contents of their professional knowledge baggage
◊ The good news is that many new-fangled ideas, methodologies, or "modalities" are nothing more than just the product of tweaking, rehashing, or rebranding of those successfully used in the past, and now backed by some new technology
Solution and Application Architects, as well IT practitioners in similar roles must be able to make informed decisions about diverse topics, including:
◊ New application architecture blueprints
◊ Capabilities of emerging technologies
◊ Automated build systems
◊ System packaging and deployment considerations
◊ etc.
Chapter 3 - Building Modern Applications
3.2 Web 2.0
The term Web 2.0 is used in contrast with the traditional ("old") Web 1.0, where users were merely passive consumers of static web content, with a new view of the Global Web where users can actively consume (and generate) rich and dynamic content using a variety of platforms, systems, and devices
Source: https://en.wikipedia.org/wiki/Web_2.0
3.3 Rich Internet Client Applications
One of the key enabler for Web 2.0 is a cohort of Internet-aware smart agents, like browsers, with JavaScript support
Browser vendors provide robust implementation of the JavaScript virtual machine narrowing down the differences in the language spec implementations across browsers that existed previously
Personal computers are now routinely shipped with 64-bit multi-core CPU architectures with plenty of RAM that well exceed the capabilities of mid-range mainframes of the last century
All these developments have brought about the emergence of Rich Internet Applications (RIA) running in client browsers and capable of handling dynamic content generation -- the job formerly performed by application servers using such technologies as PHP, JSP, JSX, ASP,
48
Chapter 3 - Building Modern Applications
ASPX, etc.
The RIA paradigm lends itself to designing powerful "Rich Client" - "Thin Server" applications
Notes:
As a language, JavaScript has recently undergone significant enhancements (version 6 and 7) making ita fully capable object-oriented language with functional programming support.
As a proof of JavaScript maturity is the fact that it now makes major inroads in the server-side programming (Node.js).
One of the criticism of JavaScript used to be its lack of type safety; now this deficiency has been addressed by the transpilation facility offered by TypeScript and similar systems.
3.4 Single Page Applications (SPA) with AngularJS
A number of JavaScript-based frameworks and toolkits allow you to createSingle Page Applications (SPA)
Single Page Applications use a combination of pre-defined HTML templates intermixed with dynamic content handled by JavaScript to create data-driven web pages
◊ For example, AngularJS is a client-side MV(C) framework written in JavaScript; originally developed by Google and now actively supportedby a vibrant development community
◊ Essentially, AngularJS helps move the display and non-sensitive business logic of web pages entirely to the browser side
Notes:
AngularJS introduces custom HTML tag attributes, e.g. ng-app, ng-model, etc. (that are silently ignored by browsers' HTML rendering engines) which are used as elements of a declarative language inside HTML pages.
Basically, Angular uses its own HTML-based DSL (Domain-Specific Language).
On page load, AngularJS JavaScript library introspects HTML for its custom tags and constructs the needed MV(C) components and supporting elements.
49
Chapter 3 - Building Modern Applications
3.5 Two-way Data Binding (the AngularJS Way)
AngularJS employs a two-way data binding mechanism on web pages, where any changes to the view are immediately reflected in the model (backed-up by JavaScript objects), and any changes in the model are propagated to the view
3.6 Other Client Side MV(C) Frameworks
There are other frameworks that take a similar approach to front-end development as AngularJS; they have their own unique strengths and weaknesses
Ext JS. Unlike AngularJS it includes a full GUI component library and charting library.
React. Appears to have a lower learning curve and higher performance according to many users
Backbone.js. A lightweight MVC framework created after AngularJS in 2010
◊ It positions itself as a lean alternative to heavyweight MVC frameworks such as Ext JS
50
Chapter 3 - Building Modern Applications
3.7 "Rich Client" - "Thin Server" Architecture
The RIA design model helps create the "Rich Client" - "Thin Server" type of application architecture
RIA applications communicate with the (application) server via AJAX connections or WebSockets
◊ WebSocket protocol is built on top of TCP; it uses HTTP-based handshake and is part of the HTML5 spec currently supported by multiple web and application servers
◊ WebSockets are not restricted by the same-origin script policy
The (thin) server side is usually fronted by a bunch of RESTful end-points
Essentially, the server's responsibilities stay within the traditional scope minus dynamic content generation
◊ "Outsourcing" content generation to client browsers significantly reduces load on the servers
Notes:
WebSocket Introduces New URI Schemes
The WebSocket Protocol (RFC 6455) defines two new URI schemes (protocols)
ws:
ws://theserver/theapp/ws
Basic WebSocket
wss:
wss://theserver/theapp/ws
WebSocket over TLS (Encryption, Authentication, Data Integrity)
3.8 Mobile Platforms
Mobile platforms provide solid foundation for the creation of RIA applications
Today there are four major platforms in the mobile space:
51
Chapter 3 - Building Modern Applications
◊ Android
◊ Blackberry
◊ iOS
◊ Windows Mobile
Those platforms are essentially mobile operating systems that allow users to run applications on hand-held devices
3.9 Types of Mobile Applications
Native Applications
Mobile Web Applications
Hybrid Mobile Applications
3.10 Native Mobile Applications
Apps specific to a given mobile platform (Windows Mobile, iOS, Blackberry, Android, etc.)
Coded in a platform-specific programming language and IDEs, such as Objective C or Swift for iOS (XCode), Java for Android operating systems (Eclipse-based ADT), C# for Microsoft Phone (Visual Studio)
Offer the best performance and usability
Full access to system devices and sensors: accelerometer, camera, file system, etc.
Ability to work without an Internet connection
Available in the target mobile platform's App Store
3.11 Mobile Web Applications
Applications created using standard web technologies: HTML5, JavaScriptand CSS
Deployed on a standard web server as regular web applications
52
Chapter 3 - Building Modern Applications
Rendered in mobile browsers
Page design takes into account target devices' screen size
Limited access to the underlying system devices
◊ Geolocation can be supported through the browser
3.12 Hybrid Mobile Applications
Hybrid mobile applications run on mobile devices inside a native executioncontainer like regular native apps
User Interface (UI) of hybrid mobile apps is built with standard web technologies: HTML, CSS and JavaScript and rendered in the device’s Web View native component (which may be based on the native browser engine)
The most valuable part of hybrid apps (which differentiate them from mobile web apps) is the embedded native device bridge that allows them to access native device capabilities such as accelerometer, compass, file system, device info, contacts database, etc.
◊ This component (e.g. a jar file or a dll) is platform-specific
The native bridge functionality is exposed via a set of JavaScript APIs that are used by hybrid apps to communicate with the bridge using AJAX calls,JavaScript remoting or similar portable communications mechanisms
Less performant than native apps
Available in target mobile platform App Stores
3.13 Hybrid App Tools and Frameworks
Apache Cordova (PhoneGap)
Ionic
React Native
Sencha Touch 2
53
Chapter 3 - Building Modern Applications
3.14 RIA as a Driving Force to Turn the "Thin Server" intoMicroservice(s)
The RIA model helps you build "Rich Client" - "Thin Server" applications
The "Thin Server" architecture further helps with breaking down potentiallymonolithic server-side code running on your application server (IIS, WebSphere, WebLogic, etc.)
At a certain point, you may want to start thinking about partitioning your application server code into separate services the code of which can be factored out and made run independently
◊ This approach dovetails with the service-oriented nature of microservices
◊ As an added value, microservices, when properly designed, can help with enhancing such QoS properties as:
Resiliency to system failures
System scalability
Note: One technical solution for addressing the "same-origin script policy" constraint when connecting from the client portion of your RIA application to multiple servers is the "Reverse Proxy" setup
3.15 So, How Can Microservices Help Me?
Development of microservices can be done in smaller teams practicing agile development practices
It becomes easier to view and treat applications (composed of a number ofinterconnected microservices) as distinct products with encapsulated functionality
◊ The product development model (as opposed to the project model) leads to the feeling of "ownership" of the application (your team carries the application production pager 24/7), which contributes to its overall better quality and yields other intangible benefits
You will get a better alignment between IT and business needs
◊ The product model facilitated by microservices maps better to business
54
Chapter 3 - Building Modern Applications
needs
◊ Product-oriented microservices are built around and aligned with business capabilities
Business Capability A → { Product X [, Product Y, …]}
Notes:
A development team working on a microservice is often referred to as a "Two pizza box" team.
3.16 The Data Exchange Interoperability Consideration
Microservices may be written in different languages (Java, C#, Python, Go, Ruby, etc.)
To ensure efficient data exchange between microservices inter-connected within complex distributed systems, the following technological approaches are used:
◊ Wire-level protocols (e.g. AMQP) with data encoding / decoding implemented in the respective client
◊ Interoperable data interchange formats, such as:
Google's protocol buffers [ https://developers.google.com/protocol-buffers/ ]
Apache Avro [ https://avro.apache.org/ ]
JSON ( JavaScript Object Notation )
XML
3.17 Microservices in Their Purest Form: AWS Lambdas
AWS Lambda is a pure compute service that does not require you to provision and manage servers (physical or virtual)
With Lambda services, you have a clear separation of concerns:
◊ You provide your application code in the form of a Lambda function as per AWS infrastructure-supported run-times: currently, C#, Python, Node.js, and Java are supported
55
Chapter 3 - Building Modern Applications
◊ AWS provides you with a dedicated, scalable, and highly available fleet of computing resources managed by AWS
You can create small utility services that could:
◊ Respond to events triggered by updates / inserts into the target service (e.g. Relational Database Service (RDS), DynamoDB, or S3)
◊ Respond to calls made through AWS SDKs
You need to be on AWS to take advantage of this service
Lambdas are perfectly suitable for creating [micro]service-oriented architectures
Notes:
You pay only for the actual time your Lambda function runs.
You are charged in 0.1-second increments multiplied by the number of Lambda function invocations.
You are only required to provide the amount of computing memory (the default is 128MB).
CPU of the instance running your lambda function is allocated in proportion to the requested memory.
3.18 The Microservices Architecture Design Principles
While the Microservices Architecture design principles are, in many aspects, close to those of SOA, including:
◊ Aid in creating (complex) composite applications made up of functionally orthogonal or complementary processes that are represented by [micro] services
◊ [Micro] services are cohesive and loosely coupled
◊ [Micro] services work in concert toward a common goal of delivering a business / utility value to end-users
Architecting solutions based on microservices, generally, takes a more comprehensive approach to re-factoring existing monolithic application
◊ In order to minimize (and, ideally, eliminate) service disruption, a good microservices architecture usually takes into account the operational aspects of the constituent services' life-cycles:
56
Chapter 3 - Building Modern Applications
Deployment, upgrading, decommissioning of older versions, and scheduled maintenance, etc.
3.19 Decentralized Processing
Under the centralized processing arrangements, there is a single service or a "facade" service interface that is used by remote clients
Microservices architectural patterns are about decentralized data management, where the functionality of the centralized service or the "facade" interface is broken into multiple services that carry out the required functions
Microservices take over the required functionality, like request routing, versioning, and data format negotiation (the "smarts")
Decentralization may break data processing consistency and synchronization, however ...
The required coordination of services (their life-cycle, versioning, configuration) should happen from a single point of authority
◊ This coordination service must have high availability (HA) quality of service in place
3.20 Crossing Process Boundary is Expensive!
When breaking down and partitioning "monolithic" applications, be acutely aware that you are foregoing some of the QoS properties of this architecture, like performance, maintainability, manageability, and throughput
Crossing process boundaries is expensive
◊ It is at least three orders of magnitude slower to make a call across a process boundary than it is to make the same call within the same process
3.21 Managing Microservices
After a specific number of microservices has been deployed in your
57
Chapter 3 - Building Modern Applications
software system, efficient coordination and non-disruptive management may become an issue
You may be required to establish control over services' lifecycle, their centralized configuration management, logical-to-physical resource mapping, transparent service versioning, etc.
Generally, it is a complex, multifaceted activity which depends on your operational environment and the nature of your business
In some cases, you may satisfy your operational needs by using Apache Zookeeper ( https://zookeeper.apache.org ), which offers services for highly reliable distributed coordination, centralized configuration management , and distributed synchronization
Netflix Open Source Software (OSS) Center (https://netflix.github.io/ ) provides a complete set of Java-based infrastructure components that canbe used to support microservices
You may also want to consider moving to a whole new deployment and execution platform, e.g. Cloud Foundry (https://www.cloudfoundry.org/ )
Notes:
Cloud Foundry is a PaaS (Platform as a Service) that you can install on-premise and run over VMware's vSphere virtualization infrastructure.
3.22 Traditional Enterprise Application Architecture (Simplified)
58
Chapter 3 - Building Modern Applications
Notes:
For session failover, application server vendors usually recommend using other products from them, e.g, a database that will hold the application state serialized from the application server container.
59
Chapter 3 - Building Modern Applications
3.23 Microservices Architecture Example (Simplified)
3.24 Design for Failure
With the distributed nature of the Microservices Architecture, Design for Failure (DFF) in one of the good design practices to mitigate potential service disruption
It is predicated on the "gloom & doom" assumption that any part of your system may break at any time, with a possible compounded effect from other failures
DFF is usually achieved through the following design decisions:
◊ Stateless design of your application
60
Chapter 3 - Building Modern Applications
Application state, where required, should be handled in an external persistent store/caching service either on-premise or on the client
◊ Load balancing between redundant instances running clones of your application
Proper capacity planning to avoid resource over-provisioning, or
Autoscaling (elastic computing) capability must be put in place
To manage failures effectively, you need to have:
◊ Trained Operational / DevOps staff
◊ Failure / Disaster Recovery processes in place
3.25 Fault Injection During System Testing
To be prepared for run-time failures of your system in production, you need to have a pre-production environment where you can simulate system failures
◊ In this environment, you deliberately "sabotage" a particular [sub-]system by injecting faults causing it to fail with simultaneous real-time assessment of the overall health and resiliency of the system under test
Duplicating system components, finding an alternative route for handling user requests, or otherwise mitigating the overall impact of a system failure leads to creating fault-tolerant architectures
Chaos Monkey developed by Netflix is a resiliency tool that helps applications tolerate random instance failures (https://github.com/Netflix/SimianArmy)
3.26 Architecting in the Cloud
To design your Cloud solutions for failure, use the following mechanisms:
◊ Design workflows and process that are interruption-tolerant and can resume on instance reboot
Make your application's design stateless; state should be outsourced
61
Chapter 3 - Building Modern Applications
to a centralized persistence store, if needed
◊ Have an adequate backup and restore automation strategy in place
Whenever possible, use the Cloud platform's managed services for functionality needed by your applications
3.27 The Building Blocks of a Fault-tolerant Application on AWS
Route53 (Elastic DNS service)
Elastic Load Balancer
Availability Zones
Regions
3.28 Dev and Ops Views
To survive in a competitive world, the Business demands more aggressiveproject time-lines to be delivered on tighter IT budges
To meet those demands, IT needs to re-think the ways development and operations are done in their organizations
In many organizations, there are two conflicting views of how things need to be done: those of the Dev and the Operations (Ops)
The Dev View The Ops View
• We have aggressive deadlines -- Business is all over us
• Ops are much too sluggish supporting us (provisioning integration environment, etc.)
• They lost the application zip file we emailed them yesterday night -- it was eventually found in their "junk mail" folder
• Overall, we don't have trust and confidence in Operations (Ops) -- theyare more like Oops, then Ops
• Dev is all over us• The application set-up guide sent by Dev
was not complete -- they missed some critical steps, which resulted in us wasting time
• With so many new applications being released in the environment, we can no longer guarantee uninterrupted services
• Overall, we don't trust Dev
62
Chapter 3 - Building Modern Applications
3.29 What is DevOps?
DevOps is short for Development and Operations
It is an approach to delivering software solutions in a continuous manner based on lean (minimizing waste of resources, reducing number of defects, etc.) and agile practices
DevOps help manage complexities of Enterprise applications by creating acollaborative environment with participants coming not only from Development and Operations, but also from Business, QA, and other stakeholder groups
◊ In other words, DevOps is not only about Development and Operations!
The DevOps practice has been popularized by organizations adopting the Cloud-as-a-Service computing model
3.30 More DevOps Definitions
You can view DevOps as
◊ a culture, or
◊ a cross-team software delivery discipline (paradigm)
that tries to reconcile competing perspectives (e.g. those of Dev vs Ops) and promote collaboration by stepping over the silos of isolated, group-centric interests
3.31 DevOps and Software Delivery Life Cycle
To efficiently increase the velocity of application delivery, DevOps activities span the whole software delivery life cycle (not only its deployment!):
◊ Development
◊ Testing
◊ Deployment
◊ Operation
63
Chapter 3 - Building Modern Applications
3.32 Main DevOps Objectives
Continuous software delivery planning and control
Software delivery processes optimization
Software delivery process consistency and predictability
Minimization of the number of software defects and unnecessary re-work
Software delivery cycle time reduction
Notes:
Planning is viewed by some developers as an unnecessary overhead hampering their "real work"; those developers rely on tribal knowledge of some opaque team processes they establish themselves. While it may work in a short-term perspective, the lack of transparency and overall planning across various stakeholder groups would normally result in problems with project delivery sustainability at faster rates.
3.33 The Term "DevOps" is Evolving!
Originally, DevOps was used to refer to the practice adopted by Operations to borrow some of the tools and processes used in software development
◊ For example:
Admin scripts were placed in a version control system
Now DevOps is used in the context of the shared responsibility between Development and Operations for delivering high quality software products
◊ For that, where appropriate, the reporting lines are merged and simplified
◊ Development goals (introduce code, configuration, etc. changes to the system) are aligned with those of Operations (maintain the target system stability)
DevOps nowadays is becoming more embracing being not only about Tools, but also about People and Processes
64
Chapter 3 - Building Modern Applications
3.34 Infrastructure as Code
"Infrastructure-as-Code" is a practice of provisioning infrastructure by executing system management and configuration automation scripts
Infrastructure-as-Code is effectively supported by such tools as Ansible, Chef, Puppet, Salt, IBM UrbanCode Deploy, Vagrant, etc.
◊ Essentially, these tools allow for an automated way to configure and manager hundreds, or even thousands of (mostly) identical servers running the required applications
This practice addresses three types of concern:
◊ Speed (you have shorter DevOps cycles)
◊ Cost (partially as a result of the Speed category above)
◊ Risk (e.g. with a tested configuration script, you eliminate human-factor errors)
Notes:
Under DevOps, Dev is granted system administration privileges to run the infrastructure set-up scripts to automatically provision the necessary development and testing environments.
Provisioning of other environments (staging, production) may still be the exclusive prerogative of personnel in the DevOps' Operations role.
3.35 Prerequisites for DevOps Success
A good relationship between Dev and Ops is a necessary but not sufficientcondition for the overall success of DevOps operations
DevOps success depends on the proper execution of all the technical aspects of the Software Development Life Cycle (SDLC) phases and stepsestablished in the organization
◊ Sometimes, the existing SDLC documentation needs to be adjusted to make it aligned with the agile practices used by DevOps
The following elements and capabilities need to be put in place for DevOps to meet its objectives:
◊ Alignment with the business needs
65
Chapter 3 - Building Modern Applications
◊ Collaborative development
◊ Continuous testing and integration
◊ Continuous release and deployment
◊ Continuous application monitoring
3.36 Alignment with Business Needs
In essences, DevOps is a business-driven software solutions delivery process
The DevOps practice is instrumental in reliably materializing a business idea in a software product, ultimately delivering value to customers
DevOps processes improve product time-to-market metric (faster time to value) and enable organizations to react to new market demands more quickly
With DevOps, customer feedback on product is captured and quickly incorporated in the next iteration of the product delivered in a continues manner
◊ The ultimate result of a fast accommodation of the customer feedback is an enhanced customer experience, customer loyalty, and larger market share
3.37 Collaborative Development
High quality software development is predicated on the collaborating development practices, including:
◊ Development teams' work is done in accordance with established code standards, styles, and living centralized developer documentation (wiki pages, etc.)
Development teams may be geographically dispersed or formed at the last moment, making the above practice indispensable
◊ The stewards of the target system's architecture and design are cooperating with development to quickly accommodate any design flaws / gaps identified during development
66
Chapter 3 - Building Modern Applications
3.38 Continuous Testing and Integration
Development of discrete software components must go hand-in-hand with the development and application of appropriate unit tests as prescribed by the Test-Driven Development (TDD) process
◊ TDD is an agile software development practice
Integration of software components must start as early as possible (even though the work on components may not yet been fully completed) and conducted frequently (sometimes, several times a day)
◊ This process is known as the Continuous Integration (CI) agile practice which helps with catching integration problems early
3.39 Continuous Release and Deployment
Deployment has always been one of the primary activities of Operations
◊ With the advent of the Cloud Computing, Development can take over some workload of application deployment and perform self-provisioningof cloud computing resources they require
To support reliable continuous releases, the deployment process must be automated; any failed deployments must be rolled back in its entirety in anatomic operation without affecting applications currently running in production
Deployment parameters, such as average deployment time, size of the deployment bundle, etc., must be recorded and kept for reference
3.40 Continuous Application Monitoring
Application run-time behavior monitoring should begin in production-like environments where the application would have setup, configuration, and other parameters close to those used in production
Things to look for:
◊ Run-time application behavior (CPU, RAM, I/O, average duration of garbage collection pauses, if applicable, and other metrics)
67
Chapter 3 - Building Modern Applications
◊ Response time per application interface
◊ Excessive or insufficient logging
◊ Logging of sensitive information
◊ etc.
3.41 Standing Up DevOps
There is no cast-in-stone rules
Every organization finds its own organizational form for DevOps
◊ Some companies create a joint DevOps group with a single reporting line
◊ Others establish a small contact group with representatives from all stakeholder groups
◊ Still others completely delegate Ops functions to Dev (mostly the case with Cloud-based shops)
3.42 Select DevOps Techniques and Practices
The DevOps is supported by a number of common techniques, practices, and capabilities:
◊ Collaborative steering
◊ Continuous testing of all aspects of the application delivery pipe-line
◊ A Version Control System
There is a wide choice of VCS systems that you can choose from: Git, CVS, SVN, Mercurial, TFS, etc.
◊ A Bug Tracking System
Bugzilla, FogBugz, JIRA, etc.
◊ Artifact Management
Apache Maven, Nexus universal repository solution, Apache Archivarepository manager, etc.
68
Chapter 3 - Building Modern Applications
◊ Iterative and frequent integration and deployment
◊ Automation
◊ Change Management
◊ Monitoring and auditing
3.43 Select DevOps Techniques and Practices
Collaborative steering
◊ Collaborative and transparent working environment promotes visibility and agility of software development processes
◊ In order to receive timely notifications or feedback, you may want to set up a Web UI dashboard publishing application lifecycle status in real time for all parties concerned
Continuous testing of all aspects of the application delivery pipe-line
◊ Where applicable, DevOps assures quality of software code; deployment scripts for all environments (QA, UAT, Staging, etc.); scripts for setting up the infrastructure components (VMs, databases, application servers, etc.),
3.44 Select DevOps Techniques and Practices
A Version Control System
◊ For change tracking and consistency of your application code, admin and deployment scripts, keep them in a version control system (VCS). Changes in your VCS should be accompanied with a check-in messagereferencing the defect # or change request # addressed by the code check-in, e.g. cvs commit -m "Bug #12YYZ fix" stringUtils.c
A Bug Tracking System
◊ Defects and issues must be tracked, accounted for, and acted upon
◊ The use of a bug tracking system is regarded as a hallmark of a maturesoftware engineering practice
69
Chapter 3 - Building Modern Applications
Iterative and frequent integration and deployment
◊ With this practice in place, you can guarantee consistent and predictable release times; applications can be installed reliably and repeatedly
3.45 Select DevOps Techniques and Practices
Automation
◊ Processes that need manual intervention may occasional fail due to thehuman factor (to err is human!)
◊ Establish the continuous automation practice. Keep automation scripts in your VCS
Change Management (CM)
◊ This is a critical aspect of DevOps that is often overlooked
◊ CM is a core part of the overall IT governance process
◊ CM helps track changes introduced to the target system by recording the reason for change, scope of change, references to the applicable VCS revisions of assets involved in the change, etc.
◊ CM as a system of record addresses the audit requirements and promotes transparency
3.46 Select DevOps Techniques and Practices
Monitoring and auditing
◊ Runtime parameters (response time, computing throughput, etc.) and other metrics of the application (service availability, time to recover froman outage, etc.) deployed in production must meet the client's Service Level Agreement (SLA); the only practical way to capture those parameters is to run your application in a production-like environment
◊ Have a dedicated production-like Performance (a.k.a. Production) Testing Environment (PTE) to collect critical runtime parameters of the application before its release into production
70
Chapter 3 - Building Modern Applications
3.47 Containerization and Virtualization
DevOps practice can hugely benefit from fast and reliable computing system provisioning
◊ For example,
In order to cope with increasing user traffic towards your web site, you must be able to rapidly horizontally scale your application in production by deploying and starting your application on one or moreseparate hosts
You may want to use exact replicas of your application code across different phases: dev, system integration testing, user acceptance testing, and production with only differences between the phases being the application's configuration settings and the number of allocated hosts
Your QA team may have a requirement to test an application runningon a range of operations systems, or hosts with different system parameters (e.g. amount of RAM and number of CPUs)
All of the above requirements (and more!) can be satisfied with pre-built machine images deployed as a single unit
◊ Deployment can be done on a physical machine (a long and not alwaysreliable process)
◊ Deployment on a virtual machine
◊ Deployment in a special container
3.48 Machine Images On Demand
Cloud platforms (AWS, Azure, etc.) offer clients a straightforward way to deploy virtual machines from pre-baked machine images that contain the OS of your choice and optionally some pre-installed software and configuration files
Currently, the EC2 AWS service, for example, offers a selection of 500+ AMI's (Amazon Machine Images) popular OSS and commercial software, available from the Amazon's marketplace
71
Chapter 3 - Building Modern Applications
You can also create your own bootable machine images from snapshots of your own machine instances running in the Cloud
This capability greatly shortens DevOps cycles
3.49 Virtualization
Virtualization is a technique of abstracting computer resources (hardware and networking) and allowing software (OSes and applications) to run in such environments as if it were a real computer
The collection of the virtualized resources are packaged as a Virtual Machine binary file
Virtual Machines are managed by hypervisors (Virtual Machine Managers)
Virtualization helps drive server consolidation initiatives that leads to betterresource utilization, management and driving operational costs down in public cloud computing, on-premise private clouds, and traditional enterprise data centers
3.50 Hypervisors
A hypervisor (or Virtual Machine Monitor (VMM)) is a specialized software program that creates and runs virtual machines
Hypervisors allow several operating systems (called "Guest OSes") to share a single hardware host at the same time in a way that
◊ Each guest OS receives its own fair share of virtualized resources (CPU, RAM, network, file-system, etc.)
◊ Guest OSes running on the same host do not affect others (allowing fora safe multi-tenant hosting arrangement)
3.51 Docker Containers
Docker is an open IT automation platform widely used by DevOps
You can view Docker as a system or a platform for creating virtual environments which are extremely lightweight virtual machines
72
Chapter 3 - Building Modern Applications
It leverages resource isolation features of the modern Linux kernel (cgroups and kernel namespaces)
Docker allows developers and system administrators to quickly assemble, test, and deploy applications and their dependencies inside Linux containers supporting the multi-tenancy deployment model on a single host
Docker’s lightweight containers help DevOps rapidly scale up and down applications
3.52 Docker Containers vs Traditional Virtualization
System virtualization tools or emulators like KVM, Xen, HyperV, VMware, etc. boot virtual machines from a complete guest OS image (of your choice) and basically emulate a complete machine, which results in a high operational overhead
Virtual environments created by Docker run on the existing kernel’s image of the host's OS without a need for a hypervisor
◊ This leads to very low overhead and significantly faster container start-up time
Docker-provisioned containers do not include or require a separate operating system (it runs in the host's OS)
◊ This circumstance puts a significant limitation on your OS choices
3.53 Docker Containers vs Traditional Virtualization
Overall, traditional virtualization has advantages over Docker in that you have a choice of guest OSes (as long as the machine architecture is supported)
◊ You can get only some (limited) choice of Linux distros
You still have some choice: e.g. you can deploy a Fedora container on a Debian host
◊ You can, however, run a Windows VM inside a Linux machine using virtual machine emulators like VirtualBox (with less engineering
73
Chapter 3 - Building Modern Applications
efficiency)
With Linux containers, you can achieve a higher level of deployed application density compared with traditional VMs (10x more units!)
Disclaimer: Docker runs everything through a central daemon which is not a particularly reliable and secure processing model
3.54 Docker as Platform-as-a-Service
Docker defines an API for creating, deploying and managing containers that make up highly distributed systems spanning multiple physical machines
◊ Docker-based systems can also efficiently run multiple isolated applications on a single physical machine
On-demand provisioning of applications by Docket supports the Platform-as-a-Service (PaaS)–style deployment and scaling
3.55 Docker Integration
Docker can be integrated with a number of IT automation tools that extendits capabilities, including
◊ Ansible
◊ Chef
◊ Jenkins
◊ Puppet
◊ Salt
Docker is also deployed on a number of Cloud platforms
◊ Amazon Web Services
◊ Google Cloud Platform
◊ Microsoft Azure
◊ OpenStack
◊ Rackspace
74
Chapter 3 - Building Modern Applications
3.56 Docker Application Container Public Repository
Docker community maintains the repository for official and public domain Docker application images: https://hub.docker.com/account/signup
3.57 Kubernetes
Kubernetes (https://kubernetes.io) is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts
Technology behind Kubernetes leverages many years of experience of running production workloads at Google and donated by Google to the Cloud Native Computing Foundation
It supports a range of container-centric tools, including Docker
Some users complain about difficulty working with Kubernetes:
◊ It requires different setup for different OSes
◊ Setting Kubernetes up takes a lot of planning
On the upside, Kubernetes allows efficient management of large clusters (up to 30,000 containers)
3.58 Other Containerization Systems
Linux containerization systems:
75
Chapter 3 - Building Modern Applications
◊ LXC (Docker uses this system under-the-hood)
◊ OpenVZ
◊ Linux-VServer
Non-Linux systems containerization systems:
◊ Oracle Solaris Zones (Containers)
◊ IBM AIX Workload Partitions
◊ FreeBSD Jails
3.59 Where to Use Virtualization and Containerization
Virtualization belongs to the Enterprise space (and big Ops budgets)
If you are an infrastructure provider and a Linux shop competing on price, use containerization
◊ Platform-as-a-Service (PaaS) vendors such as Heroku, OpenShift, and Cloud Foundry use Linux containerization
Containerization is the way to go if you are cost-conscious organization trying to save every nickel (most Linux containerization systems are free)
DevOps can hugely benefit from containerization as well (fast system provisioning: build, test, integration machines, etc.)
3.60 Summary
In this module we reviewed some of the "modalities" related to building modern applications:
◊ Rich Internet Applications (RIA)
◊ Mobile applications
Native
Mobile Web
Hybrid
◊ "Rich Client" - "Thin Server" architecture
76
Chapter 3 - Building Modern Applications
◊ Designing for Failure consideration
◊ The DevOps practice consideration
◊ Virtualization and Containerization technologies: their strengths and weaknesses
77