DEV Community

Cover image for Building the Right Platform
Vinay Hegde
Vinay Hegde

Posted on

Building the Right Platform

In mid-level and big scale organizations, the mission focus is on having continuous innovation backed by stability. The former is required to stay ahead of the curve (being better than one's competitors) while the latter is the springboard to delivery. Thus, a strong platform is an apparent need for every technological company.

Thus, we land upon a concept called Platform Engineering.

So what's it actually?

As per this definition
Platform engineering is the process through which enterprises adopt (new technology and platforms), leverage (existing technologies and platforms), and transform (shift the dial on delivering value by transforming the way things are done) cloud platforms. It is at the core of designing, building, and operating your cloud infrastructure to deliver the next generation IT ecosystem.

While the above definition is accurate, it does not really help understand on the why, what & how to build reliable platforms. Especially for teams who are looking to either augment or revamp their infrastructure from old ways to new.

Therefore, I felt I could contribute by creating one from my know-how so far. For easier understanding, the categories herewith will be structured into the following parameters: why, some points to consider, alternatives.

begin-blog

To build a smooth platform, most e-commerce companies need tooling/tech/processes/workflows in the following categories.

Domains
Infrastructure
Version Control
Packaging
CI/CD
Web-Services
Databases
Monitoring

Domains

Right Domain Name

Why?: Branding of one's product, everything on the internet begins with a domain. E.g: google.com, facebook.com, dev.to
Some points to consider?:

Known tools: Bigrock.in
Alternatives: Namecheap, Route53, Cloudflare, Google Registry

Infrastructure

Infrastucture Diagram

Why?: Gateway to the system, having the right infrastructure will be like a strong backbone.
Some points to consider?:

  • Basic features such as instances/VMs, isolated networks (not everyone will need Kubernetes or Mesos)
  • Sufficient Capacity for one's enterprise at scale (The last thing one wants in the middle of a frantic user rush is no hardware available)
  • Multiple accounts with RBAC to distinguish between teams/environments.
  • Compatibility with Infrastructure-as-Code tools
  • Effective Pricing.

Known tools: Amazon Web Services (AWS)
Alternatives: Google Cloud Platform, Microsoft Azure Cloud, DigitalOcean, Linode

Version Control

Version Control

Why?: Managing codebases with multiple teams across varied projects in different business verticals.
Some points to consider?:

  • Decentralized (avoids a single point of failure)
  • Clear history log (for updates/rollback)
  • Branching/separating strategies.
  • Ease of setup

Known tools: Git
Alternatives: Mercurial, TFS, SVN

Packaging

Application Packages

Why?: Software should be same across environments. Helps in the CI/CD step and reproduce issues to be fixed quicker
Some points to consider?:

  • Application storage size (No point in having GB sized containers)
  • Ability to generate artifacts (if any)

Known tools: Docker
Alternatives: Containerd, LXC, APT, Yum

CI/CD

ci-cd-flow

Why?: To compile/build and deploy software easily. Manual steps can be time-consuming, error-prone and be a bottleneck.
Some points to consider?:

  • Ability to build/deploy multiple programming languages, frameworks
  • Support for unit/smoke tests, canary deployments.
  • Preferably independent than infrastructure (helps avoid vendor lock-in)
  • Self-hosted vs SaaS (factors here are cost, upgrades and maintenance)

Known tools: Jenkins
Alternatives: Github Actions, Gitlab , CircleCI, TravisCI, ArgoCD

Web-Services

web-entrypoint

Why?: Helps your userbase access all the consumer endpoints of the system. For e.g: discover, checkout, payments
Some points to consider?:

  • Scale management (An incorrectly setup web-service can quickly have a cascading effect in case of heavy traffic)
  • Reverse proxying to one/multiple back-ends and fail-overs (for High Availability)
  • Support for HTTP/GRPC protocols.
  • Advanced features such as rate-limits, throttling, IP bans.

Known tools: HAProxy
Alternatives: NGinx, Apache, Ambassador, Envoy, Istio

Databases

sample DB stucture

Why?: To maintain state of applications and store all data such as inventory, payments and other types of relational information. Helpful for data analytics as well.
Some points to consider?:

  • ACID Compliance
  • Libraries/connectors for multiple programming languages.
  • Storage parameters such as in-memory or persistent to disk.
  • Ease of backup, recovery in case of DR drills.
  • Key-value stores for relatively smaller datasets.

Known tools: MySQL or MariaDB
Alternatives: PostgreSQL, MSSQL, MongoDB, Kafka, Aerospike, Redis, Memcached

Monitoring

Monitoring system

Why?: A small monitored system will be more reliable than a big one without.
Some points to consider?:

  • Agents/libraries across multiple programming languages.
  • Ability to view application/infrastructure metrics.
  • Retention as per compliance.

Known tools: NewRelic
Alternatives: Datadog, AppSignal, Instana, ElasticAPM

TL;DR: While this is not a definitive list of things that's required to build a system but there's a good chance this blog post provides an entrypoint for you to begin with


What are some pointers you would consider to build a reliable, consistent and easy-to-use platform?

Discussion (0)