The financial perils of infinite capacity I see a very common and dangerous pattern across many of the teams I support, with regard to their cloud utilization habits: there isn’t a clear sense of the financial impact of their development output. What I mean is, teams working with the cloud have no fiscal responsibility as to the expenses and budget they’re working with - and this unawareness triggers bad behaviors:

An insatiable internet Five years ago in 2015, HTTP/2 was officially launched. Based on earlier developments by Google and their SPDY protocol, it looked to solve known issues present in the previous HTTP/1.1 standard as well as enable lower latency, data compression, and other features necessary for an internet growing ever larger and hungrier for speed and data. Fast forward to today, and the scale of the internet has outgrown all expectations, and so have the needs of users relying on technologies built on top of the HTTP protocol, which represent a large percentage of traffic on the internet.

What you’ll get out of this series The world of cloud native engineering is reaching ever new heights in terms of flexibility, integration and elegance, all driven by adoption that rapidly gains momentum and the myriad of learning opportunities and challenges that arise from that velocity. The Open Application Model looks to provide structure, in a vendor agnostic way, towards clearly defining the context of responsibility for each different participant in a cross functional team as well as across teams as they build service oriented, cloud native solutions.

If you haven’t heard the buzz about confidential computing, I’m sure you will very soon. I hope with this post you will: Get a bit of background of what confidential computing is, and how we got here. Understand some technical concepts you will need to be aware of, to understand confidential computing. Get an overview of the current features available across the major public clouds supporting confidential computing. What is confidential computing Data moves through three different states:

Welcome to Part 3 of this series on multicloud data with Debezium. For those just joining us, in part 1 you can learn about the high level architecture of what we will be building and get a quick introduction to Debezium as a change data capture tool. In Part 2 we start building our solution, specifically the AWS side of things, where our data will originate. We are now going to look in this 3rd and last part where we get to consume and extract value from this data from a different cloud, the Google Cloud Platform, and we will see the full solution in action!

Welcome to Part 2 of this 3-part series on Multicloud Data with Debezium - in this post we will be building the source of our data, and will be implementing Debezium for tracking and streaming data changes in AWS. For those that just got here and need a refresher on the scenario that we’re using for our experiment, or if you need to know which tools you’ll need installed to deploy this solution, take a look at part 1 of this series.

Multicloud Data with Debezium When thinking multi cloud, data is usually one of the more complicated concerns. Regardless of whether thinking multi cloud for disaster recovery or to better leverage each cloud’s own strengths, there will always be scenarios where you need to make sure data is available and consistent across multiple cloud platforms. In this series I will demonstrate a concept leveraging Debezium, an open source distributed platform for change data capture (CDC) as our core mechanism to get data across multiple clouds.