Gartner's "top 5 strategic technology trends in software engineering in 2024" report (key takeaways)

June 13, 2024

Ready to start?

 Gartner's "top 5 strategic technology trends in software engineering in 2024" report (key takeaways)

Intro

On May 15th, Gartner released a report on the top 5 technology trends in software engineering in 2024

The five key trends are:

  • Software engineering intelligence
  • AI augmented intelligence
  • Green software engineering
  • Platform engineering and
  • Cloud development environments.

Port is mentioned in the report, which cites internal developer portals as one of the key steps in beginning to implement platform engineering. 

Here are our key takeaways from the report: 

Developer experience & productivity are a core focus for software engineering leaders

This is the main takeaway from the report. Whether leaders use software engineering intelligence platforms to understand what developers are doing, try to make the SDLC less overwhelming for developers or are considering AI-augmented development, the message stays the same: software engineering needs simplification and developer experience needs to get better.

The trends are mostly all about this - understanding the process and value of software development and ensuring the developer experience is better, since it directly affects productivity.

The time is now for platform engineering 

Gartner predicts that by 2026, 80% of large software engineering organizations will establish platform engineering teams, up from 45% in 2022. 

Platform engineering was introduced to help organizations deal with the increased complexity and chaos of modern software architectures, and help to reduce the cognitive load on developers.

The widespread adoption of microservices, APIs, and open source technologies in recent years has created huge opportunities for innovation and collaboration, but has left developers with significant challenges, such as the complexity of Kubernetes, the migration from on-prem to SaaS and the uptake of more and more tools and frameworks.

Gartner believes that platform engineering can free software engineers from having to navigate all of this, enabling product teams to focus on delivering the products that customers want. 

By utilizing reusable tools, automated infrastructure operations, and self-service capabilities, platform engineering prioritizes the developer experience and boosts productivity. It delivers standardized tools, streamlined components, and automated workflows, fostering a collaborative ecosystem.

At Port, we see another important trend - where many tools converge into the internal developer portal. In fact, we think that software engineering intelligence, mentioned as one of the trends in the report, may one day “live” within an internal developer portal.

Product owners are key to making platform engineering work

To really get to grips with the tools that developers need, you have to take a platform as a product approach, which considers how the platform will be used and how it will evolve and continuously improve over time. 

Platform engineering is managed by a dedicated platform team comprising skilled platform engineers, and Gartner suggests that your dedicated platform team must include a product owner to analyze developer experience and identify the biggest pain points to address. We definitely agree with this approach and have written both about a product led approach to a portal MVP (link) and created a portal roadmap planner (link). These tools and approaches help platform product owners avoid the trap of technical perfection instead of thinking about delivering product-like experiences to their developer users.

Platform product owners can also use the portal to deliver on better AppSec practices, API governance and more, serving additional stakeholders beyond developers.

Start with the Thinnest Viable Platform 

Gartner suggests that the best way to start with platform engineering is to start small by building a thinnest viable platform that addresses developers’ top pain points and implementing an internal developer portal like Port to provide access to common services. Remember, the portal abstracts away your platform’s complexity. 

Team Topologies defines the thinnest viable platform (TVP) as a careful balance between maintaining a minimal platform and ensuring it effectively accelerates and simplifies software delivery for the teams using it. If your internal developer platform is not fully developed, a TVP can help outline the essential components needed for a portal on top of it.

From that outline, you can get to work on a minimal viable product (MVP) of an internal developer portal. The MVP is a smaller subset of developer routines that cover actual use cases in the organization, servicing real developer needs, which can then be tested and iterated on.  

In short, to get started you should:

  1. Work on a TVP of your internal developer platform
  2. Choose an internal developer portal on top of the platform (this is where Port comes into play)
  3. Work on an MVP of your internal developer portal

Read Gartner’s research, here

Find out how to get started with an internal developer portal, here.

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start