HEATone Architecture

Stan Mitranic December 2016

Agenda

• Introduction
• Architectural Principles Overview (Stan)
• Service Fabric (Stan)
• Azure, Environments, Deployments (Stan)
• Unified Agent (Herve)
• Agent-Server Messaging (Herve)

© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 2

Agenda – Continued…

• SOA, EDA, DDD, CQRS (Alex)

• HEATone Services Framework (Alex)
• How To Build A HEATone Service (Alex)
• User Story Analysis (Lorrin)
• Patch (Chris)
• Q&A

© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 3

Why Do We Need Change?

• We have different architectures, data-models, APIs, deployment

processes, configuration, administration, etc.
• A natural and expected outcome with M&A
• Complex, fragile integrations
• The full potential of the original vision is not realized
• We are building a cloud-first product offering
• We need a cloud-first architecture and deployment model
• New set of challenges compared to running on-premise

• HEATone is a new product with a new vision

• More than just putting together features from existing products

© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 4

Architectural Principles
• Consistent cloud-first architecture across teams and services
• SOA – Service Oriented Architecture
• Autonomous services with well defined responsibilities and data ownership
• Service remains logically consistent in the presence of failures

• EDA
• Reduce coupling between services, avoid direct calls / dependencies
• Evolution of SOA; SOA + EDA a.k.a. SOA 2.0

• DDD
• How do we go about designing our services, their boundaries, entities
• CQRS
• Separating reads and writes, optimizing them separately
• Fits very well with above concepts
© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 5
Managing Services in The Cloud – Service Fabric
• Distributed systems platform that simplifies packaging, deployment and
management of microservices
• Full service lifecycle management
• Each service independently versioned, deployed, scaled
• Automated orchestrated deployment, upgrades, rollback
• Partitioning of services
• Scale services up and down at runtime
• Health monitoring
• Automated failover and rebalancing
© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 7
Service Fabric – Continued…

• Service Fabric Explorer UI

• Overview of SF Cluster
• Status of nodes, deployed
applications
• Active operations
• Deployments
• Upgrades
• Failovers
• Rebalancing
• Also fully managed via PowerShell cmdlets
© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 8
Service Fabric – Continued…
• Integrates with Azure infrastructure
• But runs everywhere – AWS, on-premise
• Fault Domains, Upgrade Domains
• Azure Load Balancer

• Local Service Fabric Cluster

• 1-node or 5-node
• Easy testing of service failure (or underlying server failure)

• We can all do Chaos Monkey-like testing on our own

© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 9

Service Fabric – Continued…
• VM Scale Sets
• Network Configuration
• Multiple subnets
• Network Security Group rules
• Load balancer

• Service placement constraints

• Simpler Dev/Test Environments
• One VM Scale Set
• One Subnet
• One Network Security Group
• One Load Balancer
• Simple deployment config change
© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 10
Service Fabric – Continued…

• High density
• Better utilization of resources
• More even distribution of load
• Different types of services
• Stateless Services
• Stateful Services
• Actor Framework

© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 11

Azure
• HEATone - built for the cloud; built in the cloud
• Disposable cloud infrastructure
• Spin it up, use it, tear it down
• Fully automated, easy to do; single command line:
• Provision the environment with all necessary resources
• Deploy HEATone services
• Bootstrap configuration
• Seed data
• Ready to use/debug/test
• Delete it when done
• Very different from traditional resources (physical servers, VMware VMs)
• State and context may be needed for longer-running efforts
• Shut down VMs when not in use, start them up later
© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 12
Azure – Continued…

• Resource Groups
• A logical grouping of resources
• A deployment unit
• HEATone Environment == Resource Group

• Azure Resource Manager

• ARM Templates
• Parameterized JSON files
• All Azure resources can be provisioned via ARM templates
• Can be provisioned via PowerShell, Portal, Azure REST API, .NET/NodeJS
SDKs, etc.
• Basis for our automated environment deployments

© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 13

14
REST API
• REST is a style
• OData - RESTful API Standard
• Full featured standard for data-focused APIs; metadata support
• Rich querying capabilities, including relationships
• Very well supported in ASP.NET
• Great fit for HEATone for read, query operations
• But for HEATone commands are better suited for writes
• Allows us to build generic UX components that work with any data sets
• Good tooling integration (all major BI vendors, client libraries for many
platforms)
• Different modules, different services will contribute API endpoints

© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 15

Packaging by feature

• Scrum teams are structured vertically (functional areas), rather than

horizontally (app tiers)
• A team owns all aspects of developing a feature
• User Story Analysis -> Contribute to High Level Design
• Contracts (Commands, Events, REST APIs, …)
• Service Modules (Business Components)
• Agent Modules
• Data Store
• UI
• Event Handlers in other services (e.g. indexing in Search Service)
• Automated Tests

© 2016 HEAT Software. All Rights Reserved. Proprietary and Confidential 16

Packaging by feature – Continued…

• Organization of projects, solutions, Git repositories, NuGet packages

will follow similar structure
• All logical components of a functional area, across tiers, are co-located
• Common libraries, frameworks, etc. will be their own projects
• Working with Ken Folsom’s team
• We are in the process of setting up project structure, repositories, builds

© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 17

Dev Process Update

• Continuous Integration
• Private NuGet server
• All development in feature branches
• Pull Requests
• All commits within the feature branch are included
• Even ones added after Pull Request is created
• It’s OK to submit a Pull Request even for WIP – solicit early feedback
• More details later in the week from Ken Folsom

© 2015 HEAT Software. All Rights Reserved. Proprietary and Confidential 18