IRIS can use a KMS (Key Managment Service) as of release 2023.3.  Intersystems documentation is a good resource on KMS implementation but does not go into details of the KMS set up on the system, nor provide an easily followable example of how one might set this up for basic testing.

The purpose of this article is to supplement the docs with a brief explanation of KMS, an example of its use in IRIS, and notes for setup of a testing system on AWS EC2 RedHat Linux system using the AWS KMS.  It is assumed in this document that the reader/implementor already has access/knowledge to set up an AWS EC2 Linux system running IRIS (2023.3 or later), and that they have proper authority to access the AWS KMS and AWS IAM (for creating roles and polices), or that they will be able to get this access either on their own or via their organizations Security contact in charge of their AWS access.

This article explains how to deploy InterSystems IRIS Community Edition on AWS using the AWS Marketplace and EC2. It covers prerequisites, instance selection, security settings, SSH access, and first verification steps. The deployment can be completed using the AWS Free Tier and is suitable for developers who want to quickly start working with IRIS in the cloud.

Who this guide is for.

This guide is intended for developers, solution architects, and DevOps engineers who want to deploy InterSystems IRIS Community Edition on Amazon Web Services (AWS). No prior AWS automation experience is required, but basic familiarity with EC2 and SSH is helpful.

What you will achieve.

After completing this guide, you will be able to:

1. Launch InterSystems IRIS Community Edition on AWS
2. Configure a secure EC2 instance
3. Connect to IRIS using SSH and the Management Portal
4. Verify that IRIS is running correctly

Prerequisites

Before you begin, make sure you have:

1. An active AWS account
2. Permissions to create EC2 instances and security groups
3. An SSH key pair configured in AWS
4. Basic knowledge of Linux command line

Deployment overview

The deployment process consists of the following steps:

1. Launch IRIS Community Edition from AWS Marketplace
2. Select an EC2 instance type
3. Configure networking and security
4. Connect to the instance via SSH
5. Verify IRIS installation

Hi Gang! 

Did you know you can deploy InterSystems IRIS Community Edition on the cloud without paying for a license? You can try for free, and it could even come in handy if you want to show off that shiny new app you've created (maybe for the full stack competition..?) 

In this article I will provide a complete walkthrough on how to deploy IRIS on Amazon Web Services (AWS), and will also add a follow up for deploying on Azure. 

Now before I begin the walkthrough, I want to admit that I was terrified of using AWS the first time because I'd seen memes about how easy it is to rack up costs on AWS. So if you're thinking the same, I suggest you start by signing up to a Free Tier Account, which gives you $100 free credit to evaluate, and automatically shuts off to prevent charges. InterSystems IRIS Community Edition has a free license so if you pair the two, you can deploy without risk and completely for free. (Disclaimer: although I'm sure this is true, please do read the free account terms and make your own decisions 😅 )

Note, this article walks through deploying IRIS Community  on AWS, however the same guide can be followed to deploy IRIS for Health Community Edition, or with Bring-your-own-licence editions of IRIS and IRIS for Health, to deploy a fully licensed, production version of IRIS on AWS.

This is the second part of an article pair where I walk you through:

• Part I - Intro and Quick Tour (the previous article)
  • What is it?
  • Spinning up an InterSystems IRIS Cloud Document deployment
  • Taking a quick tour of the service via the service UI
• Part II - Sample (Dockerized) Java App (this article)
  • Grabbing the connection details and TLS certificate
  • Reviewing a simple Java sample that creates a collection, inserts documents, and queries them
  • Setting up and running the Java (Dockerized) end‑to‑end sample

As mentioned the goal is to give you a smooth “first run” experience.

Introduction

In today's rapidly evolving threat landscape, organizations deploying mission-critical applications must implement robust security architectures that protect sensitive data while maintaining high availability and performance. This is especially crucial for enterprises utilizing advanced database management systems like InterSystems IRIS, which often powers applications handling highly sensitive healthcare, financial, or personal data.

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

Nearline FHIR® Ingestion to InterSystems OMOP from AWS HealthLake

This part of the OMOP Journey, we reflect before attempting to challenge Scylla on how fortunate we are that InterSystems OMOP transform is built on the Bulk FHIR Export as the source payload.  This opens up hands off interoperability with the InterSystems OMOP transform across several FHIR® vendors, including Amazon Web Services HealthLake.

Another step in this implementation path, adding cross cloud, cross regional stretched IrisCluster with Mirroring + Disaster Recovery using the Intersystems Kubernetes Operator (IKO) and Tailscale

Though trivial, Id like to go multi-cloud with the stretched IrisCluster for a couple of reasons to socialize the power of Wireguard when it supplies the network for a properly zoned IrisCluster by adding another mirror role to Amazon Web Services in the Western United States based datacenter in Oregon.

Hey folks! Having recently onboarded to InterSystems, I realized that despite having a totally free and awesome Community Edition, it's not super clear how to get it. I decided to write up a guide highlighting all the different ways you can access the Community Edition of InterSystems IRIS:

Get InterSystems IRIS Community Edition as a Container

Working with a containerized instance of the Community Edition is the recommended approach for folks who are new to developing on InterSystems IRIS, and in my opinion it's the most straightforward. InterSystems IRIS Community Edition can be found on DockerHub; if you have an InterSystems SSO account, you can also find it in the InterSystems Container Registry.

In either case, you'll want to pull the image you want using the docker CLI:

docker pull intersystems/iris-community:latest-em
// or
docker pull containers.intersystems.com/intersystems/iris-community:latest-em

Next, you'll need to start the container: In order to interact with IRIS from outside the container (for example, to use the management portal) you'll need to publish some ports. The following command will run the IRIS Community Edition container with the superserver and web server ports published; note that you can't have anything else running that depends on ports 1972 or 52773!

docker run --name iris -d --publish 1972:1972 --publish 52773:52773 intersystems/iris-community:latest-em

As an IT and cloud team manager with 18 years of experience with InterSystems technologies, I recently led our team in the transformation of our traditional on-premises ERP system to a cloud-based solution. We embarked on deploying InterSystems IRIS within a Kubernetes environment on AWS EKS, aiming to achieve a scalable, performant, and secure system. Central to this endeavor was the utilization of the AWS Application Load Balancer (ALB) as our ingress controller.

Introduction

As the health interoperability landscape expands to include data exchange across on-premise as well as hosted solutions, we are seeing an increased need to integrate with services such as cloud storage. One of the most prolifically used and well supported tools is the NoSQL database DynamoDB (Dynamo), provided by Amazon Web Services (AWS).

The challenge for IRIS implementations, as it relates to Dynamo and other modern web services, is that there is no native support for interacting with Dynamo and AWS within ObjectScript.

I have started working on utilizing Epic on FHIR about a month ago.

Creating a Public Private Key Pair

mkdir /home/ec2-user/path_to_key
openssl genrsa -out ./path_to_key/privatekey.pem 2048

For backend apps, you can export the public key to a base64 encoded X.509 certificate named publickey509.pem using this command...

openssl req -new -x509 -key ./path_to_key/privatekey.pem -out ./path_to_key/publickey509.pem -subj '/CN=medbank'

In this post, we'll discuss our project that leverages Pulumi and Docker Compose to automate the deployment of InterSystems WSGI applications on AWS. The focus is on simplicity and efficiency, using pre-built infrastructure templates for provisioning and scaling AWS resources.

Overview

This repository automates the deployment of a WSGI-based application using AWS infrastructure templates and Pulumi’s Python SDK. The infrastructure is provisioned with Pulumi's declarative approach, while Docker Compose handles application orchestration.

Introduction

Accessing Amazon S3 (Simple Storage Service) buckets programmatically is a common requirement for many applications. However, setting up and managing AWS accounts is daunting and expensive, especially for small-scale projects or local development environments. In this article, we'll explore how to overcome this hurdle by using Localstack to simulate AWS services. Localstack mimics most AWS services, meaning one can develop and test applications without incurring any costs or relying on an internet connection, which can be incredibly useful for rapid development and debugging. We used ObjectScript with embedded Python to communicate with Intersystems IRIS and AWS simultaneously.Before beginning, ensure you have Python and Docker installed on your system. When Localstack is set up and running, the bucket can be created and used. 

If you're running IRIS in a mirrored configuration for HA in AWS, the question of providing a Mirror VIP (Virtual IP) becomes relevant. Virtual IP offers a way for downstream systems to interact with IRIS using one IP address. Even when a failover happens, downstream systems can reconnect to the same IP address and continue working.

For containers in ECS files are not editable if the file size is larger than ephemeral storage free space. For example if I have 4Gb free I can't edit 8Gb file. But if I start container with 50 Gb of ephemeral storage (24Gb free) I can edit my 8Gb file just fine. Even file attributes cannot be changed: chattr -i <file> fails if the amount of free ephemeral storage is not enough (and so db can't be mounted for writing).

This can cause iris container failure on startup if large DB is both RW and mounted on start.

Most transactional applications have a 70:30 RW profile. However, some special cases have extremely high write IO profiles.

I ran storage IO tests in the ap-southeast-2 (Sydney) AWS region to simulate IRIS database IO patterns and throughput similar to a very high write rate application.

The test aimed to determine whether the EC2 instance types and EBS volume types available in the AWS Australian regions will support the high IO rates and throughput required.

Minimal tuning was done in the operating system or IRIS (see Operating System and IRIS configuration below).

Nowadays, most applications are deployed on public cloud services. It brings many advantages including savings in human and material resources, the ability to grow quickly and cheaply, greater availability, reliability, elastic scalability, and options to improve the protection of digital assets. One of the most popular options is AWS. It allows us to deploy our applications usings virtual machines (EC2 service), Docker containers (ECS service), or Kubernetes (EKS service).

I am often asked to review customers' IRIS application performance data to understand if system resources are under or over-provisioned.

This recent example is interesting because it involves an application that has done a "lift and shift" migration of a large IRIS database application to the Cloud. AWS, in this case.

A key takeaway is that once you move to the Cloud, resources can be right-sized over time as needed. You do not have to buy and provision on-premises infrastructure for many years in the future that you expect to grow into.

Continuous monitoring is required. Your application transaction rate will change as your business changes, the application use or the application itself changes. This will change the system resource requirements. Planners should also consider seasonal peaks in activity. Of course, an advantage of the Cloud is resources can be scaled up or down as needed.

For more background information, there are several in-depth posts on AWS and IRIS in the community. A search for "AWS reference" is an excellent place to start. I have also added some helpful links at the end of this post.

AWS services are like Lego blocks, different sizes and shapes can be combined. I have ignored networking, security, and standing up a VPC for this post. I have focused on two of the Lego block components;

• Compute requirements.
• Storage requirements.

In this article, we’ll build a highly available IRIS configuration using Kubernetes Deployments with distributed persistent storage instead of the “traditional” IRIS mirror pair. This deployment would be able to tolerate infrastructure-related failures, such as node, storage and Availability Zone failures. The described approach greatly reduces the complexity of the deployment at the expense of slightly extended RTO.

The Amazon Web Services (AWS) Cloud provides a broad set of infrastructure services, such as compute resources, storage options, and networking that are delivered as a utility: on-demand, available in seconds, with pay-as-you-go pricing. New services can be provisioned quickly, without upfront capital expense. This allows enterprises, start-ups, small and medium-sized businesses, and customers in the public sector to access the building blocks they need to respond quickly to changing business requirements.

Updated: 10-Jan, 2023 

In this article, I am trying to walk through my deploying step of IAM on my EC2(ubuntu).

What is IAM?

IAM is InterSystems API Manager
you may reference to the link below to get more idea about IAM

https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_apimgr

Before deploying IAM

Check the license of your API host

Enable the User IAM

Deploy IAM

Reference 

https://community.intersystems.com/post/introducing-intersystems-api-manager

Download the image from the following link

https://wrc.intersystems.com/wrc/coDistGen.

Overview

Predictable storage IO performance with low latency is vital to provide scalability and reliability for your applications. This set of benchmarks is to inform users of IRIS considering deploying applications in AWS about EBS gp3 volume performance.

Summary

• An LVM stripe can increase IOPS and throughput beyond single EBS volume performance limits.
• An LVM stripe lowers read latency.

Being interoperable is more and more important nowadays. InterSystems IRIS 2022.1 comes with a new messaging API to communicate with event streaming platforms like Kafka, AWS SQS/SNS, JMS and RabbitMQ.
This article shows how you can connect to Kafka and AWS SQS easily.
We start with a brief discussion of the basic concepts and terms of event streaming platforms. 

Event streaming platforms purpose and common terms

Event streaming platforms like Kafka or AWS SQS are capable to consume a unbound stream of events in a very high frequency and can react to events.

I have described my efforts to optimize IRIS Mirror deployment in AWS ElasticContainer Service (ECS) in my prior article.

IRIS Mirror in the cloud (AWS) | InterSystems Developer Community | AWS
 

I have come to the opinion that IRIS Mirror is not as reliable as needed when deployed in ECS. The root of the problem is the fact that ECS randomly assigns one of the available IP addresses to each EC2 host or Fargate task it starts.

These get stored in iris.cpf file in MapMirrors section as shown here:

[MapMirrors.IRISMIRROR]

FAILOVER1=10.2ab.1cd.146,2188,,10.2ab.1cd.

I have been working on redesigning a Health Connect production which runs on a mirrored instance of Healthshare 2019. We were told to take advantage of containers. We got to work on IRIS 2020.1 and split the database part from the Interoperability part. We had the IRIS mirror running on EC2 instances and used containers to run IRIS interoperability application. Eventually we decided to run the data tier in containers as well. Later we switched from using EC2 instances to Fargate “server-less” compute.

I heard about Message Bank when we started redesigning a Health Connect production to run in containers in the cloud. Since there will be multiple IRIS containers, we were directed to utilize Message Bank as one place to view messages and logs from all containers.

How does Message Bank work?

I added Message Bank operation to our Interoperability Production. It automatically sends messages and event logs to the Message Bank.

Resending Messages

The Message Bank provides an interface for portal user to resend messages from the Message Bank portal.

Hi guys,

It's FHIR contest and this time, they provided something really cool: FHIRaaS

And to be part of this, @José Pereira and I team up (again) to deliver something easy to use and easy to understand how we did.

All source code to the article is available at: https://github.com/antonum/ha-iris-k8s 

In the previous article, we discussed how to set up IRIS on k8s cluster with high availability, based on the distributed storage, instead of traditional mirroring. As an example, that article used the Azure AKS cluster. In this one, we'll continue to explore highly available configurations on k8s. This time, based on Amazon EKS (AWS managed Kubernetes service) and would include an option for doing database backup and restore, based on Kubernetes Snapshot.

Installation

Let's get right to business.

Hi colleagues!

Often when we collaborate to someone's repo in GitHub we do the following cycle:

Fork-Clone-Change-Commit-Push-Pull-Request-Merge to the original repo.

This is all great and works fine!

And if we want to make a second collaboration right after the merge you need to perform "Fetch upstream" to your forked repo first to "ingest" your own Pull-request in the original repo.

Geeky git-professionals do it with ease but this was always a headache for me so I usually simply deleted the fork and created a new one.

And today I figured that Github added a new UI feature that I can easily fetch-upstream for my fork with the original one and make it up to date and capable for pull-requests.

Here is where the button is:

This is a relief! )

Wanted to share this relief and productivity tip with you!

Bring more collaborations to Github repos!

And speaking of PR - I just made a PR with docker to Google Cloud Run deployment for the FHIRaaS demo made by @Anton Umnikov for the current FHIR Contest! Looking for more of your contributions!

Like hardware hosts, virtual hosts in public and private clouds can develop resource bottlenecks as workloads increase. If you are using and managing InterSystems IRIS instances deployed in public or private clouds, you may have encountered a situation in which addressing performance or other issues requires increasing the capacity of an instance's host (that is, vertically scaling).

One common reason to scale is insufficient memory.