In one of my previous blog post, we saw that creating a VPC is quite simple. We just need to provide values to four parameters and we can get our VPC up and running in minutes:
From these four parameters, the CIDR block is usually the trickiest one to understand. And this parameter is critical — because once your Mule VPC is created,
CloudHub is the cloud-based iPaaS component of Anypoint Platform. Applications on MuleSoft Cloudhub are run by one or more instances of Mule, called workers. Each worker is a dedicated instance of Mule that runs your integration application. In the default configuration, all cloud-based workers reside in a multi-tenant public cloud, balanced by a publicly accessible shared load balancer.
In my previous blog post, we explained the different scenarios required to get a VPC in place. But there’s yet another question we need to answer before creating our first VPC. Is it enough with one VPC? How many VPCs do I really need? In this blog post, we’ll review some of the considerations to decide how many VPCs should be included in your network architecture.
One of the first tasks to set up your Anypoint Platform is the definition of your network architecture and in particular your virtual private cloud (VPC). Creating a VPC is a pretty straightforward process that can be done in a couple of minutes, you just need to provide the values for four parameters:
There are a variety of ways to establish connectivity between Anypoint CloudHub workers and systems deployed on backend customer-hosted or vendor-managed data-centers. One of the ways is through Anypoint VPN which provides a secure tunnel between cloudhub workers and a data-center. In order to setup the VPN tunnel or extend the CloudHub network with corporate network, we need to setup Anypoint VPC. Anypoint VPC provides an isolated network segment to host CloudHub workers.
For the last few decades, application and operational teams have been preaching loudly about monitoring and alerting capabilities to improve system resiliency. It is only with COVID-19, however, that these capabilities have shifted from “luxury” items to “absolutely necessary” capabilities to ensure business continuity.
As businesses take the next steps to refine their monitoring and alerting capabilities, it is critical that all stakeholders understand and utilize the same frameworks and metrics.
In enterprise system integrations, there’s no escaping the need to include file transfers in workflows. Integrators building out an application network in MuleSoft often need to meet various file transfer use cases involving multiple B2B partners, customers, and internal lines of business. It isn’t uncommon for large consumer goods companies to exchange millions of files per month with partners such as retailers, banks, and wholesalers.
In my daily interactions with MuleSoft customers, I always get the question what I regard as the most effective way to secure Mule applications and APIs on Anypoint Platform. A majority of our customers deploy their Mule applications on CloudHub — our MuleSoft managed and hosted cloud offering. So by the default, any application that gets deployed on CloudHub is exposed to the outside world and needs to be secured — from an access and authentication perspective,
This blog describes upcoming Anypoint Platform features within access management, mapping them to the most common use cases and customer needs.
In my last blog, I discussed a few ways governments can create citizen journeys with API-led connectivity to address the inertia caused by legacy IT systems. We return to the second reason digital government services are held back: providing secure services. In this blog post, I’ll review the fundamentals of dealing with digital government services and how governments can create a better citizen experience through these fundamentals.
