Containers vs Mainframes: Scaling & Consistency
Key Points
- Containers achieve scalability by adding many distributed instances, whereas mainframes rely on vertical growth, making them larger in a single, centralized location.
- A hybrid architecture can place containers near users for low‑latency front‑end processing while using the mainframe as a centralized back‑end for critical data and workloads.
- Containers often shard or duplicate data to enable horizontal scaling, supporting eventual consistency for non‑critical information, while mainframes maintain a single, always‑consistent database by scaling up.
- The decision to scale out (containers) or scale up (mainframes) hinges on whether the application’s data requires strict consistency or can tolerate delayed synchronization.
- By combining the container’s flexible, geographically dispersed compute with the mainframe’s high‑integrity, centralized processing, systems can achieve both performance and reliability.
Sections
- Container vs Mainframe: Scaling Debate - A dialogue contrasts containers' horizontal scaling and global placement with mainframes' vertical scaling and centralized processing, showing how the two approaches can complement each other.
- Mainframe Integration with Modern Dev Tools - The speaker explains when eventual consistency is acceptable, then highlights that mainframe developers can use the same IDEs, pipelines, and build/deploy tools as modern container‑based developers, enabling a unified workflow across COBOL, REXX, Java, and other languages.
Full Transcript
# Containers vs Mainframes: Scaling & Consistency **Source:** [https://www.youtube.com/watch?v=H9m04URhpsk](https://www.youtube.com/watch?v=H9m04URhpsk) **Duration:** 00:05:21 ## Summary - Containers achieve scalability by adding many distributed instances, whereas mainframes rely on vertical growth, making them larger in a single, centralized location. - A hybrid architecture can place containers near users for low‑latency front‑end processing while using the mainframe as a centralized back‑end for critical data and workloads. - Containers often shard or duplicate data to enable horizontal scaling, supporting eventual consistency for non‑critical information, while mainframes maintain a single, always‑consistent database by scaling up. - The decision to scale out (containers) or scale up (mainframes) hinges on whether the application’s data requires strict consistency or can tolerate delayed synchronization. - By combining the container’s flexible, geographically dispersed compute with the mainframe’s high‑integrity, centralized processing, systems can achieve both performance and reliability. ## Sections - [00:00:00](https://www.youtube.com/watch?v=H9m04URhpsk&t=0s) **Container vs Mainframe: Scaling Debate** - A dialogue contrasts containers' horizontal scaling and global placement with mainframes' vertical scaling and centralized processing, showing how the two approaches can complement each other. - [00:03:02](https://www.youtube.com/watch?v=H9m04URhpsk&t=182s) **Mainframe Integration with Modern Dev Tools** - The speaker explains when eventual consistency is acceptable, then highlights that mainframe developers can use the same IDEs, pipelines, and build/deploy tools as modern container‑based developers, enabling a unified workflow across COBOL, REXX, Java, and other languages. ## Full Transcript
Hi, I'm Container.
Hi, I'm Mainframe.
Even though I'm a container, I started my career as mainframe.
So for today's video, I was thinking of a little retrospective.
We're going to look at three different scenarios to see how they're approached
from both viewpoints and how they might work better together.
Sound good?
Sounds great.
Let's get started!
Cool.
Let's start out with scaling.
So, when I need to scale to add additional capacity, I scale horizontally.
Adding new containers.
How's that scenario play out for you, Mainframe?
And I don't have that problem.
I just scale vertically.
So I just keep getting bigger and bigger for all my work.
Okay, "bigger".
You say bigger, but how much bigger is bigger?
Can you put those in some practical terms for me?
Yeah, we're not just talking CPU or memory.
What we're really talking about is what is the work.
I can do 100,000 transactions,
just me, a second.
Well, that's great, but I can put my containers anywhere in the world.
So, for example, I can move closer to where the people are located.
How's that work out for you, Mainframe?
I'll stay in the data center because I need to be there,
but I can be the back-end processing to your front-end localization and so we can work together.
So that's kind of a smarter architecture
that takes advantage of having a centralized location for key data, but bringing the compute capacity closer.
Absolutely.
Sounds fun.
Okay, so let's look at the next one, which is consistency.
So again, I scale horizontally when I'm using databases to add additional performance capacity.
How does that play out for you, Mainframe?
You can guess.
I just get bigger.
I'm seeing a pattern here so far.
Absolutely.
You either have to shard or duplicate your data.
But in my world, I just keep getting bigger.
And let me give you an example for that.
So let's say I'm an inventory system.
I need an always consistent version of my inventory for my whole organization.
But I might want to copy out in the local store.
That local store copy can represent only that small amount of data of that store.
And it's okay that it may not be consistent with the whole world
because it represents that store and it'll get pushed updates from the rest of the big database in my system.
Okay, I see that, how that makes sense.
But aren't there cases where duplication actually is the right choice?
Yeah, there are cases where data doesn't matter in the same way.
We think about bank account balances, inventory, it really matters.
But social media? Okay, you can put that local because if it's not always consistent, it doesn't matter.
Or your shopping cart.
Those kinds of things might sit better locally near the user and then whenever they replicate back, it's okay.
It doesn't matter that it's not always consistent.
You have to look at your data.
Does consistency matter?
If it does, large/scale up.
If it doesn't, scaling out works.
So there's cases for eventual consistency and
where it's required, where maybe like an eventual 200 milliseconds is not going to be the end of the world?
Yes.
Fair enough. Okay, so we come to our final topic, tools.
Now come on now, developers, they love me!
All the cool tools hang out with me.
How's life in the REXX/JCL land for mainframe?
I can use all the same cool tools. I can use the same IDE. I, with my COBOL or REXX or any other traditional mainframe language.
And I can use those modern languages too.
So for my world, I've got them all.
And guess what?
I've got a pipeline too.
And I can use your pipeline, the exact same pipeline with a version of the build tools and deploy tools.
So it's all exactly the same from the developer's perspective.
So you're saying we have one pipeline of which part of it belongs to those working on mainframe,
part of it belongs to those working on container. And that's where we meet in the middle?
Absolutely.
But they're the same tools.
So if you want to work on Java one day and COBOL the next--yeah, you can still work on COBOL.
It would be in the same tools, same IDE and same pipeline.
Cool.
Well, thanks, Mainframe, but you get the last word.
What do you want to have as our take away for this?
Well, it's really important to think about the fact that they work better together, containers and mainframe.
Use this concept of fit-for-purpose.
Run the workload where it belongs and let the developers use all the tools they want and deploy it as part of the pipeline to the right place.
Awesome.
Thanks a lot, Mainframe.
And for those who are watching, please before you leave, don't forget to hit like and subscribe.