WA2325 Solution Architecture (SA) Practitioner’s Guide ...

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,


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


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

http://www.sei.cmu.edu/


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


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


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


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


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

http://www.dama.org/

http://www.iiba.org/babok-guide.aspx

http://www.opengroup.org/soa/source-book/gov/sgrm.htm

http://www.opengroup.org/soa/source-book/gov/sgrm.htm

http://pubs.opengroup.org/architecture/togaf9-doc/arch/


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


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


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


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

http://www.computer.org/portal/web/swebok/


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

http://epf.eclipse.org/wikis/openup/


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


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.


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


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


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


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


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


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


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


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


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


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


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




EntityServices

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


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


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


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


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


2.22 Work & Build Dependencies

Component Dependencies

The architect must understand the component dependencies and the impact on the development and build processes.

39


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


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


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


# 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


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


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


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.


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


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


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


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


◊ 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


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


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


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


◊ 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


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


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


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


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


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


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


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


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


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


◊ 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


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


◊ 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


◊ Iterative and frequent integration and deployment

◊ Automation

◊ Change Management

◊ Monitoring and auditing


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.),


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


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


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


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


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


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


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


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


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


◊ 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


◊ Designing for Failure consideration

◊ The DevOps practice consideration

◊ Virtualization and Containerization technologies: their strengths and weaknesses

77

WA2325 Solution Architecture (SA) Practitioner’s Guide ...

Documents

Transcript of WA2325 Solution Architecture (SA) Practitioner’s Guide ...