In today’s fast-paced digital world, companies are looking for ways to securely expose their APIs and microservices to the internet. MuleSoft Anypoint Flex Gateway is a powerful solution that solves this problem.

Let's walk through deploying the Anypoint Flex Gateway on Heroku in a few straightforward steps. You'll learn how to connect your private APIs and microservices on the Heroku platform through the Anypoint Flex Gateway and the Anypoint API Manager, without the hassle of managing infrastructure. Get ready to unlock the potential of this potent pairing and, in the future, integrate it with Salesforce.

This blog post is adapted from a talk given by Ali Hamidi at Data Council SF '19 titled "Operating Multi-Tenant Kafka Services for Developers on Heroku."

Today we're excited to announce Site-to-Site Virtual Private Network (VPN) support for Heroku Private Spaces. Heroku customers can now establish secure, site-to-site IPsec connections between Private Spaces on Heroku and their offices, datacenters and deployments on non-AWS clouds.

VPN is a powerful, proven and widely-adopted technology for securely combining multiple networks (or adding individual hosts to a network) over encrypted links that span the public Internet. VPN is well-understood and in use by most enterprise IT departments, and is supported on all major cloud providers and by a range of hardware and software-based systems.

Today we’re announcing a powerful new network control for apps running in Heroku Private Spaces: Internal Routing. Apps with Internal Routing work exactly the same as other Heroku apps, except the web process type is published to an endpoint that’s routable only within the Private Space and on VPC and VPN peered networks (see the Private Space VPN support companion post). Apps with Internal Routing are impossible to access directly from the public internet, improving security and simplifying management and compliance checks for web sites, APIs and services that must not be publicly accessible.

This is the first in a series of blog posts examining the evolution of web app architecture over the past 10 years. This post examines the forces that have driven the architectural changes and a high-level view of a new architecture. In future posts, we’ll zoom in to details of specific parts of the system.

The standard web application architecture suitable for many organizations has changed drastically in the past 10 years. Back in Heroku’s early days in 2008, a standard web application architecture consisted of a web process type to respond to HTTP requests, a database to persist data, and a worker process type plus Redis to manage a job queue.