da Agency

Building a better asset and risk management platform with elastic Azure services

Elasticity means services can expand and contract on demand. This means Azure customers who are on a pay-as-you-go plan will reap the most benefit out of Azure services. Their service is always available, but the cost is kept to a minimum. This feature is so important, one Microsoft partner is using it as a point of differentiation.

Modular and elastic benefits

A key attribute of Azure is the interchangeable nature of services. Together with elasticity, Azure lets modern enterprises migrate and evolve more easily. For financial service providers, the modular approach lets customers benefit from best-of-breed analytics and in these areas:

Risk and performance analytics: Azure Data Lake Storage, DataBricks, and Azure Stream Analytics are just a few of the options for calculating risk.
Regulatory compliance automation (regtech): Automating compliance using Azure DevOps or using a service provider such as CloudNeeti simplifies an arduous task.
Investment management technology: Azure Virtual Machines or Azure Functions are just two options for managing investment portfolios.

With these capabilities, asset managers can build superior products that generate higher returns for their clients.

Financial services is a tough market

Competition in the asset management industry has ramped up: active vs. active, passive vs. active, and passive vs. passive, while margins are shrinking. At the same time, costly, outdated, and difficult-to-maintain legacy systems and technology are impacting both costs and operational efficiencies, putting a further drag on performance, while also making it difficult to scale. A new Microsoft partner, Axioma, is helping its clients in the financial services industry to regain and retain a competitive edge.

On-premises means rigid resources

Many investment firms have relied on physical datacenters as a means of maintaining control and security. But such properties and legacy systems are costly to maintain and difficult to scale. Given market volatility, fee compression, and an overall competitive investment landscape, fund managers are seeking flexible solutions to discover, create, and implement superior investment strategies and products. Specifically, the need is for enterprise-wide analytics, data, reporting, and data storage.

Cloud elasticity is a vital attribute

Axioma offers an open and flexible platform, where each building block is accessible via APIs. Their platform is a cloud-native architecture but modularity allows seamless integration points with other best-of-breed providers. For example, Axioma Risk is an enterprise-wide multi-asset class (MAC) risk-management platform. With the solution, asset managers can efficiently scale assets under management (AUM) to drive revenue growth and reduce the effects of margin compression.

Build a unified platform with Azure

When using Azure to build a platform, the users of the platform benefit from a common architecture. For example, Axioma helps to migrate solutions to their platform axiomaBlue. The clients then benefit from a common engine that calculates risk and performance analytics. Having one engine on the platform also means using the same underlying market and reference data. Clients, therefore, have a consistent view of risk and return across their enterprise and across front, middle, and back-office functions.

On a specialized platform, users can create flexible, modular, workflow solutions. For financial services, the platform approach means a highly specialized set of components, as shown in this graphic.

Azure services used

Axioma is a primary example of using the elastic and modular attributes of Azure to its fullest extent. They use these Azure services:

Service Fabric 
Virtual machines (Windows and Linux)
VM Scale Sets / Load Balancers
Azure Active Directory
Azure Data Lake
Azure SQL Database
Azure Database for PostgreSQL
Storage Accounts 
Service Bus/Relays

Recommended next steps

Go to the Azure marketplace listing for AxiomaBlue and click Contact me.
Quelle: Azure

da Agency

Uppkoppla: Ikea entwickelt Produktkollektion für Gamer

Stühle, Tische und sogar ergonomische WSAD-Tasten: Uppkoppla soll eine Kollektion für Gamer werden. Möbelstücke werden mit Körperscans den Bedürfnissen angepasst und stammen teils aus dem 3D-Drucker. Damit will Ikea Erfahrungen zu Produkten für Menschen mit Einschränkungen sammeln. (Ikea, Eingabegerät)
Quelle: Golem

da Agency

CloudForms 4.7 – What’s new with Ansible?

Ansible continues to grow and is the strategic automation engine for Red Hat’s business. Having a solid and constantly improving integration with Ansible is key for CloudForms’ future success.
 
Ansible Tower Workflows are widely used in by the industry to orchestrate and govern interactions between different playbooks. CloudForms has been able to run Ansible Tower Jobs since its 4.1 release. Starting with CloudForms 4.7, we will expand this support and will be able to utilize Workflows from the Service Catalog.
Setup
CloudForms is using the concept of Providers, to integrate with other systems. Each Provider integration takes care of building and maintaining an up to date inventory, executing operational tasks, listening to events, and some also support features like Metric Collection or more.
 
The existing Ansible Tower Provider was extended to include existing Workflows into the inventory. If an Ansible Tower Provider was already configured, CloudForms will automatically add the Workflows to its inventory, after the Upgrade to 4.7 was successfully rolled out. Instructions on how to upgrade CloudForms to 4.7, can be found in the Migrating to Red Hat CloudForms 4.7 guide.
 
Adding a new Ansible Tower Provider is very simple. Navigate to “Automation”, “Ansible Tower”, “Explorer” and click on “Configuration”, “Add a new Provider”.

Workflows have been introduced with Ansible Tower 3.1. Instructions on how to create and use Workflows can be found in the Ansible Tower Documentation.
Ansible Tower Workflows
After the inventory was updated in CloudForms, Ansible Tower Workflows can be found in “Automation”, “Ansible Tower”, “Explorer” and by clicking on “Templates”.

The new “Type” column will help to separate Workflows from regular Jobs. After clicking on a Workflow, a Detail page will give additional information.

Service Dialogs and Catalogs
From this page, a Service Dialog for the currently selected Workflow can be automatically generated. The Service Dialog will automatically be populated with all extra_var and survey fields. To verify the result or customize the Service Dialog to make it more user-friendly, navigate to “Automation”, “Automate”, “Customization” and “Service Dialogs” in the accordion on the left.

NOTE: Ansible Tower Workflows do not support the “limit” parameter. Since different Jobs in a Workflow can potentially point to different inventories, a “limit” might break a Workflow and is therefore currently not support.
 
When creating a Service Catalog item select the Ansible Tower Provider and from the list of the “Ansible Tower Templates” the appropriate Workflow. Note the new section “Workflow Templates” at the end of the drop-down list.  

Instructions on how to build a Service Catalog with some examples to get you started, have already been provided in the post Service Catalogs and the User Self-Service Portal.
Job Output
With the embedded Ansible capabilities of CloudForms it was already possible to get the output of a Job in the “My Services”, “Jobs” tab. Starting with CloudForms 4.7, this will also work for Jobs running on Ansible Tower.
 
After ordering a Service Catalog Item which is using an Ansible Tower Job Template, a new “My Service” Object is created (Navigate to “Services”, “My Services” to find them). Click on the just created object to see some metadata of the Job. Click on the “Jobs” tab to get more details, including start and runtime and the Job output.

The Job Output can be found on the bottom of the Jobs page.

Workflows, variables and limits
Since Workflows are a features CloudForms inherits from Ansible Tower, there are some concepts which have to be kept in mind as well.
Extra Variables and Surveys
Ansible allows the use of variables, which can be defined in many different ways, including the Playbook itself, a role, the environment or in Ansible Tower. Ansible Tower can use Surveys to build a form asking for those variable values when running a Job. When using CloudForms’ Service Catalog features combined with Ansible Tower, a Service Dialog can be created to build an intuitive and user-friendly interface.
 
When running an Ansible Tower Workflow, all Extra Variables are sent to all subsequent Jobs. For example, if a Workflow has three Jobs (job1, job2, job3) and there are three variables (var1, var2, var3), all three variables are sent to all jobs. It is possible to set a variable to be used in a specific job only.
 
While this is not really a problem, it’s something to keep in mind, for example by avoiding duplicate variable names in multiple Jobs.
Limits
To run an Ansible Playbook, an inventory has to be used to tell Ansible which endpoints to use and how to access them. Sometimes an Ansible Playbook only has to run on a subset of the inventory. Limits allow the user to use the same inventory but filter out a subgroup of systems.
 
CloudForms is using this feature when running an Ansible Playbook from a button assigned to a Virtual Machine.
 
Ansible Tower Workflows do not support the “limit” option though. Potentially a workflow can have many Jobs with different inventories (e.g. run a sub job on the storage, a sub job on the network and a sub job on some servers, each using different inventories). A limit parameter would potentially break this Workflow (e.g. if the limit would be a specific Virtual Machine, the network and storage jobs would fail).
 
Quelle: CloudForms