Takeaways and highlights from AWS re:Invent 2018

I had an opportunity to attend the seventh installment of AWS re:Invent. It was indeed a large gathering with more than 50,000 in attendance. Despite the size of crowds, the conference was very well run. I was not able to reserve a seat for all the workshops and sessions I was interested in advance but I was able to attend most of these workshops and sessions by queuing up in the walk-up line. Here are some of the takeaways and highlights.

Machine Learning was front and center

AWS provides ML capabilities at three levels of abstraction.

1. Fully managed services such as AWS Rekognition, Polly, Amazon Comprehend (NLP), Alexa, etc. AWS introduced Textract, a smart OCR service.
   
2. Managed execution of pre-built or custom ML models. SageMaker fills this role. 150+ machine learning algorithms are being made available in the AWS Marketplace.
   
3. Infrastructure for running ML tools such as MXNet, PyTorch, TensorFlow, etc.

• Several new sub-services for SageMaker were announced. For models that require a manual effort to train, AWS introduced SageMaker Ground Truth for classification of data via Mechanical Turk, or other sources. AWS also introduced SageMaker RL which performs training of models through rewards over time. To promote this service, AWS introduced DeepRacer, a fully autonomous 1/18th scale race car driven by reinforcement learning to help developers gain hands-on working knowledge of SageMaker RL. Amazon SageMaker Neo enables machine learning models to train once and run anywhere in the cloud and at the edge with optimal performance.
  
• AWS also announced AWS Inferentia, a new inference chip (yes, a custom-built computer chip) that promises to significantly reduce the time it takes to draw inference from an ML model.
  
• ML Insights works with Amazon QuickSight, a BI Service for interactive dashboards. ML Insights adds ML-powered anomaly detection, ML-powered forecasting, and Auto-narratives (add text descriptions automatically) to QuickSight dashboards.
  
• AWS Personalize is managed service for building and consuming recommendations models. It does the heavy lifting needed to design, train, and deploy a machine learning model under the covers.
  
• AWS RoboMaker provides a robotics development environment for application development (open-source robotics software framework, Robot Operating System,ROS), a robotics simulation service to accelerate application testing, and a robotics fleet management service for remote application deployment, update, and management.

AWS IoT services matured and can now connect to more things

• AWS IoT Core can now ingest data directly, bypassing the MQTT broker, by having the thing publish data to $aws/rules/ruleName topic. This eliminates the additional time and cost of publishing data to an IoT topic before it reaches the rules engine for desired processing.
  
• AWS IoT SiteWise opens up AWS IoT to data from industrial devices. It runs on a gateway that resides in customer's facilities and automates the process of collecting and organizing industrial equipment data.
  
• AWS IoT Events - Managed service to analyze patterns in IoT data respond accordingly.
  
• AWS IoT Things Graph can be used to connect devices and web services to build IoT applications. With this service, one can define interactions between them to build multi-step automation applications.

Serverless computing saw some important improvements

• AWS Lambda now natively supports Ruby.
  
• Lambda now supports custom runtimes (any runtime that can run on Unix) via Lambda Runtime API. C++ and Rust are now supported on Lambda using this new feature. Some other languages that third-parties have enabled on AWS Lambda are Erlang, Elexir, COBOL, and PHP. This feature will certainly encourage migration of legacy code to Lambda.
  
• A new feature of Lambda called Layers allows lambda functions to share code and data. For example, if several Lambda functions use a common library, that library does not need to deployed (duplicated) for each these Lambda functions. Instead, the library can be pulled in from a remote repository.
  
• Step function (orchestration of Lambda functions) can now invoke many AWS managed services (such as DynamoDB, AWS Batch, Amazon SQS, and Amazon SageMaker) directly in a defined flow.
  
• A new service called AWS Serverless Application Repository allows cataloging/discovery/assembly of a serverless application from existing Lambda functions.
  
• Lambda functions can now be placed behind an Application Load Balancer. This allows Lambda functions to be invoked directly via HTTP/HTTPS without having to use the API Gateway.
  
• Firecracker is a lightweight virtualization that is based on KVM. Amazon uses this technology internally to for its AWS Lambda offering as well. According to AWS, this service allows "launching of lightweight micro-virtual machines (microVMs) in non-virtualized environments in a fraction of a second, taking advantage of the security and workload isolation provided by traditional VMs and the resource efficiency that comes along with containers".
  
• AWS App Mesh - For monitoring and controlling communication across microservices on AWS such as ECS, EKS and Kubernetes running on EC2.
  
• API Gateway now supports Web Sockets. For Single Page Apps, live updates from the Server are usually sent over Web Sockets. This makes API Gateway more desirable as a backend for interactive SPAs.
  
• SNS now supports filtering of messages that are published to a given SNS topic. This can help discard undesirable messages at the SNS service level thus reducing traffic to a configured SNS recipient such as AWS Lambda or a microservice.

Databases and Storage

Amazon Aurora, a MySQL-based managed database service, was featured prominently in Werner's keynote. Amazon has famously vowed to get rid of all its Oracle databases. I imagine Aurora will replace a good number of these databases.

• Amazon Aurora added a Global database feature that is designed for applications with a global footprint. It allows a single Aurora database to span multiple AWS regions, with fast replication to enable low-latency global reads and disaster recovery from region-wide outages. I imagine one of the main motivations for adding this feature was to match Microsoft Azure Cosmos Database's globally distributed storage model.
  
• Amazon DynamoDB added ACID-compliant transactions across multiple tables in a given AWS region. This is important for applications that need to store data reliably across multiple tables in a single transaction. DynamoDB also added an On-demand pricing model where the application does not need upfront capacity planning (read/write capacity units).
  
• Amazon Timestream is a new database offering optimized for storing timestream data and is more cost effective than other storage options such as RDS. This is an attractive option for storing large amount of streaming data such as Telemetry data from IoT devices.
  
• Amazon had previously introduced AWS Glue to discover and catalog structured and unstructured data to aid in building of a Data Lake. Amazon has now introduced AWS Lake Formation, that sits on top of AWS Glue, and makes the job of configuring data sources and governance of the source data much simpler.
  
• S3 added intelligent tiering which automatically moves data to different pricing/availability tiers of S3 based on S3 object access patterns.
  
• AWS Transfer for SFTP is new fully managed SFTP service S3. This allows access to data stored in S3 buckets through SFTP protocol.
  
• Amazon introduced Amazon FSx for Lustre, a fully managed file system for use with Lustre, a file system used for large-scale cluster computing. Similarly, Amazon FSx for Windows File Server delivers a managed Windows file system (supports SMB, NTFS and AD) for use with workloads on Windows Server.

Amazon finally gets into the Blockchain game

Two Blockchain related services were announced.

1. Amazon Managed Blockchain is a fully managed service that makes it easy to create and manage scalable Blockchain networks using popular open source frameworks Hyperledger Fabric & Ethereum.
   
2. Amazon Quantum Ledger Database (QLDB) is a purpose-built ledger database that provides a complete and verifiable history of application data changes. The database is append only/immutable (can't be edited) and cryptographically verified (to ensure contents have not been tampered).

Finally, there were new offerings in the area of DevOps and Security

• AWS CodeDeploy now supports Blue/Green deployments for AWS Fargate and Amazon ECS.
  
• AWS Security Hub enables AWS customers to centrally view and manage security alerts and automate compliance checks within and across AWS accounts.
  
• AWS Control Tower helps create and maintain secure, well-architected multi-account AWS environments with respect to configuration of organizations, federated access, centralized logging, IAMs auditing, and workflows for provisioning new accounts.
  
• AWS Well-Architected Tool can review state of workloads and compare them to the latest AWS architectural best practices.
  
• AWS Outposts (later in 2019) - An on-premise hardware offering developed jointly by Amazon and VMWare. It is fully managed, maintained, and supported by AWS to deliver access to the latest AWS services on customer's site. It brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
  

Well, that's all for this year. I believe we are nowhere near utilizing the full potential of AI, Machine Learning, and IoT data. I have no doubt we will see many more outstanding innovations in these areas in the near future. We are now well-beyond dynamic websites (Web 1.0) and mobile computing (Web 2.0). Warp speed to AI, ML and IoT (Web 3.0).

Modern Web Architecture

Service Tier

REST, Xml, or JSON results returned to the Client

Responsive Web Clients

Single page sites (e.g. Angular.js)

Workers

Background processes working off queues

Generating meaningful invoice numbers

Problem

You want to generate invoice numbers for a customer.

General Approach

Commonly, a global or customer-specific integer counter is maintained for generating invoice numbers. The next number in the counter sequence is used as the invoice number when generating a new invoice.

A Different Approach

We can add more meaning to the invoice number generated for a customer. Here's one such approach that contains the customer identifier and the time an invoice was generated. The invoices numbers increase over time and hence can be sorted in ascending order.

public static String TimeBasedIdentifier(this string customerId)
{
  var now = DateTime.UtcNow;
  string dateStamp = now.ToString("yyMMdd");
  long elapsedSecondsToday = (long)(now - now.Date).TotalSeconds;
  return String.Format("{0}-{1}-{2}",
     customerId, dateStamp, elapsedSecondsToday.ToString("D5"));
}

Sample Output for customer 10000:
10000-20150603-68650

Limitation

This approach generates unique invoice numbers for a given customer as long as we do not generate more than one invoice per second for a given customer. We can use TotalMilliseconds (instead of TotalSeconds) if we want higher precision.

Storage: Entity Framework - Leveraging EF in a multi-tiered enterprise application

EF is not a data access layer but rather a tool that helps build a data access layer with less code. The following diagram depicts how EF can be utilized in a multi-tiered enterprise application. Each box can be thought of a separate layer/tier (or at a minimum, a separate Visual Studio project).

• Repository creates and uses EF DbContext. It may create a new DbContext for each request (disconnected client) or create, keep and use a singleton instance (connected client) of a DbContext . DbContext tracks changes. If changes are made to POCOs that are not monitored by DbContext (via DBSet), EF must be apprised of these changes via the EF API. If the domain is large, multiple domain-specific Repositories may be implemented.
• Repository abstracts the Storage API. Behind the scenes, it can use a persistence scheme other than EF, if it decides to do so later. DTOs (Data Transfer Objects) are persistence-technology independent data structures (POCOs) that shuttle the data between the Domain Model and the Repository.
• Domain Model uses the Storage API exposed by the Repository. The Repository can be "mocked" to facilitate unit testing of the Domain Model without having to create a real SQL Server database.
• Domain Model has its own set of POCOs that form the Data Contracts for the application. These are not the same as DTOs (we should be able to change the DTOs without breaking the Application API). The Domain Model exposes its functionality through a well-defined API and Data Contracts.
• Clients (Background daemon, WPF, ASP.NET,...) use the Domain Model and are decoupled from the SQL Server Database, EF, Repository, and DTOs. The clients are only dependent on the Data Contracts and Application API exposed by the Domain Model.

Entity Framework: Code and Database Separate Approach

The use of EF designers is optional. You can totally design your database and code separately and independently. You are not required to use any EF designers to reap most of the benefits of the Entity Framework. Here are the general steps for  the Code and Database Separate Approach.

1. Database: Create and optimize your database as you would normally.
2. .NET: Create POCO classes (not interfaces) that correspond to database objects. Foreign key references become collections of referenced objects in the POCO instance.
3. Create a DBContext derived class. Add DBSet<POCO_EntityType> members to DBContext for each DB table/view.
4. Use methods of DBContext to hydrate DBSets and perform LINQ queries (rich, intuitive, composable, and type safe; paging is supported via Skip and Take) against the DBSets. EF generates and executes appropriate SQL against the database.
5. You can provide hints to EF, if the default (convention-based) mapping of POCOs to DB objects used by EF is not what you expect. This can be done via attributes (data annotations) or via code.
6. If you modify the database, simply make corresponding changes to your POCO classes.

Quick Start

If you already have a database and want to create POCO classes from the database, use the Entity Framework Power Tools. Once POCO classes are created fix up the namespaces, move the classes to appropriate project, and make future changes manually, in a controlled fashion. 

Domain Driven Design

Ubiquitous Language

• Common (same) name of entities and processes between specifications and implementation
• Reduces assumptions
• Specification map to implementation

Bounded Contexts / Modules

• Modular design
• Single-purpose
• Module is isolated from other modules
• Well-defined interface
• Messaging and Pub-sub works well for communication between bounded contexts

Aggregate Roots

• Top-level entity that contains other dependent entities
• Top-level entity has globally unique identifier
• Entities inside the aggregate are unique within the aggregate root ( but not globally)
• Can  be globally referenced

Cloud Services

IaaS

Infrastructure as a service

A Virtual Machine (VM) built by the enterprise is hosted by a cloud host. This provides control down to the operating system to the enterprise. The cloud host manages the physical hardware.

PaaS

Platform as a Service

The enterprise hosts web applications and services in the preconfigured virtual machines provided by cloud host. The cloud host manages all layers up to the operating system level. The enterprise manages the applications.

SaaS

Software as a Service

The enterprise consumes software services hosted by the cloud host. For example, a hosted Sharepoint server falls in this category.

Web-based Services

SOAP - Simple Object Access Protocol

• Messages are encoded in Xml
• The format is defined by SOAP
• Envelope
• Headers (not the same as HTTP headers)
• Body - contains the data/payload and an Operation (verb) name that maps to some code method on the Server
• Several protocols collectively referred to as WS-* protocols (e.g. WSDL, MEX)
• Uses HTTP POST

POX - Plain Old Xml

• Transfer of XML data over HTTP
• XML is application defined. Often an XML Schema is provided
• HTTP GET to a URI fetches the desired data
• A client can specify preferred format in the HTTP header to get data in the desired format, such as XML, JSON, or AtomPub (if supported by the Service)
• Accept: application/json, application/atom+xml
• HTTP POST to a URI modifies the desired data

REST - REpresentational State Transfer

• Services are exposed as "resources" (URIs). Example, http://WeatherService.com/USA/CA/SANDIEGO would return the whether for San Diego, California
• CRUD operations on a resource (URI) are defined by HTTP verbs such POST, GET, PUT, and DELETE, respectively
• GET to a given URI may retrieve requested data or entity; POST to the same URI may add a new data or entity

Atom

• A specific dialect of XML
• Extensible, older clients simply ignore extra data
• Leverages REST to communicate

Atom+Pub

• XML format similar to Atom but extended to provide more functionality
• Builds on Atom by supporting retrieval and editing (publishing) of web resources

OData

• Extends Atom+Pub to provide RESTful data services for exchanging data over the Web
• Provides a standard way of editing and querying data
• Conventions for representing entities in AtomPub
• Query string conventions for addressing, filtering and paging data
• Constrained HTTP Operations for submitting requests
• Metadata support to learn about the service
• Based on HTTP, AtomPub, JSON
• Can expose different data sources (db, files,...) uniformly
• Can use LINQ from .NET client to send OData (RESTful) requests

SOA Application Blueprint

Here is a simple blueprint for building an application based on the Service Oriented Architecture (SOA).

The various participants in this architecture are as follows:

Application Domain Layer (ADL)
ADL is where the business logic or the brains of the application resides. ADL is the most valuable piece of this architecture. ADL should closely model the business entities, processes, and workflows without regard to data persistence or the user interface. ADL should be testable in isolation. Full suite of unit, functional and regression tests must be maintained and continuously executed. To isolate ADL from the Data Persistence Layer (DPL), a Data Persistence Adapter (DPA) is introduced.

Data Persistence Adapter (DPA)
DPA implements a well-defined interface that ADL uses to persist itself. A concrete implementation of DPA makes specific calls to the Data Persistence Layer (DPL) to do the actual saving and loading the of the data. A concrete, mock DPA should be written that emulates known data save and load behaviors. The mock DPA can be utilized by the ADL Test Suite to exercise the functionality of ADL on an ongoing basis.

Data Persistence Layer (DPL)
In most system implementations, this is the relational database management system such as Oracle, Microsoft SQL or equivalent. ADL never talks to DPL directly. Only Data Persistence Adapter (DPA) has direct interaction with Data Persistence Layer (DPL) usually through ODBC, JDBC, or a .NET Data Provider.

Application Service Layer (ASL)
ASL is the immutable interface to the System. The existing service methods and data contracts of ASL are never changed once published. However, new service interfaces, methods and data contracts can be added to extend the functionality of the application. The primary consideration in the design of this layer is the ease and efficiency of consumption of ASL Services by its clients such as the Application Presentation Layer (APL) and the Batch and External Systems (BES).

Application Presentation Layer (APL)
APL is the user interface of the application. It usually takes form of a Web Site or a Desktop Application. APL never calls ADL, DPA, or DPL directly. It does all data querying and manipulation through the Application Service Layer (ASL).

Batch and External Systems (BES)
An application may require offline, asynchronous, or batch processing. Furthermore, external systems may need to access the System to query or update data. Like APL, BES never calls ADL, DPA, or DPL directly. It does all data querying and manipulation through the Application Service Layer (ASL).

Using Queues to improve performance and reliability

Enterprise Systems typically involve two or more applications that collaborate with each other to run a business process. One of the ways that participants of an Enterprise System can share information is queuing. Logically speaking, queues are a system resource where applications in an Enterprise System can place messages for each other. Microsoft Message Queuing (MSMQ) is an example of such a queue.

Message queues provide a repository for inter-application messages and ensure guaranteed delivery of messages. In MSMQ, a queue may be defined as a transactional queue ensuring that the messages are enqueued, and hence dequeued and delivered, in the original order. Furthermore, a transactional queue persists each message received to ensure guaranteed delivery in case of a system crash.

Queues are useful in many Enterprise System scenarios. These scenarios have one thing in common: one application places a message in the queue and another application picks up the message from queue and acts on it. This allows us to distribute work among applications in an Enterprise System. Queues can also improve throughput of an Enterprise System.

Let's consider a stock order processing system that receives a stock order from client applications through a web service call to an endpoint it hosts. The orders must be processed in the order they are received and must not be lost. During peak trading hours of trading, it is likely that the stock order processing system will be receiving orders at a much higher speed than it can process them. In a monolithic, single-threaded stock order processing system, the throughput of the stock ordering system is constrained by the speed at which it can process the orders. Granted to improve performance we can spin two threads: one to receive orders and the other to process the order. But to ensure guaranteed delivery and in-order processing of stock orders received we will have to cook up our own scheme.

Now consider how we can design the stock order processing system more elegantly using queues. Our System will have three components:

1. Transactional Queue
2. Listener Application
3. Order Processing Application

Transactional Queue

A transactional queue can be created using MSMQ.

Listener Application

The job of the listener application is to simply host the endpoint for the receiving the stock order requests and to enqueue these requests as messages into the Transactional Queue.

Order Processing Application

The job of the Order Processing Application is to dequeue a message from the Transactional Queue and to act on it (i.e. to route stock orders to an external trading system).

Some of the benefits of this queue-based design are follows:

1. Stock orders delivered guaranteed because of the Transaction Queue
2. Stock orders are processed in the order they are received because of the Transaction Queue
3. The Listener Application continues to enqueue Stock Order messages even if the Order Processing Application goes down or can't keep up with the rate at which the stock orders are being received
4. We are able to scale Order Processing Application up (more powerful machine) or out (more machines) to improve throughput of the stock order processing system

Enterprise Application Integration Patterns

Messaging Pattern

The Applications participating in an Enterprise Solution communicate with each other using a common messaging system. The message publishing application follows the fire and forget model where it places a message in the shared messaging system and forgets about it. Other interested applications listen for these messages and act on them as business rules dictate. The most common implementation of a messaging system is a queue. The queue semantics ensure delivery of messages in the order they are received. A robust messaging system guarantees delivery via local persistence of message and multiple delivery attempts. The delivery guarantee is important because all participant applications in an Enterprise Solution may not be online all the time. Microsoft Message Queuing (MSMQ) and Oracle Advanced Queues are examples of messaging systems.

Shared Database Pattern

If all applications participating in an Enterprise Solution have access to a common database, the applications can exchange data by reading/writing to the common database. This is a less robust solution than the Messaging Pattern because a change in the common database schema may require modifications to participating applications.

Service Oriented Architecture (SOA) Pattern

The applications participating in an Enterprise Solution expose their functionality as a Public API that other applications can consume. This approach is more robust than sharing a database but still causes some coupling between applications due to dependence on the Public API. There is also an implicit assumption that all collaborating applications are online all the time. The most common incarnation of SOA are SOAP and RESTful Web Services.

Shared File Pattern

In this pattern, the publishing application writes a file with appropriate data and/or instructions to a shared network resource. The interested applications read this file and act on it as appropriate. On the surface, this approach seems to be a highly decoupled and robust. However, for a complex application this method of collaboration can be cumbersome and requires agreement on content location, file access policies, shared file disposal, frequency of file drops and retrievals, and meaning of the file content and format.

Messaging + SOA Pattern

For a complex Enterprise Solution with many participating Applications, Messaging provides the most robust solution. Messaging Pattern is even more effective when it is used as a way to communicate Commands among participating applications rather than detailed application data. Following the preceding paradigm, the Messaging Pattern can be combined with the SOA Pattern. For example, let's say an Enterprise Solution consists of an Accounting Application and a Shipping Application. When a payment is received from the customer for an order, the Accounting Application publishes a message stating that an order is OK to ship. The message contains the May Ship Order command with an additional parameter Order Id (Messaging Pattern). When the Shipping Application receives the message, it calls the Public API of the Accounting Application (SOA Pattern) to get the details of the order to ship and proceeds with shipping.

Coherent Architectures

In his paper, Urban and Enterprise Architectures: A Cross-Disciplinary Look at Complexity, Roger Sessions talks about Coherent architectures that are:

• Easier to implement
• Easier to maintain
• Easier to adapt
• Are less complex

By gleaning into architecture of buildings, Sessions finds four attributes of architecture that make an architecture coherent. He contends these attributes are equally applicable to Enterprise architecture.

1. Scale Range - There must be a range of architectural scales ranging from the very small to very large. For example, in buildings bricks make up the walls, walls make up the rooms, and rooms make up the building. Similarly, in an Enterprise architecture, there is a scale range of artifacts: data rows, tables, databases, programs, APIs, services, components, sub-systems, systems
2. Scale Hierarchy - There is an obvious  hierarchy of elements in a building. Buildings contain rooms, rooms contain walls, and walls contain bricks. Similarly, in Enterprise systems, raw data is contained in data rows, data rows are contained in tables, tables in databases, and databases are usually accessed through a well-defined programmatic interface. In a Coherent architecture, this hierarchy is clearly decipherable.
3. Scale Connections - Couplings are between elements of like scale. For example, bricks couple with bricks to form a wall. Walls couple with other walls to form a room. In an enterprise system, for example, Web Services collaborate with other Web Services, but not with the underlying database of another system.
4. Scale Tightness - The higher up you go in the hierarchy, the weaker the connection strength and there are fewer connection points. For example, two autonomous systems are likely to communicate through an asynchronous message rather than a synchronous method invocation. Furthermore, connection points will be fewer between the two autonomous systems than between a data access layer of a subsystem and its database.

Reference: http://www.objectwatch.com/whitepapers/SessionsSalingaros01.pdf

Enterprise Service Bus

Enterprise Service Bus (ESB) is an architecture style that provides plumbing for heterogeneous systems (legacy, client-server, SOA, message-oriented middleware, MOM) in an enterprise to collaborate in order to carry out the business processes.

ESB decouples tiers within a system by brokering messages sent among the tiers. ESB controls flow of messages to command handlers and subscribers.

ESB utilizes the following primary constructs:

• Messages/Events - ESB orchestrates routing of the messages to systems to support stateful and stateless business processes. ESB employs adapters to transform messages into a format suitable for the target system on the ESB
• Standards-based messaging - Supports complex Message Exchange Patterns (MEPs) such as Web Services, Messaging Middleware, Intelligent routing, Request/Response communication, One-way event notification
• Service Registry - Provides a common directory of all services provided by systems in the Enterprise. Service Registry provides another layer of indirection to where these Services are physically present. The participants in ESB access all services through the Service Registry and are agnostic to physical addresses of these services

ESB attempts to reduce strong coupling between systems by providing for abstractions over underlying Services, APIs and Messaging Systems. ESB ensures delivery of messages:

• To the Right place (system)
• At the right time (messages are delivered in correct sequence and within specified timeframes)
• In the right format (ESB uses adapters to convert messages into appropriate formats for seamless consumption by target systems)

ESB goes beyond traditional Hub and Spoke architecture prevalent in Enterprise Application Integration (EAI) by supporting a distributed architecture for message routing and transformation. All systems communicate in the same way with the ESB. ESB transforms and routes the message to the target consumer per the configuration. ESB also provides mechanisms for monitoring messages as they are move through the enterprise.

Some of the services provided by ESB include:

• Relay - Shuttles messages from one system to another (perhaps, off-premise) system through firewalls
• Queue - Delivers messages to queues to be picked by the target system
• Topic - Provides pub-sub services. Systems can subscribe to events published by other systems. ESB delivers the events to subscribers