Your reliable partner for successful IT projects

Fragmented nature of healthcare data

Healthcare information was scattered across different systems, making it difficult for providers to access and share comprehensive patient records. However, we addressed this challenge by developing a centralized health data platform that integrates data from various sources, making it easier for healthcare providers to access and manage information in a streamlined manner. This improved care delivery, research outcomes, and collaboration among stakeholders.

What we did

A centralized healthcare data system operates on the Microsoft Azure Cloud, which provides a highly scalable and secure infrastructure that meets the stringent requirements of the healthcare industry. We utilize a wide range of both commonly-used and healthcare-specific services available on Azure, such as Azure API for FHIR and Azure Security and Compliance Blueprint for Healthcare, to ensure seamless integration, interoperability, and adherence to industry regulations and best practices for data security and privacy.

Approach

We take an innovative, collaborative, and customizable approach to creating a centralized health data platform that prioritizes user experience. By working closely with our clients, we gain a thorough understanding of their specific needs and objectives, allowing us to tailor the platform accordingly.

Analysis of virtual machines

Our client utilizes MS Azure as its infrastructure provider and needs an immense amount of cloud resources/services worth millions of dollars for their projects. These resources are mainly virtual machines, and the cost of resources has continued to increase as time goes on.

What we did

Our team reviewed the usage of cloud resources to find ways to improve cost-efficiency. To accomplish this, we performed an analysis of virtual machines. Our first step was to determine the current parameters of each machine, including CPU, memory, disks, and hourly/monthly price. Then, we considered how each virtual machine was being utilized, examining metrics like CPU/memory utilization. From there, we determined the minimum parameters that each machine would need to meet its workload. Finally, we calculated the potential savings by subtracting the NewSizeMonthlyPrice from the CurrentSizeMonthlyPrice, resulting in the value of PotentialSavings.

As part of our analysis, we provide our client with recommendations for optimizing their virtual machines, which they are free to implement as they see fit. Another potential source of savings we identified was virtual machine disks that were not attached to any machines and were essentially unused. We considered these as candidates for deletion. Based on our calculations, the client could potentially save up to a million dollars over a year or two by following our recommendations. Our team accessed the client's resources using Azure CLI and utilized PowerBI for data import, aggregation, transformation, and export.

Next steps

We are currently working on a service that will automate the calculation of savings by importing client resources into the repository on a schedule. Historical resource data like metrics and usage will be phased out. After importing the resources, the service will analyze virtual machine utilization and determine the optimal size for each VM to achieve maximum savings. These findings will be saved as "recommendations" available for export. The service will track which recommendations were implemented and calculate the actual savings achieved. This will make the optimization process easier for our clients and help them get the most out of their resources.

The tech stack

Migration from AWS to Azure

Challenge

A client requested a solution migration from AWS to Azure. This involved transferring multiple microservices, database, and storage (from S3 to Azure Blob Storage). We also needed to ensure that the migration was seamless and didn't cause any downtime for dependent services. On top of that, we were faced with the added challenge of migrating the database to a different engine, specifically from Aurora MySQL to SQL Server.

Approach

In order to accomplish our objectives, our development team took a methodical approach to the migration process. We divided the migration into multiple stages, starting with adjusting the applications to work with AWS infrastructure. Next, we utilized an Infrastructure As Code (IaC) approach to deploy a new staging infrastructure on AWS. All migration steps were thoroughly tested in the staging environment before moving on to deploying the production environment. However, we made sure not to go live just yet. Once all tests were completed in the production environment, we switched all dependencies from Azure to AWS. We also had to take additional steps to synchronize data that had been modified in the old database during the brief switch-over period.

Electricity Auctions Carl Zeiss AG

Challenge

Our client wanted to rewrite an existing legacy application written in VB.NET into an application based on modern technologies: Cloud Based, Service-Oriented written in the latest C# version. A significant part of the existing functionality is now handled by an external solution, so the new application provides numerous interfaces to seamlessly integrate the new landscape into the existing company infrastructure.

Approach

The decision was made to go with Angular as a frontend framework, .NET Core (C#) for backend services, SQL Server for the persistence layer, and Entity Framework as ORM. All services are hosted in Azure Kubernetes Service in a private cluster. First, our team analyzed what functionality has to be re-implemented, considering that there is now a third-party solution, and agreed on integration points. The rest of the business logic was functionally decoupled into several services that would be responsible for each aspect of the business flow. The existing UI of the Desktop application was taken as a basis for creating a mockup of the future UI. Other references for UI mockups were existing company applications. The goal is to have a consistent design across different client applications. Each component of the system (backend services + UI application) was developed in an isolated manner, with its own build and release pipelines and code repositories. The code base that has to be shared was externalized as a nuget package with its own development and delivery lifecycle. Logging is centralized: all logs from all components are collected in Azure Application Insights, we support distributed tracing and follow Open Telemetry standards. We decided to use Azure Application Config for managing service configuration. All components communicate with each other either through the HTTPS protocol or through Kafka message bus. The UI is highly responsive thanks to the real-time updates and usage of server-to-client WebSockets communication.

The application became much more readable and maintainable: code was rewritten in the latest C# language version, following SOLID principles and N-tier and Microservices architecture. Due to externalizing part of business logic to a third-party system, the company has to maintain less business logic. The UI is now much more comfortable to use due to re-using of the Angular component library.