REST, API, SDK, Cloud, Internet Buzzword Bingo!
If you are new here, welcome! If you are returning for another dose (of whatever this post is), welcome back! I now work on the Oracle Cloud Infrastructure (OCI) Database Tools (DBTools) team, where we build cool software for the cloud. For the past few months, by the time I wrote this post, I have been working hard to get up to speed on OCI. (Still in geek heaven, by the way.)
What follows is a chat about geek stuff.
Building the software that makes a cloud run requires many technical skills and an understanding of various concepts combined. Once the building blocks are in place, it's a bit like the ultimate lego set for geeks, where we can build anything with the right pieces.
Jefe, what is a plethora? ~ El Guapo, 1986
With cloud software, there is no shortage of N-letter acronyms (lazily, just TLA). Well, that is probably true for every domain, but you get a whole new set of cloud-oriented TLAs, for which you must allocate some memory.
Side note, listing to Low Roar as I write this. They have some great "going on a relaxing journey" tunes if you are into that sort of thing.
TLAs aren't all bad. Imagine how long and repetitive geek conversations and reading would be if we didn't use acronyms, for example.
I can't wait to try out the latest representational state transfer application programming interface for the virtual cloud network service. How are the hypertext transfer protocol over secure socket layers with transport layer security 1.2 updates coming along for the new software development kit?
Let's turn on the acronyms.
I can't wait to try out the latest REST API for the VCN service. How are the HTTPS with TLS 1.2 updates coming along for the new SDK?
It was contrived, yes. But highlights well the amount of visual and auditory compression we get from communicating with TLAs.
Did you know OCI publishes SDKs for various languages (Java, Go, Python, .NET, etc.)?
Here is a reasonably technical example of putting those legos to good use.
Private Endpoints and Connections
It is time for a new acronym. A private endpoint (PE) is a software-defined networking concept that allows you to securely send traffic to (and from) a host that sits in an isolated virtual cloud network (VCN). PEs handle the routing of network traffic and all the private domain resolution magic. The VCN handles security by defining what traffic is allowed to and from the PE.
Imagine your VCN is an exclusive nightclub with all kinds of cool database or API stuff happening inside.
- The PE is the path from outside, leading people to the secret entrance of the club. Remember, the VCN is exclusive; knowing how to get to the club is not enough to guarantee entrance.
- The VCN employs bouncers (security lists or network security groups ... NSGs) only to allow people in if they were sent from the right place.
- The VCN also controls which people are allowed out and where they can go. Maybe this is not a nightclub at all, but instead, you are inside Hotel California. (such a lovely place)
Right. Way oversimplified and maybe strange, but you get the idea.
VCNs use stateful (or stateless) packet filtering to only allow traffic into the database on specified ports or from the specified range of network addresses. This is known as ingress, and egress is just the opposite. (What traffic is allowed going out of the VCN?)
The DBTools example above shows how to use the OCI Go SDK to run queries over a DBTools connection. These are similar to saved connections in SQL Developer, which define the database target, authentication details, wallet file (for mutual TLS), etc. A DBTools connection could point to a public database, but more importantly, a database that lives in an exclusive nightclub, accessible via PE.
I have more examples of using DBTools connections and the OCI SDKs in the works. Stay tuned ™.
In the meantime, you can find many examples within the various SDKs linked above. For example, here are Java SDK examples my team contributed to the DBTools service.
It has been good chatting with you. Until next time.