Operations | Monitoring | ITSM | DevOps | Cloud

There's a version of cloud strategy that looks like a decision and a version that looks like drift. Most enterprises are living the second version. AWS won an early workload because the team knew it. Azure followed the Microsoft enterprise agreement. GCP came in through a data science team that preferred its ML tooling. Nobody chose concentration; it just accumulated.

Ask any engineering leader how AI has changed their team, and you'll get an optimistic answer. Ask them to prove it with a number, and most go quiet. That gap is the story of 2026. Individual engineers are faster than they've ever been. Teams, in a lot of cases, aren't. We talked to our own engineering team, the people who've spent the last year building and shipping Upsun Dispatch and living through exactly this shift, and the same tension came up again and again.

When platform providers talk about autoscaling, they usually mean one thing: application autoscaling, adding or removing web instances based on traffic. The pattern is well understood. Define a metric, set a threshold, and let the platform act on it. Most platforms still leave database capacity as a separate, mostly manual problem. Teams either pre-provision for the worst hour of the worst day, upgrade plans on a calendar, or wire together their own scaling logic on Kubernetes or RDS.

Hosting an MCP (Model Context Protocol) server on Upsun lets AI IDEs like Cursor, Codex, Claude Code and Windsurf reach real infrastructure context (database schemas, service logs, environment variables), closing the gap between local coding assistants and your cloud environment.

For most IT leaders, multicloud didn't arrive as a decision. It arrived as a fait accompli. A team chose AWS for one workload. Azure came in through a Microsoft enterprise agreement. A SaaS acquisition brought its own cloud dependencies. A DR requirement pointed to a second region with a different provider. Nobody declared a multicloud strategy; the organization just became one. Today, 87% of organizations run a multicloud strategy, balancing an average of 2.6 public cloud providers simultaneously.

Application autoscaling has existed for years. Database autoscaling has lagged behind. Today, that changes on Upsun. Managed PostgreSQL and MariaDB read replicas now autoscale, joining worker autoscaling in production since March 2026. Apps, workers, and managed databases all autoscalead replicas saturate first, connection pools max, someone getse on one platform - natively, without a third-party database engine or a Kubernetes layer to operate. Three operational headaches just disappeared.

As Staff Engineers and Principal Architects, most of us have spent years thinking about long-term system health. We are considerate of the company’s business objectives and strategy, accumulation of technical debt, and operational risk. For us it is not about whether code works today, but whether the engineer who inherits it in three years will be able to understand what it was trying to do and why. That's what makes a codebase maintainable rather than just functional.

Database migrations are where the mock data problem shows up most clearly. A migration that adds an index to a table with 500 rows in the development database runs in milliseconds and passes every test. The same migration against a production table with 8 million rows locks the table for 90 seconds during peak traffic. Nobody saw it coming because nobody tested it against 8 million rows. This isn't an edge case.

There is a question a lot of engineering leaders are quietly sitting with right now: we have rolled out AI tools across the team, the developers seem faster, so why isn't more software actually shipping? It is a reasonable thing to consider. Pull requests are opening faster. Lines of code per sprint are up. The boilerplate that used to take full afternoons now takes minutes. By every local measure, the investment is paying off.

Standardizing the fleet: automated updates for multi-site management There's a specific kind of update that Drupal agencies and enterprise teams dread: a security release in something the whole fleet runs on, the PHP runtime, the database engine, or a shared service, with a patched version available now and a deadline attached. For a team managing a single site, moving to the patched version is an afternoon of work.

If you've shipped software in fintech, healthcare, or government, you probably know the specific dread of an upcoming compliance audit. Not because the software isn't secure, but because proving it is requires reconstructing a paper trail for decisions that were made in Jira tickets, Slack threads, and pull request comments over the last six months. The software is fine. The documentation of the software is the problem.