JJ was early for the Tuesday 10 o’clock meeting, which usually meant he was holding his yoga poses too long.
Georgie was already there with a pink notebook open to a blank page.
When JJ arrived and got settled with his black coffee with extra grass-fed butter, he started with the good news.
“Georgie and I have been talking with a major frozen-food supplier in Canada. They also service the EU. Paris wants in with their own pilot running on Azure, using our pilot database.”
Selena added a note to her notebook: Paris compute. Our data. Hot!
Go Fast, Go Public
Raja nodded as if the architecture had already agreed with him. “That’s a multi-cloud decision. Azure containers. AWS database. We can connect them together publicly.”
Georgie wrote down: multi-cloud? bigger? better? and then jumped up and stood beside JJ. “We need a review. Ownership. Checks and balances. My glow-in-the-dark presentation is still useful, and I would like the architecture to survive the slides.”
JJ smiled at the word architecture. Paris. He was already packing sample bags in his head.
Bart still had not met a multi-cloud deployment he trusted.
Raja kept going. “If Paris is on Azure and the database is on AWS, the fastest way is to make the database easy to reach. Open it enough. Let Azure connect. Georgie can redo her demo for Paris on Thursday.”
Bart put his Jolt! cola down with a bang. “If Paris connects the wrong way, the failure will be a delayed pilot, and a database story nobody wants in email.”
“We are not doing this again,” he said. “Last week was using a public path with default rules. Old records treated like they did not count. We are not giving Paris a public database because it is convenient.”
Selena held up both hands. “I agree with Bart.”
“They need answers,” Bart said. “Answers that don’t require a database login.”
The Records Room
Georgie frowned. She wanted a phrase she could reuse in her presentation that sounded like an expert was talking.
“Explain it like I have to present it,” she said.
Bart did. “Think of the database as the records room. Nobody from Paris walks into the records room. Not because we do not trust Paris. Because a records room with a public street door is still a bad records room.”
He drew a box on the whiteboard and labeled it AWS.
“Inside AWS we keep the database private. In front of it we put an API. The API is the doorman. Paris talks to the doorman. The doorman checks who is calling and what they are allowed to ask. Only then does it fetch records from the room.”
He drew a second box and labeled it Azure.
“Paris runs containers here using Azure compute on an Azure VNet. Their containers call the API here on AWS. They do not access the database on the public internet.”
Selena wrote: API = doorman. Database = records room. Keys stay with the doorman.
“So, Paris does not get a public records room,” Georgie said. “Paris talks to the doorman.”
Georgie flipped her notebook shut and wrote on the cover: don’t ever use orange and yellow markers when presenting!
Peering is Not Always Magical
Raja tried one more shortcut question. “Could Azure just talk to the database using a one-to-one peering connection?”
“Peering is not a magic hallway,” Bart said. “Peering is a controlled connection between two separate networks. It still needs rules and a proper design.”
JJ asked if using containers made this harder.
“No,” Bart said. “Containers package the app. They do not replace a private database path. Fargate on our side, Azure Kubernetes Service is on theirs. The database uses a private endpoint. Paris never gets a public one.”
“I need the real short version on endpoints,” Georgie said.
Bart gave her the short version.
“A public database endpoint is like a door on the street. Anyone could open it. A private endpoint keeps the database off the public street. Paris talks to the doorman. The doorman is allowed to use the private endpoint to access the database.”
Selena added: Public endpoint = street door. Private endpoint = inside door. API = doorman who decides who is allowed to knock.
Raja exhaled. “So I should not open the database to the world for the Azure pilot.”
“Correct,” Bart said. “Run this automation script.”
Bart dropped a link for the script for Raja in the Slack tech channel: paris-pilot-path.sh. Network layout. Private database endpoint. API only. Logging on.
Thursday in Paris
Bart built the automation with the operations the pilot needed. Logging was enabled so questions asked were visible. No midnight console invention. No temporary public access that would still be there next October.
“Paris can deploy on Azure when their side is tested and approved,” Bart said. “They call the API. They do not access the database from the internet for convenience.”
Thursday the demo was presented by Georgie to the Paris division. She said the word endpoint more than JJ preferred, but Bart’s design was far better than Raja’s plan.
“Azure-side containers requested pilot data through the API. The API hosted on AWS, answered only what it was allowed to answer. The API used the private endpoint to the database. The database stayed private. Nobody loaded ten-year-old records onto a public path.”
During the presentation, JJ dimmed the lights and made the sample label glow.
Georgie tapped JJ’s arm. “Endpoints are cool,” she whispered.
Friday morning there was no ransom text. There was a short note from Bart in the tech channel:
Pilot problem from last week: defaults, public neighbourhood, skipped script.
New improved design: Azure compute, AWS data, API doorman, private database endpoint. Paris tech team on board.
Raja replied that he had run the script before lunch. Georgie replied that her presentation now had a new header on every slide: Paris talks to the doorman; the database never stands on the street.
JJ replied with a photo of sample bags glowing in the colours and the word Paris in the caption, which everyone ignored productively.
What the Problem Actually Was
Not Azure. Not AWS. Not Kubernetes. Not the fact that two clouds appeared in one pilot.
The danger was treating multi-cloud like a logo and treating public database access as a good design decision.
Paris ran their pilot on Azure. The pilot database stayed on AWS. The API controlled who could ask questions and provided answers. The private database endpoint kept the answers from becoming an incident.
Containers packaged the work. Network design kept the work safe.
Proper multi-cloud design knows where the data lives, where the compute lives, and who is allowed to talk.
Three questions worth asking before the next multi-cloud pilot
1. When separate teams need access to the same data, do they need a database login - or API access?
2. Is a pilot database hosted on a public path because it is the right decision, or only because it is convenient?
3. If the path between Paris and the data fails at 2 a.m., what breaks first - and who owns the fix?
Ask. Understand. Connect. Belong.
The daily concept, question, and rationale arrive at dontknowjack.club every weekday. Selena’s Crossword every Sunday. Free. No credit card.