Pulumi

pulumi

This tutorial shows you how to deploy and automate a Docker container using Pulumi in Google Cloud Platform's Cloud Run with minimum permissions. Here's the GitHub Repository for reference: https://github.com/superjose/deploy-to-cloud-run-go Get the CLIs: . Create a Google Cloud Account Install Google Cloud CLI Install Pulumi CLI - We need it to build the Docker container. Install Docker Bootstrap the project: Create a directory: pulumi mkdir pulumi Run to initialize a pulumi project with Go (It can be your language of choice pulumi new go Navigate to the directory. pulumi cd pulumi Navigate to and create a new project. cloud.google.com Take note of the (Usually the project's name). project-id Generate the necessary permissions using gcloud CLI Login with the Google Auth CLI: gcloud auth login (Optional) Set the project in google cloud CLI (Can be changed anytime). This saves you from passing into every command. --project [PROJECT-ID] gcloud If your machine has multiple GCP projects, skip this step and pass the flag into every command. --project gcloud Create a service account (The account that Pulumi will connect to): gcloud iam service-accounts create pulumi-gcp --description="Pulumi GCP" Download the credentials for the service accounts and store them locally (Remember to replace with your GCP Project Id): [PROJECT-ID] gcloud iam service-accounts keys create ~/keys/gcp/pulumi-service-account-key-file.json --iam-account=pulumi-gcp@[PROJECT-ID].iam.gserviceaccount.com Set Pulumi's gcp credentials config path:
(This will connect the service account with Pulumi) pulumi config set gcp:credentials ~/keys/gcp/pulumi-service-account-key-file.json Set the GCP Project by doing: pulumi config set gcp:project [PROJECT-ID] Create a file (Inside the dir) and add the required permissions in : roles.gcp.yml pulumi includedPermissions # https://cloud.google.com/iam/docs/creating-custom-roles#creating
# Yaml to define the Pulumi GCP Roles that need to be created with gcloud CLI
title: Pulumi GCP Roles
description: |
  This policy ensures that all GCP roles are created using Pulumi.
stage: GA
# https://cloud.google.com/iam/docs/permissions-reference
includedPermissions:
  - serviceusage.services.list
  - serviceusage.services.enable
  - serviceusage.services.disable
  - serviceusage.services.get
  - serviceusage.services.use
    # Permissions for GCR
  - storage.objects.create
  - storage.objects.delete # Optional: only include if you need to delete images
  - storage.objects.get
  # Permissions for Google Artifact Registry
  - artifactregistry.repositories.create
  - artifactregistry.repositories.delete
  - artifactregistry.repositories.get
  - artifactregistry.repositories.list
  - artifactregistry.repositories.update
  - artifactregistry.repositories.downloadArtifacts
  - artifactregistry.repositories.uploadArtifacts
  - artifactregistry.repositories.deleteArtifacts
  # Permissions
  # Permissions
  - run.services.create
  - run.services.get
  - run.services.list
  - run.services.update
  - run.services.delete
  - run.services.getIamPolicy
  - run.services.setIamPolicy
  - iam.serviceAccounts.actAs
# NOTE: This should be removed the first time you're creating a role.
# This etag is to update the current active role (As GCP lets you manage multiple roles)
# I'm commenting it out so I can always replace the role
# etag: BwYS74Xx5y4= Create the with the file above:
(We assume we're running this code from the directory) pulumi_admin_role pulumi gcloud iam roles create pulumi_admin_role --project=[PROJECT-ID] --file='./roles.gcp.yml' In case you need to make edits, change the file and use: gcloud iam roles update pulumi_admin_role --project=[PROJECT-ID] --file='./roles.gcp.yml' We're also adding the role (I haven't found a better way) (Otherwise we'd get 403 errors when refreshing and updating in Pulumi)<sup>1</sup> serviceAccountAdmin gcloud projects add-iam-policy-binding [PROJECT-ID] --role roles/iam.serviceAccountAdmin   --member serviceAccount:pulumi-gcp@[PROJECT-ID].iam.gserviceaccount.com (The following will add the new role to the service account) gcloud projects add-iam-policy-binding [PROJECT-ID] --role projects/[PROJECT-ID]/roles/pulumi_admin_role   --member serviceAccount:pulumi-gcp@[PROJECT-ID].iam.gserviceaccount.com Our in the directory:
(Check the code for comments!) main.go pulumi We enable the required services (Artifact Registry, and Cloud Run). Artifact Registry is used to host the docker container image. Cloud Runner will launch the Docker image from Artifact Registry. We build the docker image locally (We specify the platform in case you're using an ARM chip like M1, M2, Snapdragon SQ, X Elite, etc.) We create a chain of "DependsOn" to notify Pulumi:
5.1 Services need to be enabled first
5.2 We create the Artifact Repository
5.3 We build the docker image and push it to Artifact Registry.
5.4 We pull the Docker Image from Artifact Registry and run it.
5.5 We add IAM permissions so it can be accessed from anywhere. package main

import (
	"errors"
	"log"
	"os"

	"github.com/joho/godotenv"
	"github.com/pulumi/pulumi-docker/sdk/v3/go/docker"
	"github.com/pulumi/pulumi-gcp/sdk/v7/go/gcp/artifactregistry"
	"github.com/pulumi/pulumi-gcp/sdk/v7/go/gcp/cloudrun"
	"github.com/pulumi/pulumi-gcp/sdk/v7/go/gcp/projects"
	"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

// This is the name you created in Google Cloud Platform (GCP).
const gcpProjectId = "deploy-to-cloud-run-go"

// The Docker Image Name
const dockerImageName = "my-app-docker"
const artifactRegistryServiceName = "artifact-registry-api"
const artifactRegistryRepoName = "my-app-artifact-repo"
const artifactRegistryRepoLocation = "us-east1"
const cloudRunAdminServiceName = "cloud-run-admin-service"
const cloudRunServiceName = "cloud-run-service"

// For more info: https://cloud.google.com/run/docs/locations
const cloudRunLocation = "us-east1"

// The tag for the Docker image
const imageTag = "latest"

// This is a url like: us-east1-docker.pkg.dev
// It is used to push the Docker image to Google Container Registry
// For more info: https://cloud.google.com/container-registry/docs/pushing-and-pulling
// The format is: <region>-docker.pkg.dev
var dockerGCPServer = cloudRunLocation + "-docker.pkg.dev"

// The full path to the Docker image
// It is used to deploy the Docker image to Google Cloud Run
// The format is: <region>-docker.pkg.dev/<project-id>/<repo-name>/<image-name>:<tag>
// For more info: https://cloud.google.com/run/docs/deploying
// Example: us-east1-docker.pkg.dev/deploy-to-cloud-run-go/my-app--artifact-repo/my-app-docker:latest
var dockerImageWithPath = dockerGCPServer + "/" + gcpProjectId + "/" + artifactRegistryRepoName + "/" + dockerImageName + ":" + imageTag

func main() {

	// Load the .env file
	err := godotenv.Load()

	if err != nil {
		log.Fatal("Error loading .env file")
	}

	pulumi.Run(func(ctx *pulumi.Context) error {

		enabledServices, serviceResultErr := enableServices(ctx)

		if serviceResultErr != nil {
			return serviceResultErr
		}

		artifactRegistryRepo, createArtifactErr := createArtifactRegistryNewRepository(ctx, &enabledServices)
		if createArtifactErr != nil {
			return createArtifactErr
		}

		dockerImage, buildAndPushErr := buildAndPushToContainerRegistry(ctx, &enabledServices, artifactRegistryRepo)

		if buildAndPushErr != nil {
			return buildAndPushErr
		}

		deployContainerErr := deployContainerToCloudRun(ctx, &enabledServices, dockerImage)

		if deployContainerErr != nil {
			return deployContainerErr
		}

		return nil
	})
}

type EnabledServices struct {
	CloudRunService         *projects.Service `pulumi:"cloudRunService"`
	ArtifactRegistryService *projects.Service `pulumi:"artifactRegistryService"`
}

func enableServices(ctx *pulumi.Context) (EnabledServices, error) {

	cloudRunService, cloudRunAdminErr := projects.NewService(ctx, cloudRunAdminServiceName, &projects.ServiceArgs{
		Service: pulumi.String("run.googleapis.com"),
		Project: pulumi.String(gcpProjectId),
	})

	if cloudRunAdminErr != nil {
		return EnabledServices{}, cloudRunAdminErr
	}

	artifactRegistryService, err := projects.NewService(ctx, artifactRegistryServiceName, &projects.ServiceArgs{
		Service: pulumi.String("artifactregistry.googleapis.com"),
	})

	if err != nil {
		return EnabledServices{}, err
	}
	return EnabledServices{
		CloudRunService:         cloudRunService,
		ArtifactRegistryService: artifactRegistryService,
	}, nil
}

func createArtifactRegistryNewRepository(ctx *pulumi.Context, enabledServices *EnabledServices) (*artifactregistry.Repository, error) {

	if enabledServices == nil || enabledServices.ArtifactRegistryService == nil {
		return nil, errors.New("enabledServices cannot be nil")
	}

	dependingResources := []pulumi.Resource{
		enabledServices.ArtifactRegistryService,
	}

	repo, err := artifactregistry.NewRepository(ctx, artifactRegistryRepoName, &artifactregistry.RepositoryArgs{
		Location:     pulumi.String(artifactRegistryRepoLocation),
		RepositoryId: pulumi.String(artifactRegistryRepoName),
		Format:       pulumi.String("DOCKER"),
		Description:  pulumi.String("The repository that will hold social-log Docker images."),
	}, pulumi.DependsOn(dependingResources))

	if err != nil {
		return nil, err
	}

	return repo, nil
}

func buildAndPushToContainerRegistry(ctx *pulumi.Context, enabledServices *EnabledServices, artifactRegistryRepo *artifactregistry.Repository) (*docker.Image, error) {

	if enabledServices == nil || enabledServices.ArtifactRegistryService == nil {
		return nil, errors.New("enabledServices cannot be nil")
	}

	if artifactRegistryRepo == nil {
		return nil, errors.New("artifactRegistryRepo cannot be nil")
	}

	// Lookup GOOGLE_CREDENTIALS environment variable which should hold the path to the JSON key file
	jsonKeyPath, present := os.LookupEnv("GOOGLE_CREDENTIALS_FILE_PATH")
	if !present {
		return nil, errors.New("GOOGLE_CREDENTIALS_FILE_PATH environment variable is not set")
	}

	// Read the JSON key file
	jsonKey, err := os.ReadFile(jsonKeyPath)
	if err != nil {
		return nil, err
	}

	dependingSources := []pulumi.Resource{
		enabledServices.ArtifactRegistryService,
		artifactRegistryRepo,
	}

	// Build and push Docker image to Google Container Registry using the JSON key
	image, err := docker.NewImage(ctx, dockerImageName, &docker.ImageArgs{
		Build: &docker.DockerBuildArgs{
			Context: pulumi.String("../"), // Adjust the context according to your project structure

			ExtraOptions: pulumi.StringArray{
				// This option is needed for devices running on ARM architecture, such as Apple M1/M2/MX CPUs
				pulumi.String("--platform=linux/amd64"),
			},
		},
		ImageName: pulumi.String(dockerImageWithPath),
		Registry: &docker.ImageRegistryArgs{
			Server:   pulumi.String(dockerGCPServer),
			Username: pulumi.String("_json_key"),     // Special username for GCP
			Password: pulumi.String(string(jsonKey)), // Provide the contents of the key file
		},
	}, pulumi.DependsOn(dependingSources))
	if err != nil {
		return nil, err
	}

	return image, nil
}

func deployContainerToCloudRun(ctx *pulumi.Context, enabledServices *EnabledServices, dockerImage *docker.Image) error {

	if enabledServices == nil || enabledServices.CloudRunService == nil {
		return errors.New("enabledServices cannot be nil")
	}

	if dockerImage == nil {
		return errors.New("dockerImage cannot be nil")
	}

	dependingSources := []pulumi.Resource{
		enabledServices.CloudRunService,
		dockerImage,
	}

	appService, err := cloudrun.NewService(ctx, cloudRunServiceName, &cloudrun.ServiceArgs{
		Location: pulumi.String(cloudRunLocation), // Choose the appropriate region for your service
		Template: &cloudrun.ServiceTemplateArgs{
			Spec: &cloudrun.ServiceTemplateSpecArgs{
				Containers: cloudrun.ServiceTemplateSpecContainerArray{
					&cloudrun.ServiceTemplateSpecContainerArgs{
						Image: dockerImage.ImageName,
						Resources: &cloudrun.ServiceTemplateSpecContainerResourcesArgs{
							Limits: pulumi.StringMap{
								"memory": pulumi.String("256Mi"), // Adjust the memory limit as needed
							},
						},
					},
				},
			},
		},
		Traffics: cloudrun.ServiceTrafficArray{
			&cloudrun.ServiceTrafficArgs{
				Percent:        pulumi.Int(100),
				LatestRevision: pulumi.Bool(true),
			},
		},
	}, pulumi.DependsOn(dependingSources))

	if err != nil {
		return err
	}

	_, iamErr := cloudrun.NewIamMember(ctx, "invoker", &cloudrun.IamMemberArgs{
		Service:  appService.Name,
		Location: appService.Location,
		Role:     pulumi.String("roles/run.invoker"),
		Member:   pulumi.String("allUsers"),
	})

	if iamErr != nil {
		return iamErr
	}

	ctx.Export("containerUrl", appService.Statuses.Index(pulumi.Int(0)).Url().ToOutput(ctx.Context()))
	return nil
} Update the in your Dockerfile:
There's a , and in which you need to export your environment variable to ENV known issue here HOME /root # Set the ENV HOME before your ENTRYPOINT.
ENV HOME=/root

# This is specific to your project. 
ENTRYPOINT ["/whatever-is-your-entrypoint"] Create a .env file in the pulumi directory: Set the * to the one you saved on full path 11) GOOGLE_CREDENTIALS_FILE_PATH="/Users/myusername/keys/gcp/pulumi-service-account-key-file.json" Run pulumi up You should be up and running! Extras The go.mod module social-log-go

go 1.21

toolchain go1.22.0

require (
	github.com/pulumi/pulumi-gcp/sdk/v7 v7.11.2
	github.com/pulumi/pulumi/sdk/v3 v3.108.1
)

require (
	dario.cat/mergo v1.0.0 // indirect
	github.com/Masterminds/semver v1.5.0 // indirect
	github.com/Microsoft/go-winio v0.6.1 // indirect
	github.com/ProtonMail/go-crypto v0.0.0-20230828082145-3c4c8a2d2371 // indirect
	github.com/aead/chacha20 v0.0.0-20180709150244-8b13a72661da // indirect
	github.com/agext/levenshtein v1.2.3 // indirect
	github.com/apparentlymart/go-textseg/v13 v13.0.0 // indirect
	github.com/atotto/clipboard v0.1.4 // indirect
	github.com/aymanbagabas/go-osc52/v2 v2.0.1 // indirect
	github.com/blang/semver v3.5.1+incompatible // indirect
	github.com/charmbracelet/bubbles v0.16.1 // indirect
	github.com/charmbracelet/bubbletea v0.24.2 // indirect
	github.com/charmbracelet/lipgloss v0.7.1 // indirect
	github.com/cheggaaa/pb v1.0.29 // indirect
	github.com/cloudflare/circl v1.3.7 // indirect
	github.com/containerd/console v1.0.4-0.20230313162750-1ae8d489ac81 // indirect
	github.com/cyphar/filepath-securejoin v0.2.4 // indirect
	github.com/djherbis/times v1.5.0 // indirect
	github.com/emirpasic/gods v1.18.1 // indirect
	github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 // indirect
	github.com/go-git/go-billy/v5 v5.5.0 // indirect
	github.com/go-git/go-git/v5 v5.11.0 // indirect
	github.com/gogo/protobuf v1.3.2 // indirect
	github.com/golang/glog v1.1.0 // indirect
	github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
	github.com/golang/protobuf v1.5.3 // indirect
	github.com/google/uuid v1.3.0 // indirect
	github.com/grpc-ecosystem/grpc-opentracing v0.0.0-20180507213350-8e809c8a8645 // indirect
	github.com/hashicorp/errwrap v1.1.0 // indirect
	github.com/hashicorp/go-multierror v1.1.1 // indirect
	github.com/hashicorp/hcl/v2 v2.17.0 // indirect
	github.com/inconshreveable/mousetrap v1.1.0 // indirect
	github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99 // indirect
	github.com/joho/godotenv v1.5.1 // indirect
	github.com/kevinburke/ssh_config v1.2.0 // indirect
	github.com/lucasb-eyer/go-colorful v1.2.0 // indirect
	github.com/mattn/go-isatty v0.0.19 // indirect
	github.com/mattn/go-localereader v0.0.1 // indirect
	github.com/mattn/go-runewidth v0.0.15 // indirect
	github.com/mitchellh/go-ps v1.0.0 // indirect
	github.com/mitchellh/go-wordwrap v1.0.1 // indirect
	github.com/muesli/ansi v0.0.0-20230316100256-276c6243b2f6 // indirect
	github.com/muesli/cancelreader v0.2.2 // indirect
	github.com/muesli/reflow v0.3.0 // indirect
	github.com/muesli/termenv v0.15.2 // indirect
	github.com/opentracing/basictracer-go v1.1.0 // indirect
	github.com/opentracing/opentracing-go v1.2.0 // indirect
	github.com/pgavlin/fx v0.1.6 // indirect
	github.com/pjbgf/sha1cd v0.3.0 // indirect
	github.com/pkg/errors v0.9.1 // indirect
	github.com/pkg/term v1.1.0 // indirect
	github.com/pulumi/appdash v0.0.0-20231130102222-75f619a67231 // indirect
	github.com/pulumi/esc v0.6.2 // indirect
	github.com/pulumi/pulumi-docker/sdk/v3 v3.6.1 // indirect
	github.com/rivo/uniseg v0.4.4 // indirect
	github.com/rogpeppe/go-internal v1.11.0 // indirect
	github.com/sabhiram/go-gitignore v0.0.0-20210923224102-525f6e181f06 // indirect
	github.com/santhosh-tekuri/jsonschema/v5 v5.0.0 // indirect
	github.com/sergi/go-diff v1.3.1 // indirect
	github.com/skeema/knownhosts v1.2.1 // indirect
	github.com/spf13/cobra v1.7.0 // indirect
	github.com/spf13/pflag v1.0.5 // indirect
	github.com/texttheater/golang-levenshtein v1.0.1 // indirect
	github.com/tweekmonster/luser v0.0.0-20161003172636-3fa38070dbd7 // indirect
	github.com/uber/jaeger-client-go v2.30.0+incompatible // indirect
	github.com/uber/jaeger-lib v2.4.1+incompatible // indirect
	github.com/xanzy/ssh-agent v0.3.3 // indirect
	github.com/zclconf/go-cty v1.13.2 // indirect
	go.uber.org/atomic v1.9.0 // indirect
	golang.org/x/crypto v0.17.0 // indirect
	golang.org/x/exp v0.0.0-20231110203233-9a3e6036ecaa // indirect
	golang.org/x/mod v0.14.0 // indirect
	golang.org/x/net v0.19.0 // indirect
	golang.org/x/sync v0.5.0 // indirect
	golang.org/x/sys v0.15.0 // indirect
	golang.org/x/term v0.15.0 // indirect
	golang.org/x/text v0.14.0 // indirect
	golang.org/x/tools v0.15.0 // indirect
	google.golang.org/genproto/googleapis/rpc v0.0.0-20230706204954-ccb25ca9f130 // indirect
	google.golang.org/grpc v1.57.1 // indirect
	google.golang.org/protobuf v1.31.0 // indirect
	gopkg.in/warnings.v0 v0.1.2 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
	lukechampine.com/frand v1.4.2 // indirect
) If you include this Run , and this will fetch all the packages for you go.mod go tidy Footnotes I fought against permissions for 5 days. The predefined GCP role brought in the additional permissions needed. 1* serviceAccountAdmin

Automate and Deploy a Docker Container to Google Cloud Run from Scratch Using Pulumi and Go

You Probably Aren’t as Advanced in Automation as You Think

In this piece, we are going to explore the most effective methods and procedures for you to follow to craft your medical application from the ground up without risks, so that you save time and cash on wasted retries and project restarts. So let us buckle up for this time and go further into this complex but at the same time highly intriguing subject. You Want to Build a Healthcare Application? Start here You Want to Build a Healthcare Application? Start here The main thought behind this section of our guide is to show not only what the right approach is to the whole process of mobile app development for healthcare but also common mistakes and misplays. This way of developing something was, is and will be the most productive one, since seeing the blunders of others and avoiding them makes everything optimized. Step 1: Understand the rules before you touch a line of code Step 1: Understand the rules before you touch a line of code Before you even start considering pushing to main, you should have some sense of which legal and technical landmines you are stepping into. Regulations such as HIPAA, GDPR, HITECH and ISO 13485 are not acronyms to sprinkle throughout investor decks. HIPAA They dictate how you have to manage PHI (Protected Health Information) and institute best practices such as data minimization, logging of access and breach notification. By not doing this step, you are risking more than just downtime — you’re risking lawsuits, penalties, and more paperwork than the DMV on a Monday. Work with a compliance specialist right away. Seriously. It is less expensive than rewriting your architecture six months later. Step 2: Build around privacy by design A good healthcare app doesn’t bolt on security after the MVP — it starts with security and privacy in its bones. This means you or the app development company for healthcare you choose must build around principles like least privilege, zero trust, and data partitioning — if you need help identifying reliable partners, see the full list of vetted providers. see the full list see the full list One architecture we like is a microservice approach with a dedicated PHI service, wrapped behind its own API layer and IAM rules. It keeps sensitive data isolated and encrypted (both at rest and in transit), with limited surface area exposed to the rest of your stack. Think of it like a digital vault — even if something else gets breached, your crown jewels stay safe. We’ve also seen success implementing tokenized data layers, where PHI is replaced with non-sensitive identifiers unless absolutely needed. Bonus: it makes your dev environments safer to work in without accidentally leaking patient info. Step 3: Choose your stack like your life depends on it (Because someone’s might) There’s no “best” stack for telemedicine, but there are definitely some choices that will make your life easier. When it comes to healthcare mobile app development, we often go with React Native or Flutter for the front-end — fast iteration and solid cross-platform support. React Native React Native Flutter Flutter For the back-end, Node.js or Python (FastAPI or Django) are strong contenders, especially when paired with PostgreSQL, MongoDB or Google Cloud Healthcare API. What matters more than your language preferences, though, is how well you modularize services, enforce API contracts and monitor performance. At scale, synchronous monoliths become your worst enemy. Step 4: Handle authentication like Fort Knox Logins aren't logins for healthcare apps, so you'll most likely have to accommodate MFA, OAuth 2.0, OpenID Connect, and potentially even Smart on FHIR for EHR integration. Design your auth layer up front and think ahead for role-based access control (RBAC), or even attribute-based access control (ABAC), if you are ambitious. One trick: utilize identity providers like Auth0, Okta or Firebase Auth if you care to eliminate the hassle of dealing with tokens, their expiration, and their audit logs. Simply keep in mind that whatever you choose is HIPAA-compliant — not every cloud service is and not every has signed BAAs (Business Associate Agreements). You can't process PHI through them without one. Yes. It is that serious among the services to develop healthcare apps that you might receive. Step 5: Plan for Scale (Yes, even if you’re pre-revenue) It is so easy to short-cut at the MVP stage. Do that — but not on the pain-of-unwinding scalability choices. For instance, don't hardcode things like "we'll always just support a single region" or "users won't ever require real-time updates." Design for horizontal scalability: stateless services, shared-nothing architecture, and read replicas or sharding where appropriate. Use infrastructure-as-code tools such as Terraform or Pulumi to keep your environments reproducible. Establish CI/CD pipelines (useful tools include GitHub Actions, GitLab CI or CircleCI) that provision for auto-deploying staging and production builds with the ability to roll back. One of our previous ventures involved developing a custom healthcare app that jumped from 500 to 30,000 users per day in less than two months due to the adoption of a feature by a large insurer. Since we had properly provisioned our load balancing and data queues, we managed to survive. Barely. But survived nonetheless. Step 6: Monitor Everything (Or regret everything) This kind of application without monitoring is like a surgeon operating blindfolded. You can work with a healthcare mobile app development company, with the organization offering these services for web platforms or even if it is your own creation, but always keep in mind logs, traces, metrics and alerts, especially when things break in the middle of the night. We use Prometheus + Grafana, Datadog or New Relic for observability. Add Sentry or Rollbar for error tracking in your front-end. And yes, log redaction matters. If PHI ends up in your logs, you’re in violation, period. Use tools that let you scrub, obfuscate or exclude sensitive info automatically. Step 7: Build trust through UX and accessibility Security and scalability are table stakes — but if your UX feels like it was designed by a sadist, users will bail. Especially in healthcare, where your end customers might be elderly, disabled or just stressed out. Follow WCAG accessibility standards during the healthcare app development, make error messages human-friendly and test your flows for cognitive overload. Make it easy for those who need to get support and verify their data. Add friction where necessary (e.g., confirmations on data-sharing) but avoid being a UX traffic cop. Remember: trust is not built in one onboarding screen — it's built through every button that does what it says it will do. Don’t Go It Alone: Why Your Dev Partner is Key to the App’s Success That is to say that even if you are developing an impressive idea, the organization you go with can turn you into a hero or pull you down to an endless loop of fixes and bugs. Here, where compliance and trust are the watchwords, who you choose to partner with becomes paramount instead of an elective prerequisite. The right team does much more than write applications; the right team is also willing to challenge the courses of compliance requirements, uptime expectations and patient safety concerns. They'll challenge you to think boldly about the tough questions up front, regarding PHI handling, audit trials, disaster recovery and challenge you to think outside the box beyond just "getting something launched." This is how a vendor is different from a healthcare development partner. A good example of encapsulation is around-the-clock communication, warning risks ahead of time and adjusting shifting needs (if rules shift) at a snappy pace. Medical care is dynamic, and developing mobile applications in this area requires a lot of brains along with flexibility. And then there are the integration capabilities, whether it is some fairly dated nation's health systems or some high-end wearable technology, your partner should have the ease of making this seem effortless. How to Choose a Healthcare App Development Company (Without Regrets) As mentioned earlier, the selection of the right vendor is not something that can be done over coffee and a gut feeling. It is more of a selection of the co-pilots for a mission to Mars because once there is a flight, you are stuck with them until the end. This partner should possess technical prowess and practical know-how in regard to healthcare. Otherwise, you will find yourself with a duct tape fix by 2 a.m. First of all, assess their compliance literacy. First of all, assess their compliance literacy. The proficient team will not merely throw names like HIPAA or GDPR, but will elaborate on key management: how the audit trails are performed, how user consent is obtained and how retention policies are applied across the relevant jurisdictions. These people must be gutsy enough to describe how they isolate Protected Health Information (PHI) in development, staging and production environments. If they answer "We use AWS" to every question about how they run HIPAA compliance, then it might be time for you to smile politely and back away. After that, talk about their technical foundation. After that, talk about their technical foundation. Good healthcare applications are not stitched together with hope and prayer. Instead, they are built upon tested and tried principles such as secure authentication (OAuth 2.0, OpenID Connect), multi-tiered API security, end-to-end encryption and RBAC models resistant to privilege escalation. For data privacy scenarios, you should look for healthcare app development companies that perform automated unit testing. Static security and dynamic security testing tools (SAST/DAST) should be used. Secure DevOps pipelines need to be in place where every single pull request is scanned for vulnerabilities before reaching the main branch. As for the third point, consider industry expertise. As for the third point, consider industry expertise. Creating a health app is significantly different from building a food delivery one and sticking a doc icon on it. The developers must have an actual understanding of the real-world problems that include interoperability of patient data, appointment scheduling quirks and integrations. Even more to the point, if they have experience involving a medical advisor on a project or working within hospital IT ecosystems because they will definitely know that real healthcare UX design does not merely involve making dashboards look clean. Assess how they communicate and are transparent. Assess how they communicate and are transparent. Are they ready to bring your patterns of security tradeoffs early into the conversation? Will they give honest estimates or do they tend more toward "smile-and-nod" consulting? Medical software creation is like marathons that are unpredictable: you need a team that is honest while the project struggles and one that can proactively call things to your attention, not one that is only concerned once the patient (your app) flatlines. In sum, the right custom-developed healthcare app partner does more than just "build features"; it thinks two steps down the road to protect users, maintain trust and keep you in compliance when regulators come knocking on the door. Wrapping Up: Custom Healthcare App Development Done Right Building a secure healthcare application that is scalable for the next few decades is not a weekend project to be thrown together with some open-source libraries and some wishful thinking. It is more of an engineering challenge with high stakes where every design choice, every line of code, and every test shortcut taken or not taken could have tangible consequence like HIPAA lawsuits, loss of patient trust, or complete failure of the product. The single most important thing to learn about collaborating with telemedicine startups, even the founders who wish to uberize telemedicine, is that scalability and security have to be inherent to the software from the very beginning or else these are just secondary buzzwords. Everything, including the pace, growth of users, and even that of investors' confidence, will cascade like a domino effect should privacy architectures, intelligent data, a solid infrastructure plan, and compliance be well-considered from the very first sprint. Half the battle is to have the right development firm in hand. A seasoned crew that has navigated the minefield of regulators before (and survived to report on their experience) can identify hazards you wouldn't dream of in your wildest fantasies. With a straightforward strategy and knowledge of everything that goes on, achievement is like medication prescribed to you by a doctor – you can't escape it!

How to Build a Scalable, Secure Healthcare App (Without Going Crazy)

“Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”n”in “Qəbələ”nin “Qəbələ”nin “Qəbələ”nin “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”in “Qəbələ”n”in “Qəbələ”n”in “Qəbələ”in

Πώς να δημιουργήσετε μια ασφαλή εφαρμογή υγειονομικής περίθαλψης (χωρίς να τρελαθείτε)

Cómo construir una aplicación de atención médica escalable y segura (sin enloquecer)

Miten rakentaa skaalautuva, turvallinen terveydenhuollon sovellus (ilman hulluja)

Kako izgraditi skalabilnu, sigurnu zdravstvenu aplikaciju (bez ludila)

Hogyan építsünk skálázható, biztonságos egészségügyi alkalmazást (ha nem őrült)

Cara Membangun Aplikasi Perawatan Kesehatan yang Meningkatkan, Aman (tanpa Gila)

スケーラブルで安全な医療アプリケーションを構築する方法(狂うことなく)

Тақырып: «Менің ата-анам, менің ата-анам, менің ата-анам, менің ата-анам» деді.

Хэрхэн Scalable, аюулгүй эрүүл мэндийн апп үүсгэх вэ (Хэзээгүй бол)

Cum să construiți o aplicație scalabilă, sigură de asistență medicală (fără a fi nebună)

ایک وسیع پیمانے پر، محفوظ صحت کے ایپ کو کیسے بنائیں (جنگ کے بغیر)

In the early days of IT, we manually configured servers–each one a precious snowflake, lovingly maintained and documented. But the size of the infrastructure grew, and this approach couldn't scale. Chef and Puppet popularized the idea of Infrastructure-as-Code: engineers would define the state of the machine(s) in text files, stored in Git–hence the name. A global node would read these files to create a registry. Then, a local agent on each machine would check the desired state at regular intervals and reconcile the current state with the registry. The first generation of Infrastructure-as-Code managed the state of existing machines but assumed the machine was already there. The migration to the Cloud created another issue: how do you create the machine in the first place? Another IaC tool appeared in the form of Hashicorp's Terraform. Terraform came with its own fully descriptive language, aptly named the Terraform language. Terraform However, it doesn't offer a central registry, and you need to run a command to reconcile the desired state with the current state. Terraform was a huge success. When Hashicorp moved away from a pure open-source license, the community forked it and christened it OpenTofu. Furthermore, IBM recently acquired Hashicorp. Terraform isn't without issue, though. Some feel that the descriptive configuration language is limiting. Pulumi offers to describe the infrastructure in a couple of existing programming languages, e.g., Python, JavaScript, and Kotlin. Instead of repeating ten configuration lines with only a single parameter changed, you can write functions and loops. Pulumi e.g. Another issue was the lack of a central registry and automated drift correction. In the current technological landscape, which tool offers such features? Kubernetes! It makes a lot of sense to use Kubernetes to address Terraform's limits; that's the approach of Crossplane by Upbound. Crossplane I'm working on Kubernetes these days. Recently, I wrote a series on how one could design a full-fledged testing pipeline targeting Google Kubernetes Engine. The second part mentions creating a Google Kubernetes Engine instance in the context of a GitHub workflow. In this post, I want to assess Crossplane by creating such an instance. a series It seems weird that to create a new Kubernetes cluster, one needs a Kubernetes cluster. I admit my use case is a bit weird, but I think that if I can achieve this edge case, I can achieve more nominal ones. Crossplane 101 Crossplane is like an engine, using a Kubernetes registry and reconciling behavior to manage resources. Resources include virtually anything: cloud resources, GitHub projects, and organizations, Terraform (!), or software stacks, such as Kafka and Keycloak, etc. By default, it doesn't know about these resources, but you can extend its capabilities via packages. Packages are of two kinds: packages Configuration packages: A configuration package defines a higher-level abstraction over Kubernetes objects. You may have noticed that deploying an application in Kubernetes follows the same pattern: define a Deployment (or any other relevant object) and a Service. In most cases, you'd rather offer a single Application abstraction to developers. Crossplane allows you to compose objects to create abstractions and deliver them in configuration packages. Configuration packages: A configuration package defines a higher-level abstraction over Kubernetes objects. You may have noticed that deploying an application in Kubernetes follows the same pattern: define a Deployment (or any other relevant object) and a Service. In most cases, you'd rather offer a single Application abstraction to developers. Crossplane allows you to compose objects to create abstractions and deliver them in configuration packages. Configuration Deployment Service Application Providers: a provider integrates with a third-party system, whether a cloud provider or any other system. For example, Crossplane offers a Google Cloud Platform provider. Crossplane offers three provider categories:


Official, developed, and supported by Upbound


Partner, developed by a third-party


Community, developed by the community in general


Upbound offers providers for the main hyperscalers, while the community has created a couple for smaller ones, e.g., Scaleway or OVH. Providers: a provider integrates with a third-party system, whether a cloud provider or any other system. For example, Crossplane offers a Google Cloud Platform provider. Crossplane offers three provider categories:


Official, developed, and supported by Upbound


Partner, developed by a third-party


Community, developed by the community in general


Upbound offers providers for the main hyperscalers, while the community has created a couple for smaller ones, e.g., Scaleway or OVH. Providers: a provider integrates with a third-party system, whether a cloud provider or any other system. For example, Crossplane offers a Google Cloud Platform provider. Crossplane offers three provider categories: Providers Official, developed, and supported by Upbound


Partner, developed by a third-party


Community, developed by the community in general Official, developed, and supported by Upbound Official, developed, and supported by Upbound Partner, developed by a third-party Partner, developed by a third-party Community, developed by the community in general Community, developed by the community in general Upbound offers providers for the main hyperscalers, while the community has created a couple for smaller ones, e.g., Scaleway or OVH. e.g. First Steps With Crossplane The first step is to install Crossplane itself. I use a simple Helm Chart with the default configuration. I'm following the advice to install it in its dedicated namespace, crossplane-system. crossplane-system helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane --create-namespace --namespace crossplane-system crossplane-stable/crossplane helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane --create-namespace --namespace crossplane-system crossplane-stable/crossplane You should see two pods running in the crossplane-system namespace: crossplane-system NAME                                       READY   STATUS    RESTARTS     AGE
crossplane-6f88554645-b2xng                1/1     Running   1 (1h ago)   1h
crossplane-rbac-manager-75bc66d6b7-8p2fh   1/1     Running   1 (1h ago)   1h NAME                                       READY   STATUS    RESTARTS     AGE
crossplane-6f88554645-b2xng                1/1     Running   1 (1h ago)   1h
crossplane-rbac-manager-75bc66d6b7-8p2fh   1/1     Running   1 (1h ago)   1h We are now ready to start the real work. We target Google Cloud Platform, hence, we need to install the GCP provider. The marketplace offers many available providers. The first challenge is to locate the one that contains the abstraction we want to create. Since we want to create a Cluster, we need the provider-gcp-container. available providers Cluster provider-gcp-container Cluster is the Schema for the Clusters API. Creates a Google Kubernetes Engine (GKE) cluster.
-- Cluster managed resource Cluster is the Schema for the Clusters API. Creates a Google Kubernetes Engine (GKE) cluster. -- Cluster managed resource Cluster managed resource We create a Provider object that points to the provider package: Provider apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp                                             #1
spec:
  package: xpkg.upbound.io/upbound/provider-gcp-container:v1     #2 apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp                                             #1
spec:
  package: xpkg.upbound.io/upbound/provider-gcp-container:v1     #2 Providers are cluster-wide.
Upbound requires a paid subscription for specific versions. Because I don't have one, I can only use a major version, with all the stability issues that come with it. Providers are cluster-wide. Upbound requires a paid subscription for specific versions. Because I don't have one, I can only use a major version, with all the stability issues that come with it. We can list the installed providers: kubectl get providers kubectl get providers The result should look like the following: NAME                          INSTALLED   HEALTHY   PACKAGE                                               AGE
provider-gcp                  True        True      xpkg.upbound.io/upbound/provider-gcp-container:v1     28m
upbound-provider-family-gcp   True        True      xpkg.upbound.io/upbound/provider-family-gcp:v1.12.1   28m NAME                          INSTALLED   HEALTHY   PACKAGE                                               AGE
provider-gcp                  True        True      xpkg.upbound.io/upbound/provider-gcp-container:v1     28m
upbound-provider-family-gcp   True        True      xpkg.upbound.io/upbound/provider-family-gcp:v1.12.1   28m At this stage, we can manage GKE instances with Crossplane. Google offers several ways to authenticate. Here, I'll use the straightforward JSON credentials associated with a Service Account. Get the JSON from the Google Cloud console, then import it as a secret in Kubernetes: kubectl create secret generic gcp-creds -n crossplane-system --from-file=creds=./gcp-credentials.json kubectl create secret generic gcp-creds -n crossplane-system --from-file=creds=./gcp-credentials.json In the Crossplane model, a Provider object is generic and relevant to a single provider. On the other hand, a ProviderConfig is relevant to a project, including its credentials. Provider ProviderConfig apiVersion: gcp.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: gcp-provider
spec:
  projectID: xplane-demo                                         #1
  credentials:
    source: Secret
    secretRef:                                                   #2
      namespace: crossplane-system
      name: gcp-creds
      key: credentials.json apiVersion: gcp.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: gcp-provider
spec:
  projectID: xplane-demo                                         #1
  credentials:
    source: Secret
    secretRef:                                                   #2
      namespace: crossplane-system
      name: gcp-creds
      key: credentials.json The project ID we want to manage the resources of.
Reference to the previously created secret containing the required credentials. The project ID we want to manage the resources of. Reference to the previously created secret containing the required credentials. The last step consists of creating the cluster. I tried to set the same configuration as in the command line of the original post, but I must admit I couldn't map every single option. apiVersion: container.gcp.upbound.io/v1beta1
kind: Cluster
metadata:
  name: minimal-cluster
spec:
  forProvider:
    initialNodeCount: 1                                          #1
    location: europe-west9                                       #1
    nodeLocations: [ "europe-west9-a" ]                          #1
    network: projects/xplane-demo/global/networks/default        #1
    subnetwork: projects/xplane-demo/regions/europe-west9/subnetworks/default #1
    ipAllocationPolicy:
      - clusterIpv4CidrBlock: "/17"                              #1
    resourceLabels:
      provisioner: crossplane                                    #2
  providerConfigRef:
    name: gcp-provider                                           #3
  writeConnectionSecretToRef:                                    #4
    namespace: default
    name: kubeconfig apiVersion: container.gcp.upbound.io/v1beta1
kind: Cluster
metadata:
  name: minimal-cluster
spec:
  forProvider:
    initialNodeCount: 1                                          #1
    location: europe-west9                                       #1
    nodeLocations: [ "europe-west9-a" ]                          #1
    network: projects/xplane-demo/global/networks/default        #1
    subnetwork: projects/xplane-demo/regions/europe-west9/subnetworks/default #1
    ipAllocationPolicy:
      - clusterIpv4CidrBlock: "/17"                              #1
    resourceLabels:
      provisioner: crossplane                                    #2
  providerConfigRef:
    name: gcp-provider                                           #3
  writeConnectionSecretToRef:                                    #4
    namespace: default
    name: kubeconfig Same parameters as in the command line
Set labels to document who the resource manager is. Depending on your context, you can add more, e.g., environment
Name of the ProviderConfig we created above
Writes the kubeconfig to connect to the created GKE Same parameters as in the command line Set labels to document who the resource manager is. Depending on your context, you can add more, e.g., environment e.g. environment Name of the ProviderConfig we created above ProviderConfig Writes the kubeconfig to connect to the created GKE kubeconfig You can follow the creation of the GKE cluster both on the Google Cloud console and via kubectl. kubectl kubectl get cluster kubectl get cluster We can see here that the cluster is not ready yet: NAME              SYNCED   READY   EXTERNAL-NAME     AGE
minimal-cluster   True     False   minimal-cluster   2m46s NAME              SYNCED   READY   EXTERNAL-NAME     AGE
minimal-cluster   True     False   minimal-cluster   2m46s We can use the kubeconfig Secret that Crossplane created along with the Cluster to connect to the latter. First, let's dump the Secret value to a file: kubeconfig Secret Cluster Secret kubectl get secret kubeconfig -o jsonpath="{.data.kubeconfig}" | base64 --decode > kube.config kubectl get secret kubeconfig -o jsonpath="{.data.kubeconfig}" | base64 --decode > kube.config At this point, we can use it to send requests to the newly-created Cluster: Cluster kubectl --kubeconfig ./kube.config get pods kubectl --kubeconfig ./kube.config get pods To delete the GKE instance, it's enough to delete the local Cluster. Kubernetes and Crossplane will take care of sending the DELETE request to Google Cloud. Cluster DELETE kubectl delete cluster.container.gcp.upbound.io minimal-cluster kubectl delete cluster.container.gcp.upbound.io minimal-cluster The command is synchronous: you won't get the prompt back until the GKE instance is removed. In this post, I used Crossplane to create a simple GKE cluster. Using Kubernetes for the registry and the reconciling behavior is ingenious. Of course, Crossplane is as good as the number of integrations it offers. At the moment, it can already manage all major hyperscalers, plus a couple of smaller ones. To go further: To go further: Crossplane
Crossplane documentation
GCP Quickstart
Crossplane provider-family-gcp Crossplane Crossplane Crossplane documentation Crossplane documentation GCP Quickstart GCP Quickstart Crossplane provider-family-gcp Crossplane provider-family-gcp Originally published at A Java Geek on May 4th, 2025 Originally published at A Java Geek on May 4th, 2025 A Java Geek

My First Steps With Crossplane: Crossplane 101

Startups of The Year has returned for 2024, and we’re happy to say that this was our biggest and best year yet. 150,000+ startups across the globe were nominated, over 4M+ votes were cast, and 2.9k cities were represented. 150,000+ startups One of the most exciting startup scenes to watch was the Emerging Tech industry! Emerging Tech If you’re wondering what Emerging Tech is, it’s new and cutting-edge tech that has the potential to change all of our lives. But this tech doesn’t just grow on trees; trailblazers and innovators have to push boundaries to make them come true. That’s why we’re happy to showcase and put a spotlight on all of these amazing Emerging Tech startups. Emerging Tech 🏆 Key Stats Let’s start out with some general stats for all of you technical folks. Total Startups Participated: 14,248
Sub Industries Represented: 10
Total Votes Gathered: 48,800
Winning Startups: 10 Total Startups Participated: 14,248 Total Startups Participated: Sub Industries Represented: 10 Sub Industries Represented: Total Votes Gathered: 48,800 Total Votes Gathered: Winning Startups: 10 Winning Startups: To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner.


You may also check out the full list of nominated startups in the Emerging Tech Industry HERE.



Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner.


You may also check out the full list of nominated startups in the Emerging Tech Industry HERE. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner. startups.hackernoon.com You may also check out the full list of nominated startups in the Emerging Tech Industry HERE. You may also check out the full list of nominated startups in the Emerging Tech Industry HERE. HERE. HERE Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. Startups of The Year Winner Announcement Series Now, drum roll please, here are all the 2024 Startups of The Year winners for Emerging Tech! drum roll please Emerging Tech Space Technology (26.2k total votes, 566 startups) Space Technology Winner: Spacecoin Winner: Spacecoin Spacecoin Pan Galactic Developments Ltd
Space Copy Pan Galactic Developments Ltd Pan Galactic Developments Ltd Space Copy Space Copy Honorable mentions: Honorable mentions: Portal Space Systems
Advanced Rocket Technologies
Monarc Holdings
Resolute Lab India
Element Robotics
Mor Mitti
Net Zero Company Portal Space Systems Portal Space Systems Advanced Rocket Technologies Advanced Rocket Technologies Monarc Holdings Monarc Holdings Resolute Lab India Resolute Lab India Element Robotics Element Robotics Mor Mitti Mor Mitti Net Zero Company Net Zero Company Climatetech (5.7k total votes, 3.5k startups) Climatetech Winner: Cropler Winner: Cropler Cropler Nat5
Violet Nat5 Nat5 Violet Violet Honorable mentions: Honorable mentions: 7Analytics
Swarm
scoutlabs
Treeback
Dracoss
Watergenics
SunRuf - Switch To Solar 7Analytics 7Analytics Swarm Swarm scoutlabs scoutlabs Treeback Treeback Dracoss Dracoss Watergenics Watergenics SunRuf - Switch To Solar SunRuf - Switch To Solar Biotechnology (3.6k total votes, 2.1k startups) Biotechnology Winner: Vitality Robotics Winner: Vitality Robotics Lite-1
GOTECH Antimicrobial Lite-1 Lite-1 GOTECH Antimicrobial GOTECH Antimicrobial Honorable mentions: Honorable mentions: Sorintellis
Unibaio
Jungopharm
Tintte
GUTolution
MariHealth Solutions
EcoScience Lab Sorintellis Sorintellis Unibaio Unibaio Jungopharm Jungopharm Tintte Tintte GUTolution GUTolution MariHealth Solutions MariHealth Solutions EcoScience Lab EcoScience Lab Quantum Computing (3.4k total votes, 46 startups) Quantum Computing Winner: SharePass Winner: SharePass SharePass Exohood Labs Limited
Quantum Commodity Intelligence Exohood Labs Limited Exohood Labs Limited Quantum Commodity Intelligence Quantum Commodity Intelligence Honorable mentions: Honorable mentions: QuantumX
Q-Block Computing Inc.
QDNL Participations
Aegiq
Trailyn VC
EdenBase
SEAQuantum.ai QuantumX QuantumX Q-Block Computing Inc. Q-Block Computing Inc. QDNL Participations QDNL Participations Aegiq Aegiq Trailyn VC Trailyn VC EdenBase EdenBase SEAQuantum.ai SEAQuantum.ai Energy Solutions (2.9k total votes, 4.2k startups) Energy Solutions Winner: Dunia Winner: Dunia Dunia Swarm
Opla Energy Swarm Swarm Opla Energy Opla Energy Honorable mentions: Honorable mentions: RenTech Global Solutions
SODER SN
Rensair
Matteco
Insen
Corbiota
RoboCare RenTech Global Solutions RenTech Global Solutions SODER SN SODER SN Rensair Rensair Matteco Matteco Insen Insen Corbiota Corbiota RoboCare RoboCare Iot (2.6k total votes, 588 startups) Iot Winner: Cropler Winner: Cropler Cropler Epowar
Swarm Epowar Epowar Swarm Swarm Honorable mentions: Honorable mentions: IPAGE #GrowSmartly
Venture Labs
Your Cue
Versori
Livibe
SkoneLabs
CHIP WEB TECHNOLOGIES INDIA IPAGE #GrowSmartly IPAGE #GrowSmartly Venture Labs Venture Labs Your Cue Your Cue Versori Versori Livibe Livibe SkoneLabs SkoneLabs CHIP WEB TECHNOLOGIES INDIA CHIP WEB TECHNOLOGIES INDIA Ar/Vr (1.6k total votes, 133 startups) Ar/Vr Winner: SimZero Winner: SimZero SimZero Creart Digital Media
INFINITY-UP Creart Digital Media Creart Digital Media INFINITY-UP INFINITY-UP Honorable mentions: Honorable mentions: Akela Hub


RSight


Exposit ARVR


AniML, Inc.


nXscale


FutureMeds


Argineering, Inc. Akela Hub Akela Hub Akela Hub RSight RSight RSight Exposit ARVR Exposit ARVR Exposit ARVR AniML, Inc. AniML, Inc. AniML, Inc. nXscale nXscale nXscale FutureMeds FutureMeds FutureMeds Argineering, Inc. Argineering, Inc. Argineering, Inc. Cloud Computing (1.4k total votes, 1.5k startups) Cloud Computing Winner: RELAYTO/ Content Experience Platform Winner: RELAYTO/ Content Experience Platform RELAYTO/ Content Experience Platform Edgee
Pulumi Edgee Edgee Pulumi Pulumi Honorable mentions: Honorable mentions: Elestio
LEGIONWEB
CHIP WEB TECHNOLOGIES INDIA
EQUALS TRUE
Aurelia Ventures
ByteCraft Studios
Frankly Solutions Elestio Elestio LEGIONWEB LEGIONWEB CHIP WEB TECHNOLOGIES INDIA CHIP WEB TECHNOLOGIES INDIA EQUALS TRUE EQUALS TRUE Aurelia Ventures Aurelia Ventures ByteCraft Studios ByteCraft Studios Frankly Solutions Frankly Solutions Renewable Energy (1.1k total votes, 1.4k startups) Renewable Energy Winner: scoutlabs Winner: scoutlabs scoutlabs Dracoss
Matteco Dracoss Dracoss Matteco Matteco Honorable mentions: Honorable mentions: Reasonance GmbH
Insen
seeng LTD
SolaTrue
R.Flo
GODI
Ontario Clean Technology Industry Association Reasonance GmbH Reasonance GmbH Insen Insen seeng LTD seeng LTD SolaTrue SolaTrue R.Flo R.Flo GODI GODI Ontario Clean Technology Industry Association Ontario Clean Technology Industry Association Nanotechnology (110 total votes, 115 startups) Nanotechnology Winner: Namalab Winner: Namalab Namalab Theranautilus
Krilltech Theranautilus Theranautilus Krilltech Krilltech Honorable mentions: Honorable mentions: MIT.nano
Naco Technologies
Midel Photonics
The Nanomed Lab
NanoSci - photocatalytic materials
OrelTech
Okeanos MIT.nano MIT.nano Naco Technologies Naco Technologies Midel Photonics Midel Photonics The Nanomed Lab The Nanomed Lab NanoSci - photocatalytic materials NanoSci - photocatalytic materials OrelTech OrelTech Okeanos Okeanos Congratulations to you all! We will contact you with details on how to claim your winnings! Congratulations to you all! We will contact you with details on how to claim your winnings! Congratulations to you all! We will contact you with details on how to claim your winnings! See the global regional announcements here.
See the global industry announcements here. See the global regional announcements here.
See the global industry announcements here. See the global regional announcements here. here See the global industry announcements here. here About HackerNoon’s Startups of The Year Startups of The Year 2024 is HackerNoon’s flagship community-driven event celebrating startups, technology, and the spirit of innovation. Currently in its third iteration, the prestigious Internet award recognizes and celebrates tech startups of all shapes and sizes. This year, over 150,000 entities across 4200+ cities, 6 continents, and 100+ industries participated in a bid to be crowned the best startup of the year! Millions of votes have been cast over the past few years, and many storieshave been written about these daring and rising startups. Startups of The Year 2024 many stories The winners will get a free interview on HackerNoon and an Evergreen Tech Company News page. free interview Evergreen Tech Company News Visit our FAQ page to learn more. FAQ Download our design assets here. here Check out the Startups of The Year Merch Shop here. here HackerNoon’s Startups of The Year is a branding opportunity unlike any other. Whether your goal is brand awareness or lead generation, HackerNoon has curated packages to solve your marketing challenges. Book a meeting with us to learn more! curated packages Book a meeting with us to learn more! Book a meeting with us to learn more! Meet our sponsors: Meet our sponsors: Wellfound: Join the #1 global, startup-focused community. At Wellfound, we're not just a job board—we're the place where top startup talent and the world's most exciting companies connect to build the future. Wellfound: Join the #1 global, startup-focused community Notion: Notion is trusted and loved by thousands of startups as their connected workspace—from building product roadmaps to tracking fundraising. Try Notion with unlimited AI, FREE for up to 6 months, to build and scale your company with one powerful tool.Get your offer now! Notion: Try Notion with unlimited AI, FREE for up to 6 months Get your offer now ! Hubspot: If you’re looking for a smart CRM platform that meets the needs of small businesses, look no further than HubSpot. Seamlessly connect your data, teams and customers in one easy-to-use scalable platform that grows with your business. Get started for free. Hubspot: Get started for free Bright Data: Startups that leverage public web data can make faster, data-driven decisions, giving them a competitive edge. With Bright Data’s scalable web data collection, businesses can grow from a small operation to an enterprise by harnessing insights at every stage. Bright Data: Bright Data’s scalable web data collection Algolia: Algolia NeuralSearch is the world's only AI end-to-end Search and Discovery Platform combining powerful keyword and natural language processing in a single API. Algolia: AI end-to-end Search and Discovery Platform

Startups of The Year 2024 Winners: Emerging Tech

Стартовете на годината 2024 Победители: Възникващи технологии

২০২৪ সালের স্টার্টআপ বিজয়ী: নতুন প্রযুক্তি

Startups des Jahres 2024 Gewinner: Emerging Tech

Startups del Año 2024 Ganadores: Tecnologías emergentes

Startups do ano 2024 Gañadores: Tecnoloxía emerxente

वर्ष 2024 के स्टार्टअप विजेता: उभरते प्रौद्योगिकी

Startups of the Year 2024 Winners: Emerging Tech(新興技術)

Startups of the Year 2024 - ახალი ტექნოლოგია

Startups на годината 2024 Победници: Emerging Tech

د 2024 کال پیل کونکي: د نوښت تکنالوژۍ

Стартупс оф тхе Године 2024 Победници: Емеринг Тецх

Переможці стартапів 2024 року: нові технології

After months of nominations, enthusiastic voting, and community buzz, the Startups of The Year 2024 results are in. With over 150,000 startups in the spotlight and 4 million+ votes cast, this year’s celebration of innovation has been our biggest yet — and the Programming category was buzzing with brilliance. Startups of The Year 2024 150,000 startups 4 million+ votes Programming As tech stacks evolve and software demands grow, startups are pushing the boundaries of what’s possible — from low-code/no-code platforms and collaborative dev tools to performance optimization, code security, and AI-assisted programming. These startups aren’t just writing code — they’re rewriting the rules of software development. So let’s dive into the top Programming startups of 2024 who are building the future, one line of code at a time. top Programming startups of 2024 🏆 Key Stats Let’s start out with some general stats for all of you technical folks. Total Startups Participated: 77,899
Sub Industries Represented: 10
Total Votes Gathered: 822,000
Winning Startups: 10 Total Startups Participated: 77,899 Total Startups Participated: Sub Industries Represented: 10 Sub Industries Represented: Total Votes Gathered: 822,000 Total Votes Gathered: Winning Startups: 10 Winning Startups: To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner.


You may also check out the full list of nominated startups in the Programming Industry HERE.



Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner.


You may also check out the full list of nominated startups in the Programming Industry HERE. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner. To explore winning top startups in other industries or cities, head over to startups.hackernoon.com and use the search bar — the name at the top of each list is the winner. startups.hackernoon.com You may also check out the full list of nominated startups in the Programming Industry HERE. You may also check out the full list of nominated startups in the Programming Industry HERE. HERE. HERE Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. Stay tuned for our Startups of The Year Winner Announcement Series, where we’ll be highlighting the top startups across various regions and industries. Startups of The Year Winner Announcement Series …and now, we present to you all the 2024 Startups of The Year winners for Programming! Programming It Services (581.3k total votes, 26.7k startups) It Services WINNER: Sprinto WINNER: Sprinto Sprinto Intellico Inc
NAYAMAX Intellico Inc Intellico Inc NAYAMAX NAYAMAX Honorable Mentions: Honorable Mentions: DataMind
NEORON
MRP Elite Pvt. Ltd.
avilo
Mecanizou
Make Time Count Today
KD Squares DataMind DataMind NEORON NEORON MRP Elite Pvt. Ltd. MRP Elite Pvt. Ltd. avilo avilo Mecanizou Mecanizou Make Time Count Today Make Time Count Today KD Squares KD Squares Saas (129k total votes, 10.2k startups) Saas WINNER: Forescribe WINNER: Forescribe Forescribe Intellico Inc
NAYAMAX Intellico Inc Intellico Inc NAYAMAX NAYAMAX Honorable Mentions: Honorable Mentions: Guhuza
Luna Launches, Inc.
Ambassador
nPloy
iKonnect
RentBamboo
Altrium Guhuza Guhuza Luna Launches, Inc. Luna Launches, Inc. Ambassador Ambassador nPloy nPloy iKonnect iKonnect RentBamboo RentBamboo Altrium Altrium Software Development (57.8k total votes, 17.4k startups) Software Development WINNER: Lightrun WINNER: Lightrun Lightrun Didit
Intellico Didit Didit Intellico Intellico Honorable Mentions: Honorable Mentions: avilo
Forescribe
Pieces for Developers
Make Time Count Today
Tee Htwin
Foxsense Innovations
Spectatr avilo avilo Forescribe Forescribe Pieces for Developers Pieces for Developers Make Time Count Today Make Time Count Today Tee Htwin Tee Htwin Foxsense Innovations Foxsense Innovations Spectatr Spectatr Web Development (36.4k total votes, 19.4k startups) Web Development WINNER: Make Time Count Today WINNER: Make Time Count Today Make Time Count Today avilo
KD Squares avilo avilo KD Squares KD Squares Honorable Mentions: Honorable Mentions: MRP Elite Pvt. Ltd.
Server1
Thynkfy
APrime Technology
Foxsense Innovations
Spectatr
AQUi9 MRP Elite Pvt. Ltd. MRP Elite Pvt. Ltd. Server1 Server1 Thynkfy Thynkfy APrime Technology APrime Technology Foxsense Innovations Foxsense Innovations Spectatr Spectatr AQUi9 AQUi9 Developer Tools (11.6k total votes, 606 startups) Developer Tools WINNER: Torram WINNER: Torram Torram Pieces for Developers
Arize Phoenix Pieces for Developers Pieces for Developers Arize Phoenix Arize Phoenix Honorable Mentions: Honorable Mentions: SiteSkite
Desution
DevStacks
AI Agents Live
AppFactor
Codigy
Tecoreng SiteSkite SiteSkite Desution Desution DevStacks DevStacks AI Agents Live AI Agents Live AppFactor AppFactor Codigy Codigy Tecoreng Tecoreng Opensource (1.5k total votes, 315 startups) Opensource WINNER: Arize Phoenix WINNER: Arize Phoenix Arize Phoenix Eltassan Electronic Hardware and Software design Company
Shree Drashti Infotech LLP Eltassan Electronic Hardware and Software design Company Eltassan Electronic Hardware and Software design Company Shree Drashti Infotech LLP Shree Drashti Infotech LLP Honorable Mentions: Honorable Mentions: Dalefon
RoomsVital
MLSAPRO
Pealock
Ateios Systems
Magna Audio
Tempt India Dalefon Dalefon RoomsVital RoomsVital MLSAPRO MLSAPRO Pealock Pealock Ateios Systems Ateios Systems Magna Audio Magna Audio Tempt India Tempt India Mobile-App-Development (1.1k total votes, 515 startups) Mobile-App-Development WINNER: Hailr WINNER: Hailr Hailr Hyperhumans
Cizonet Solutions Hyperhumans Hyperhumans Cizonet Solutions Cizonet Solutions Honorable Mentions: Honorable Mentions: SmartDust.me - Device Clouds
CityRiddler
NISIR IT SOLUTIONS
Megasight
Mobly
Leolit Games
Hedy AI SmartDust.me - Device Clouds SmartDust.me - Device Clouds CityRiddler CityRiddler NISIR IT SOLUTIONS NISIR IT SOLUTIONS Megasight Megasight Mobly Mobly Leolit Games Leolit Games Hedy AI Hedy AI Software Monetization (923 total votes, 768 startups) Software Monetization WINNER: Cosmonova Broadcast WINNER: Cosmonova Broadcast Cosmonova Broadcast Burke Cybersecurity Consulting
Tripcel Burke Cybersecurity Consulting Burke Cybersecurity Consulting Tripcel Tripcel Honorable Mentions: Honorable Mentions: Q-Block Computing Inc.
Fbrand Web Hosting
Wayru Network
GigXDigital,Inc.
KMER OUTSOURCING INC
Berty Technologies
NEOVIGIE INC Q-Block Computing Inc. Q-Block Computing Inc. Fbrand Web Hosting Fbrand Web Hosting Wayru Network Wayru Network GigXDigital,Inc. GigXDigital,Inc. KMER OUTSOURCING INC KMER OUTSOURCING INC Berty Technologies Berty Technologies NEOVIGIE INC NEOVIGIE INC Devops (509 total votes, 491 startups) Devops WINNER: Pulumi WINNER: Pulumi Pulumi Elestio
DataRock Labs Elestio Elestio DataRock Labs DataRock Labs Honorable Mentions: Honorable Mentions: Zenith HR
XFANTOME
EngFlow
Digiqt Technolabs
DuskyDots
Seoul Labs Inc.
SSK Training and Consulting Zenith HR Zenith HR XFANTOME XFANTOME EngFlow EngFlow Digiqt Technolabs Digiqt Technolabs DuskyDots DuskyDots Seoul Labs Inc. Seoul Labs Inc. SSK Training and Consulting SSK Training and Consulting Operating System (457 total votes, 204 startups) Operating System WINNER: Lumafield WINNER: Lumafield Lumafield Riemann Computing
GEMESYS Riemann Computing Riemann Computing GEMESYS GEMESYS Honorable Mentions: Honorable Mentions: 273 Ventures
Nanta Technology
Le tailleur app
Destiny Robotics
SQK INC
ToSwim
QUDORA Technologies 273 Ventures 273 Ventures Nanta Technology Nanta Technology Le tailleur app Le tailleur app Destiny Robotics Destiny Robotics SQK INC SQK INC ToSwim ToSwim QUDORA Technologies QUDORA Technologies Congratulations to you all! We will contact you with details on how to claim your winnings! Congratulations to you all! We will contact you with details on how to claim your winnings! Congratulations to you all! We will contact you with details on how to claim your winnings! See the global regional announcements here.
See the global industry announcements here. See the global regional announcements here.
See the global industry announcements here. See the global regional announcements here. here See the global industry announcements here. here About HackerNoon’s Startups of The Year Startups of The Year 2024 is HackerNoon’s flagship community-driven event celebrating startups, technology, and the spirit of innovation. Currently in its third iteration, the prestigious Internet award recognizes and celebrates tech startups of all shapes and sizes. This year, over 150,000 entities across 4200+ cities, 6 continents, and 100+ industries participated in a bid to be crowned the best startup of the year! Millions of votes have been cast over the past few years, and many storieshave been written about these daring and rising startups. Startups of The Year 2024 many stories The winners will get a free interview on HackerNoon and an Evergreen Tech Company News page. free interview Evergreen Tech Company News Visit our FAQ page to learn more. FAQ Download our design assets here. here Check out the Startups of The Year Merch Shop here. here HackerNoon’s Startups of The Year is a branding opportunity unlike any other. Whether your goal is brand awareness or lead generation, HackerNoon has curated packages to solve your marketing challenges. Book a meeting with us to learn more! curated packages Book a meeting with us to learn more! Book a meeting with us to learn more! Meet our sponsors: Meet our sponsors: Wellfound: Join the #1 global, startup-focused community. At Wellfound, we're not just a job board—we're the place where top startup talent and the world's most exciting companies connect to build the future. Wellfound: Join the #1 global, startup-focused community Notion: Notion is trusted and loved by thousands of startups as their connected workspace—from building product roadmaps to tracking fundraising. Try Notion with unlimited AI, FREE for up to 6 months, to build and scale your company with one powerful tool.Get your offer now! Notion: Try Notion with unlimited AI, FREE for up to 6 months Get your offer now ! Hubspot: If you’re looking for a smart CRM platform that meets the needs of small businesses, look no further than HubSpot. Seamlessly connect your data, teams and customers in one easy-to-use scalable platform that grows with your business. Get started for free. Hubspot: Get started for free Bright Data: Startups that leverage public web data can make faster, data-driven decisions, giving them a competitive edge. With Bright Data’s scalable web data collection, businesses can grow from a small operation to an enterprise by harnessing insights at every stage. Bright Data: Bright Data’s scalable web data collection Algolia: Algolia NeuralSearch is the world's only AI end-to-end Search and Discovery Platform combining powerful keyword and natural language processing in a single API. Algolia: AI end-to-end Search and Discovery Platform

Startups of The Year 2024 Winners: Programming

Innovation Has No Boundaries — Meet the Champion Industries of Startups of The Year 2024

الابتكار لا تحتوي على الحدود - تعاقدت مع الصناعات الفاخرة للشركات الناشئة في عام 2024

Інновацыі не маюць межаў — знаёмства з чэмпіёнамі прамысловасці стартапаў 2024 года

Η καινοτομία δεν έχει σύνορα – Γνωρίστε τις πρωτοπόρες βιομηχανίες των νεοσύστατων επιχειρήσεων του 2024

La innovación no tiene fronteras - Conoce las industrias campeonas de las startups del año 2024

नवाचार कोई सीमा नहीं है - वर्ष 2024 के स्टार्टअप चैंपियन उद्योगों से मिलें

イノベーションには国境がない―2024年のスタートアップのチャンピオン産業に出会う

Иновациите немаат граници – Запознајте ги шампионските индустрии на стартапи во 2024 година

यो बर्ष महानगरको अभियान — सम्पदा संरक्षण तथा सम्बर्धन, पर्यटन प्रवर्धनका लागि पूर्वाधार Next Post

Инновации не имеют границ — познакомьтесь с чемпионскими отраслями стартапов 2024 года

Иновације немају границе – упознајте шампионске индустрије стартапа 2024. године

Innovation haina mipaka - Kukutana na viwanda vya kushinda ya Startups ya Mwaka 2024

创新没有界限 - 满足2024年初创企业冠军行业

Infrastructure as code (IaC) has become increasingly challenging as organization and usage scale. Inconsistent configurations, security gaps, and increasing costs remain to be hard to manage without the right level of abstraction, but what's the right level of abstraction? From DevOps to Infrastructure as Code DevOps started with engineers clicking around the AWS console and writing scripts to automate tasks like creating EC2 instances and setting up VPCs, but as usage grew, Infrastructure as Code (IaC) tools such as Terraform and CloudFormation emerged. Instead of writing shell scripts, infrastructure engineers can write declarative code to define how the cloud resources should be deployed. This is a great step up in terms of abstraction from the one-off automation scripts. On one hand, the declarative nature of the IaC tools makes it easy enough for most developers to write (you can think of it as configuration instead of code); on the other, it's not abstracted enough to give platform engineers the ability to write modularized code for developers to create infrastructure across the organization. Take resource tagging for example, for both cost tracking and governance purposes, it's a very common use case to want to tag cloud resources by application, team, business unit, cost center, etc. With Terraform, application engineers need to manually specify these tags for each resource. Even if platform engineering teams create the relevant terraform "tag" module to enforce common fields, application engineers still need to provide the tag values every time. The declarative nature of IaC makes it hard for platform engineering teams to automatically populate these tag values from a central registry of applications and teams. This becomes especially problematic as the number of resources and size of the organization grows. This led to the next question: how can we create a higher level of abstraction on top of IaC that addresses these enterprise-scale challenges? Creating Platform Abstraction for Scale Creating the right level of platform abstraction enables large organizations to manage infrastructure at scale more effectively and increase developer velocity. Platform engineering teams often use a mix of strategies, depending on use cases, resources, and expertise within the organization. 1. Terraform Modules or Templates Creating reusable terraform modules or templates is a common and easy way to create higher-level abstractions. While flexible, it's a lower-level abstraction, and making organization-wide changes can be time-consuming as they require review and testing by individual application teams. For organizations lacking resources and expertise, vendors like Resourcely create templated terraform code with enforced practice and security. 2. Imperative IaC With declarative IaC, integrating external processes into infrastructure deployment often requires workarounds. Platform teams frequently combine declarative IaC with one-off scripts or API calls in their CI/CD pipelines. Tools like AWS CDK (Cloud Development Kit), CDK for Terraform, and Pulumi allow teams to generate IaC using imperative programming languages, enabling platform engineers to create infrastructure code alongside dynamic processes. While this provides greater flexibility and abstraction, it poses a higher adoption barrier for application teams less familiar with these "CDK" frameworks. 3. Infrastructure and Platform as a Service At the highest abstraction level, platforms like Databricks, Confluent, and Elastic wrap entire infrastructure deployments, exposing only relevant configurations to developers. This allows the provisioning of complex, distributed systems with minimal effort. Kubernetes similarly abstracts compute resource management, enabling developers to create deployments using high-level configurations. While the high-level abstraction allows platform teams to standardize provisioning, governance, and security at scale for supported use cases, it comes at the cost of reduced flexibility and potential vendor lock-in. New or custom use cases can require much longer implementation cycles. Platform Abstraction: Balancing Flexibility and Control Defining the "right" level of abstraction is never easy. Too little abstraction can lead to frequent manual updates and migrations, inconsistent standards, and security and governance implementations. However, too much abstraction can force teams to adapt their use cases to fit the platform's limitations, slowing down developer velocity. The ideal abstraction varies case by case. For real-time fraud detection or experimental features, teams often need flexibility. Templated terraform might provide sufficient guardrails while enabling developers to easily create custom deployments. In contrast, common use cases like data streaming involving Kafka, connectors, and multi-platform integrations typically require more abstraction. Platform teams often create end-to-end deployments, exposing only necessary configs. However, data pipelines can be nuanced, and platform teams often expose lower-level components, allowing application teams to create custom implementations easily and bring back these features to the platform as they mature. For less complicated scenarios like application deployment, most teams only need to specify a Docker image, CPU, and memory requirements. Platform teams can wrap up the CI/CD process without exposing lower-level components. Knowing the different implementation strategies and levels of abstraction for various scenarios, how can we build platforms that scale? Future of Platform Engineering Data and AI Platform as a Service Kubernetes has simplified infrastructure and application deployment, but data platforms have become increasingly complex. The proliferation of specialized data tools, compounded by AI and ML solutions, has made standardization, integration, security, and governance much harder to manage than infrastructure or application deployment. Vendors like Confluent, Snowflake, Databricks, and dbt are improving the developer experience with more automation and integrations, but they often operate independently. This fragmentation makes standardizing multi-directional integrations across identity and access management, data governance, security, and cost control even more challenging. Developing a standardized, secure, and scalable solution for multi-platform environments is now a fast-evolving area for platform engineering teams. Higher Abstraction for Standardization, Security, and Governance While application developers can use low-level terraform to create infrastructure on their own, this approach doesn’t scale at the enterprise level. Standardization, security, governance, and cost efficiency aren't just “nice to have” but "required" for large organizations. Many companies undertake multi-year, large-scale migrations due to a lack of abstraction where it’s needed, meanwhile slowing down developer velocity in areas where abstraction isn’t necessary. Developers are looking for a combination of flexibility and simplicity depending on the features they are trying to build. Platform teams must continue to simplify the developer experience while strategically exposing lower-level components where necessary. By exposing the right components, they provide developers with greater flexibility and reduce the time needed to integrate new features back into the platform. Imperative IaC for Platform Teams To enable platform teams to build for higher abstraction and flexibility, offload the complexity from CI/CD pipelines, which are designed for orchestration rather than abstraction. Currently, platform teams typically use either configuration-driven systems or declarative IaC, but both approaches have limitations when it comes to creating sophisticated, dynamic deployments and abstraction. The gap in tooling continues to be a challenge, especially for data and AI platform engineering. While there's a proliferation of data product vendors, few focus on simplifying multi-platform deployments. Instead, there's a surge of governance, lineage, and cataloging products to compensate for the lack of integrations. These solutions aim to solve the complexity that arises from using multiple platforms without addressing the core issue of creating streamlined and flexible deployments across data and AI products and platforms. While infrastructure development tools and frameworks are a highly competitive space, there's still room for tools that can provide the advantage of imperative programming for complex logic, while preserving the audit trails, and version control of declarative IaC for governance and compliance. Summary The value of platform engineering is often less tangible than customer-facing product features. While platform improvements may not directly contribute to top-line growth, they are one of the most effective ways to manage cloud costs, which are often one of the biggest drivers of bottom-line costs. Choosing the right toolings and abstraction levels can not only improve developer experience and productivity but also strengthen security, governance, and compliance across the organization. Infrastructure as code (IaC) has become increasingly challenging as organization and usage scale. Inconsistent configurations, security gaps, and increasing costs remain to be hard to manage without the right level of abstraction, but what's the right level of abstraction? Infrastructure as code (IaC) From DevOps to Infrastructure as Code DevOps started with engineers clicking around the AWS console and writing scripts to automate tasks like creating EC2 instances and setting up VPCs, but as usage grew, Infrastructure as Code (IaC) tools such as Terraform and CloudFormation emerged. Instead of writing shell scripts, infrastructure engineers can write declarative code to define how the cloud resources should be deployed. This is a great step up in terms of abstraction from the one-off automation scripts. Terraform CloudFormation On one hand, the declarative nature of the IaC tools makes it easy enough for most developers to write (you can think of it as configuration instead of code); on the other, it's not abstracted enough to give platform engineers the ability to write modularized code for developers to create infrastructure across the organization. Take resource tagging for example, for both cost tracking and governance purposes, it's a very common use case to want to tag cloud resources by application, team, business unit, cost center, etc. With Terraform, application engineers need to manually specify these tags for each resource. Even if platform engineering teams create the relevant terraform "tag" module to enforce common fields, application engineers still need to provide the tag values every time. The declarative nature of IaC makes it hard for platform engineering teams to automatically populate these tag values from a central registry of applications and teams. This becomes especially problematic as the number of resources and size of the organization grows. This led to the next question: how can we create a higher level of abstraction on top of IaC that addresses these enterprise-scale challenges? Creating Platform Abstraction for Scale Creating the right level of platform abstraction enables large organizations to manage infrastructure at scale more effectively and increase developer velocity. Platform engineering teams often use a mix of strategies, depending on use cases, resources, and expertise within the organization. 1. Terraform Modules or Templates Creating reusable terraform modules or templates is a common and easy way to create higher-level abstractions. While flexible, it's a lower-level abstraction, and making organization-wide changes can be time-consuming as they require review and testing by individual application teams. For organizations lacking resources and expertise, vendors like Resourcely create templated terraform code with enforced practice and security. Resourcely 2. Imperative IaC With declarative IaC, integrating external processes into infrastructure deployment often requires workarounds. Platform teams frequently combine declarative IaC with one-off scripts or API calls in their CI/CD pipelines. Tools like AWS CDK (Cloud Development Kit) , CDK for Terraform , and Pulumi allow teams to generate IaC using imperative programming languages, enabling platform engineers to create infrastructure code alongside dynamic processes. AWS CDK (Cloud Development Kit) CDK for Terraform Pulumi While this provides greater flexibility and abstraction, it poses a higher adoption barrier for application teams less familiar with these "CDK" frameworks. 3. Infrastructure and Platform as a Service At the highest abstraction level, platforms like Databricks , Confluent , and Elastic wrap entire infrastructure deployments, exposing only relevant configurations to developers. This allows the provisioning of complex, distributed systems with minimal effort. Kubernetes similarly abstracts compute resource management, enabling developers to create deployments using high-level configurations. Databricks Confluent Elastic Kubernetes While the high-level abstraction allows platform teams to standardize provisioning, governance, and security at scale for supported use cases, it comes at the cost of reduced flexibility and potential vendor lock-in. New or custom use cases can require much longer implementation cycles. Platform Abstraction: Balancing Flexibility and Control Defining the "right" level of abstraction is never easy. Too little abstraction can lead to frequent manual updates and migrations, inconsistent standards, and security and governance implementations. However, too much abstraction can force teams to adapt their use cases to fit the platform's limitations, slowing down developer velocity. The ideal abstraction varies case by case. For real-time fraud detection or experimental features, teams often need flexibility. Templated terraform might provide sufficient guardrails while enabling developers to easily create custom deployments. In contrast, common use cases like data streaming involving Kafka, connectors, and multi-platform integrations typically require more abstraction. Platform teams often create end-to-end deployments, exposing only necessary configs. However, data pipelines can be nuanced, and platform teams often expose lower-level components, allowing application teams to create custom implementations easily and bring back these features to the platform as they mature. For less complicated scenarios like application deployment, most teams only need to specify a Docker image, CPU, and memory requirements. Platform teams can wrap up the CI/CD process without exposing lower-level components. Knowing the different implementation strategies and levels of abstraction for various scenarios, how can we build platforms that scale? Future of Platform Engineering Data and AI Platform as a Service Kubernetes has simplified infrastructure and application deployment, but data platforms have become increasingly complex. The proliferation of specialized data tools, compounded by AI and ML solutions, has made standardization, integration, security, and governance much harder to manage than infrastructure or application deployment. Vendors like Confluent , Snowflake , Databricks , and dbt are improving the developer experience with more automation and integrations, but they often operate independently. This fragmentation makes standardizing multi-directional integrations across identity and access management, data governance, security, and cost control even more challenging. Developing a standardized, secure, and scalable solution for multi-platform environments is now a fast-evolving area for platform engineering teams. Confluent Snowflake Databricks dbt Higher Abstraction for Standardization, Security, and Governance While application developers can use low-level terraform to create infrastructure on their own, this approach doesn’t scale at the enterprise level. Standardization, security, governance, and cost efficiency aren't just “nice to have” but "required" for large organizations. Many companies undertake multi-year, large-scale migrations due to a lack of abstraction where it’s needed, meanwhile slowing down developer velocity in areas where abstraction isn’t necessary. Developers are looking for a combination of flexibility and simplicity depending on the features they are trying to build. Platform teams must continue to simplify the developer experience while strategically exposing lower-level components where necessary. By exposing the right components, they provide developers with greater flexibility and reduce the time needed to integrate new features back into the platform. Imperative IaC for Platform Teams To enable platform teams to build for higher abstraction and flexibility, offload the complexity from CI/CD pipelines, which are designed for orchestration rather than abstraction. Currently, platform teams typically use either configuration-driven systems or declarative IaC, but both approaches have limitations when it comes to creating sophisticated, dynamic deployments and abstraction. The gap in tooling continues to be a challenge, especially for data and AI platform engineering. While there's a proliferation of data product vendors, few focus on simplifying multi-platform deployments. Instead, there's a surge of governance, lineage, and cataloging products to compensate for the lack of integrations. These solutions aim to solve the complexity that arises from using multiple platforms without addressing the core issue of creating streamlined and flexible deployments across data and AI products and platforms. While infrastructure development tools and frameworks are a highly competitive space, there's still room for tools that can provide the advantage of imperative programming for complex logic, while preserving the audit trails, and version control of declarative IaC for governance and compliance. Summary The value of platform engineering is often less tangible than customer-facing product features. While platform improvements may not directly contribute to top-line growth, they are one of the most effective ways to manage cloud costs, which are often one of the biggest drivers of bottom-line costs. Choosing the right toolings and abstraction levels can not only improve developer experience and productivity but also strengthen security, governance, and compliance across the organization.

Platform Engineering Abstraction: How to Scale IaC for Enterprise

Implementing Geo-Location Redirects with AWS CloudFront

Welcome back to the series where we have been building an application with that incorporates tooling from . So far, we’ve created a pretty cool app that uses AI to generate text and images. Qwik AI OpenAI Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying Now, there’s just one more thing to do. It’s launch time! https://www.youtube.com/watch?v=pob822xaT4Y&embedable=true I’ll be deploying to ‘s cloud computing services (formerly ), but these steps should work with any VPS provider. If you don’t already have a hosting provider, you can sign up at to get $100 in cloud computing credits. Akamai Linode linode.com/austingil Let’s do this! Setup Runtime Adapter There are a couple of things we need to get out of the way first: deciding where we are going to run our app, what runtime it will run in, and how the deployment pipeline should look. As I mentioned before, I’ll be deploying to a VPS in Akamai’s connected cloud, but any other VPS should work. For the runtime, I’ll be using Node.js, and I’ll keep the deployment simple by using Git. Qwik is cool because it’s designed to run in multiple JavaScript runtimes. That’s handy, but it also means that our code isn’t ready to run in production as is. Qwik needs to be aware of its runtime environment, which we can do with adapters. We can access, see, and install available adapters with the command, . This will prompt us with several options for adapters, integrations, and plugins. npm run qwik add For my case, I’ll go down and select the adapter. It works well on a VPS running Node.js. You can select a different target if you prefer. Fastify Once you select your integration, the terminal will show you the changes it’s about to make and prompt you to confirm. You’ll see that it wants to modify some files, create some new ones, install dependencies, and add some new NPM scripts. Make sure you’re comfortable with these changes before confirming. Once these changes are installed, your app will have what it needs to run in production. You can test this by building the production assets and running the command. (Note: For some reason, always hangs for me, so I run the client and server build scripts separately). serve npm run build npm run build.client & npm run build.server & npm run serve This will build out our production assets and start the production server listening for requests at http://localhost:3000. If all goes well, you should be able to open that URL in your browser and see your app there. It won’t actually work because it’s missing the OpenAI API keys, but we’ll sort that part out on the production server. Push Changes to Git Repo As mentioned above, this deployment process is going to be focused on simplicity, not automation. So rather than introducing more complex tooling like Docker containers or Kubernetes, we’ll stick to a simpler, but more manual process: using Git to deploy our code. I’ll assume you already have some familiarity with Git and a remote repo you can push to. If not, please go make one now. You’ll need to commit your changes and push it to your repo. git commit -am "ready to commit 💍" & git push origin main Prepare Production Server If you already have a VPS ready, feel free to skip this section. I’ll be deploying to an Akamai VPS. If you don’t already have an account, feel free to sign up at for $100 in free credits. linode.com/austingil I won’t walk through the step-by-step process for setting up a server, but in case you’re interested, I chose the Nanode 1 GB shared CPU plan for $5/month with the following specs: Operating system: Ubuntu 22.04 LTS Location: Seattle, WA CPU: 1 RAM: 1 GB Storage: 25 GB Transfer: 1 TB Choosing different specs shouldn’t make a difference when it comes to running your app, although some of the commands to install any dependencies may be different. If you’ve never done this before, then try to match what I have above. You can even use a different provider as long as you’re deploying to a server to which you have SSH access. Once you have your server provisioned and running, you should have a public IP address that looks something like . You can log into the server from your terminal with the following command: 172.100.100.200 ssh root@172.100.100.200 You’ll have to provide the root password if you have not already set up an authorized key. We’ll use Git as a convenient tool to get our code from our repo into our server, so that will need to be installed. But before we do that, I always recommend updating the existing software. We can do the update and installation with the following command. sudo apt update && sudo apt install git -y Our server also needs Node.js to run our app. We could install the binary directly, but I prefer to use a tool called , which allows us to easily manage Node versions. We can install it with this command: NVM curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash And once NVM is installed, you can install the latest version of Node with: nvm install node Note that the terminal may say that NVM is not installed. If you exit the server and sign back in, it should work. Upload, Build, & Run App With our server set up, it’s time to get our code installed. With Git, it’s relatively easy. We can copy our code into our server using the command. You’ll want to use your own repo, but it should look something like this: clone git clone https://github.com/AustinGil/versus.git Our source code is now on the server, but it’s still not quite ready to run. We still need to install the NPM dependencies, build the production assets, and provide any environment variables. Let’s do it! First, navigate to the folder where you just cloned the project. I used: cd versus The install is easy enough: npm install The build command is: npm run build However, if you have any type-checking or linting errors, it will hang there. You can either fix the errors (which you probably should) or bypass them and build anyway with this: npm run build.client & npm run build.server source code has working types if you want to check that. The latest version of the project The last step is a bit tricky. As we saw above, environment variables will not be injected from the file when running the production app. Instead, we can provide them at runtime right before the command like this: .env serve OPENAI_API_KEY=your_api_key npm run serve You’ll want to provide your own API key there in order for the OpenAI requests to work. Also, for Node.js deployments, there’s an extra, necessary step. You must also set an variable assigned to the full URL where the app will be running. Qwik needs this information to properly configure their protection. ORIGIN CSRF If you don’t know the URL, you can disable this feature in the file by setting the options property to : /src/entry.preview.tsx createQwikCity checkOrigin false export default createQwikCity({
  render,
  qwikCityPlan,
  checkOrigin: false
}); This process is , but it’s recommended not to disable, as CSRF can be quite dangerous. And anyway, you’ll need a URL to deploy the app anyway, so better to just set the environment variable. Note that if you make this change, you’ll want to redeploy and rerun the build and serve commands. outlined in more detail in the docs ORIGIN If everything is configured correctly and running, you should start seeing the logs from Fastify in the terminal, confirming that the app is up and running. {"level":30,"time":1703810454465,"pid":23834,"hostname":"localhost","msg":"Server listening at http://[::1]:3000"} Unfortunately, accessing the app via IP address and port number doesn’t show the app (at least not for me). This is likely a networking issue, but it is also something that will be solved in the next section, where we run our app at the root domain. The Missing Steps Technically, the app is deployed, built, and running, but in my opinion, there is a lot to be desired before we can call it “production-ready.” Some tutorials would assume you know how to do the rest, but I don’t want to do you like that. We’re going to cover: Running the app in background mode Restarting the app if the server crashes Accessing the app at the root domain Setting up an SSL certificate One thing you will need to do for yourself is buy the domain name. There are lots of good places. I’ve been a fan of and . I don’t think there’s a huge difference for which registrar you use, but I like these because they offer WHOIS privacy and email forwarding at no extra charge on top of their already low prices. Porkbun Namesilo Before we do anything else on the server, it’ll be a good idea to point your domain name’s A record ( ) to the server’s IP address. Doing this sooner can help with propagation times. @ Now, back in the server, there’s one glaring issue we need to deal with first. When we run the command, our app will run as long as we keep the terminal open. Obviously, it would be nice to exit out of the server, close our terminal, and walk away from our computer to go eat pizza without the app crashing. So we’ll want to run that command in the background. npm run serve There are plenty of ways to accomplish this: Docker, Kubernetes, Pulumis, etc., but I don’t like to add too much complexity. So for a basic app, I like to use , a Node.js process manager with great features, including the ability to run our app in the background. PM2 From inside your server, run this command to install PM2 as a global NPM module: npm install -g pm2 Once it’s installed, we can tell PM2 what command to run with the “ ” command: start pm2 start "npm run serve" PM2 has a lot of really nice features in addition to running our apps in the background. One thing you’ll want to be aware of is the command to view logs from your app: pm2 logs In addition to running our app in the background, PM2 can also be configured to start or restart any process if the server crashes. This is super helpful to avoid downtime. You can set that up with this command: pm2 startup Ok, our app is now running and will continue to run after a server restart. Great! But we still can’t get to it. Lol! My preferred solution is using . This will resolve the networking issues, work as a great reverse proxy, and takes care of the whole SSL process for us. We can follow the and run these five commands: Caddy install instructions from their documentation sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy Once that’s done, you can go to your server’s IP address, and you should see the default Caddy welcome page: Progress! In addition to showing us something is working, this page also gives us some handy information on how to work with Caddy. Ideally, you’ve already pointed your domain name to the server’s IP address. Next, we’ll want to modify the Caddyfile: sudo nano /etc/caddy/Caddyfile As their instructions suggest, we’ll want to replace the line with our domain (or subdomain), but instead of uploading static files or changing the site root, I want to remove (or comment out) the line and enable the line, pointing the reverse proxy to my Node.js app running at port 3000. :80 root reverse_proxy versus.austingil.com {
        reverse_proxy localhost:3000
} After saving the file and reloading Caddy ( ), the new Caddyfile changes should take effect. Note that it may take a few moments before the app is fully up and running. This is because one of Caddy’s features is provisioning a new SSL certificate for the domain. It also sets up the automatic redirect from HTTP to HTTPS. systemctl reload caddy So now, if you go to your domain (or subdomain), you should be redirected to the HTTPS version running a reverse proxy in front of your generative AI application, which is resilient to server crashes. How awesome is that!? Using PM2, we can also enable some load-balancing in case you’re running a server with multiple cores. The full PM2 command, including environment variables and load-balancing, might look something like this: OPENAI_API_KEY=your_api_key ORIGIN=example.com pm2 start "npm run serve" -i max Note that you may need to remove the current instance from PM2 and rerun the start command, you don’t have to restart the Caddy process unless you change the Caddy file, and any changes to the Node.js source code will require a rebuild before running it again. Hell yeah! We did it! Alright, that’s it for this blog post this series. I sincerely hope you enjoyed both and learned some cool things. Today, we covered a lot of things you need to know to deploy an AI-powered application: and Runtime adapters Building for production Environment variables Process managers Reverse-proxies SSL certificates If you missed any of the previous posts, be sure to go back and check them out. Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying I’d love to know what you thought about the whole series. If you want, you can play with the app I built at . Let me know if you deployed your own app, and I’ll link to it from here. Also, if you have ideas for topics you’d like me to discuss in the future, I’d love to hear them :) versus.austingil.com If you liked this project and are curious to see what it might look like as a app, where he converts this existing app over. UPDATE: SvelteKit check out this blog post by Tim Smith Thank you so much for reading. If you liked this article and want to support me, the best ways to do so are to , , and . share it sign up for my newsletter follow me on Twitter Originally published on . austingil.com

AI for Web Devs: Deploying Your AI-Powered App with Qwik and OpenAI

Stories, News & Mentions about PULUMI

Categories

Trending Topics

Stories, News & Mentions about PULUMI

Pulumi’s Stories on HackerNoon

Categories

Trending Topics