Automation Service architecture

<< Click to Display Table of Contents >>

Navigation:  Automation Service Overview >

Automation Service architecture

Overview

The architecture of Automation Service offers a series of technical features that provide a highly secure, reliable, and scalable Platform As A Service.

Automation Service delivers runtime environments which are optimized to run in the cloud.

Automation Service is cloud-centric and it makes the most out of modern technologies and services, including those that are not typically embraced by standard on-premises Bizagi project.

For introductory information about Automation Service, refer to Automation Service overview.

 

A service oriented architecture

Automation Service introduces a service-oriented architecture, which was designed and built for the cloud.

By implementing a highly-modular structure (principles from a service oriented architecture), Automation Service produces compatible and independently-deployable services which are easy to replace, while leveraging modern services which enhance security, reliability, and scalability.

This structure and architecture enable Bizagi's continuous delivery process that keeps up with the demands of software evolution.

 

Given that everything changes in the digital world at a significant pace, a service-oriented architecture design, along with implementation of agile development programmes, makes Automation Service a flexible service that quickly adapts to new business or IT requirements.

Service orientation has been proven to be an approach fit for the cloud, due to the flexibility inherent in loosely-coupled architecture.

 

Cloud_Architecture02

 

Though powered by Azure (as its Infrastructure As A Service provider) and managed by Bizagi, Automation Service takes it one step further by building a Bizagi service layer on top of some of the robust Azure services being leveraged.

 

Architecture

Automation Service architecture empowers a design which:

Optimizes the execution environment of your business applications.

Complies with strict governance and security requirements.

Is built to handle service interruptions and remain reliable (i.e, resiliency).

Can dynamically scale up or down.

Adheres to traditional Bizagi principles, such as offering: a consistent user experience across different supported devices (e.g. mobile phones), experience design to empower knowledge workers, and no coding required for your applications.

 

The following diagram illustrates how end users around the globe access Automation Service, and make the most out of the architecture features oriented to performance, security, reliability and scalability:

 

 

Architecture_users1OL

note_pin

Automation Service offers a virtual private cloud that grants each customer access to an isolated environment where the customer data and resources are not shared (encompassed within a dedicated Customer subscription), and the ability to choose appropriate levels of performance to match demand. Having separate resources, along with data isolation, allows for more predictable performance and gives a base for strict compliance in terms of data privacy and best governance and security practices.

 

The following architecture considers end users accessing Automation Service to work on the processes.

This architecture considers:

DNS: Resolves the service's URL.

Traffic manager: Routes requests to the customer's subscription, while considering availability of the service.

Security layer: A logical tier, filters requests and protects access, while having:

oNext generation firewall: Offers IDS, IPS, antimalware, along with preventing leaks and protecting the ports.

oApplication gateway (includes a WAF): Offering extra security at the web application level (e.g., prevents sql injection or cross-site scripting attacks), while routing requests to the target environment and its authorized endpoint (performing as well load balancing).

Network security: Provides IP whitelist filtering as an option (not recommended for mobility/acces from mobile devices), along with controls which disallow access to the environments except from the application gateway.

Subscription network: Encompasses the different environments of the customer (i.e., testing or production) and resources supporting Automation Service, while having:

oEnvironment subnets: Encompasses separately each of the resources of the different environments.

oDigital process layer: A logical tier, holds the components of Bizagi which run the process applications. This tier holds the Work portal (providing the UI for end users to log in and work in process applications) and the Scheduler service (running offline and batch tasks).

oStorage layer: A logical tier, holds the storage services to which the process applications rely on. This tier holds the Database (a relational, SQL database for process applications definitions and business data) and the Table storage service (holding logs), and encrypts data at rest.

 

Consider that a Bizagi security center monitors the security across all components so that incoming and outgoing network traffic is strictly controlled (traffic is also encrypted).

An appointed team of experts (i.e., Bizagi Cloud Operations team) is appointed to monitor 7x24 such aspects, along with receiving alerts upon potentially malicious traffic.

 

Customer admins

Admins from the customer side, do not require IT expertise, given that when subscribing, Bizagi appoints a team of expert to perform installation, upgrades, and overall maintenance of all required software, including the Bizagi platform and other services and components.

The Bizagi Cloud Operations team applies patches, service packs, fixes, and updates, and conducts monitoring and maintenance.

An admin on the customer's end, is in charge of watching after the operations of the process applications, and uses a browser to manage settings in those environments (e.g., connectivity to integrated systems of the customer, business parameters) through the Management Console.

 

Architecture_admin2

 

For more information on the responsibilities of the customer and its admin, refer to New to the cloud?

 

The following architecture considers end users accessing Automation Service to work on the processes.

This architecture considers:

DNS: Resolves the service's URL.

Management services: A logical tier, supports administrative operations in terms of managing the subscription and its authorized admins, monitoring BPUs of environments, performing deployments, while having:

oManage and Run services: The Bizagi service in charge of providing a central administration point for the subscription and the environments in it.

oManage and Run database: The database supporting the Manage and Run services.

oAccounts: The Bizagi service in charge of securely managing user accounts registered at Bizagi.com.

oAccounts database: The database supporting the Accounts service.

Security layer: A logical tier, filters requests and protects access, while having:

oNext generation firewall: Offers IDS, IPS, antimalware, along with preventing leaks and protecting the ports.

oApplication gateway (includes a WAF): Offering extra security at the web application level (e.g., prevents sql injection or cross-site scripting attacks), while routing requests to the target environment and its authorized endpoint (performing as well load balancing).

Network security: Provides IP whitelist filtering as an option (not recommended for mobility/acces from mobile devices), along with controls which disallow access to the environments except from the application gateway.

Subscription network: Encompasses the different environments of the customer (i.e., testing or production) and resources supporting Automation Service, while having:

oEnvironment subnets: Encompasses separately each of the resources of the different environments.

oManagement Console (web app): The application through which an admin manages settings of the environment.

oStorage layer: A logical tier, holds the storage services to which the process applications rely on. This tier holds the Database (a relational, SQL database for process applications definitions and business data) and the Table storage service (holding logs), and encrypts data at rest.

oVM Admin subnet: A temporary VM provisioned having the Management Console as a desktop application, in order to enable admins to perform certain management tasks which are not currently available at the Management Console (web app).