Can we stop pretending everything is going to run in containers?
Nick Chase - July 31, 2019
Go to any technical conference and you'll come to a pretty quick conclusion that programmers don't care about fashion.
Or do they?
Sure, programmers are perhaps less likely to have a history of wearing parachute pants, but they do follow a very different kind of fashion: technology fashions.
I'm not talking about wearables here. I'm talking about chasing the new "hot" technology. In the early 1990's it was Object Oriented Programming. In the late 1990's it was the World Wide Web. Then it was Virtual Machines. Then Cloud Computing. Now it's containers, and orchestrating them with Kubernetes.
At London’s OpenInfra Days UK 2019, Canonical's Mark Shuttleworth complained that “it’s become trendy to say: ‘I’m skipping OpenStack and going straight to Kubernetes.’ It’s like skipping salad and going straight to steam – they both solve different problems.”
He's right -- but he's also missing the point.
I'm more concerned about this "all-or-nothing" mindset that comes up every time there's a "new hotness".
Yes, there is definitely a benefit in building new applications to take advantage of containers. We can even make a good case for retooling development practices to take advantage of containers, and, in some circumstances, for containerizing existing applications.
Where I start to get a little concerned, though, is when companies think that they have to "stop the presses" and not do anything until they can move everything to containers.
This "analysis paralysis" isn't just harmful. It's unnecessary.
NEVER.
Why? Well, think about it for a minute. Sure, VMs are still around, but you can probably convince yourself it's just a matter of time until they're absorbed into the container ecosystem.
But you're wrong.
How do I know? I know because half a century after the first personal computers arrived on the scene, 92 of the top 100 banks -- and 71% of companies in the Fortune 500 -- are still running COBOL on mainframes.
If 97% of ATM swipes still use COBOL, how long do you think those Java and C++ apps that run HR and accounting are going to stick around?
Don't believe me?
Keep your eye on "serverless" computing. This natural evolution of the microservices paradigm is moving developers beyond thinking about the infrastructure at all, and is just the most likely "next thing" -- it's far from the only contender.
Containers are certainly the most logical way to develop right now, but eventually, something else -- something we haven't even imagined yet -- will replace them.
Well, if we're smart, we accept it and adjust, and we make sure that whatever comes next, we're ready for it. That means we need to:
Or do they?
Sure, programmers are perhaps less likely to have a history of wearing parachute pants, but they do follow a very different kind of fashion: technology fashions.
I'm not talking about wearables here. I'm talking about chasing the new "hot" technology. In the early 1990's it was Object Oriented Programming. In the late 1990's it was the World Wide Web. Then it was Virtual Machines. Then Cloud Computing. Now it's containers, and orchestrating them with Kubernetes.
At London’s OpenInfra Days UK 2019, Canonical's Mark Shuttleworth complained that “it’s become trendy to say: ‘I’m skipping OpenStack and going straight to Kubernetes.’ It’s like skipping salad and going straight to steam – they both solve different problems.”
He's right -- but he's also missing the point.
What's the big deal?
I'm not asking what the big deal is with containers. Containers are definitely an improvement over previous methods for creating and distributing software, and like the "hot" technologies before them, they're going to be around for a good, long time.I'm more concerned about this "all-or-nothing" mindset that comes up every time there's a "new hotness".
Yes, there is definitely a benefit in building new applications to take advantage of containers. We can even make a good case for retooling development practices to take advantage of containers, and, in some circumstances, for containerizing existing applications.
Where I start to get a little concerned, though, is when companies think that they have to "stop the presses" and not do anything until they can move everything to containers.
This "analysis paralysis" isn't just harmful. It's unnecessary.
Containers aren't going to completely take over
The fact is that while containers definitely have benefits, there is never going to be a time when every developer is using them.NEVER.
Why? Well, think about it for a minute. Sure, VMs are still around, but you can probably convince yourself it's just a matter of time until they're absorbed into the container ecosystem.
But you're wrong.
How do I know? I know because half a century after the first personal computers arrived on the scene, 92 of the top 100 banks -- and 71% of companies in the Fortune 500 -- are still running COBOL on mainframes.
If 97% of ATM swipes still use COBOL, how long do you think those Java and C++ apps that run HR and accounting are going to stick around?
They're not even the end of the line
While it's certainly true that existing applications will continue to migrate towards containers, long before the takeover is complete, something else is going to come along and replace containers themselves.Don't believe me?
Keep your eye on "serverless" computing. This natural evolution of the microservices paradigm is moving developers beyond thinking about the infrastructure at all, and is just the most likely "next thing" -- it's far from the only contender.
Containers are certainly the most logical way to develop right now, but eventually, something else -- something we haven't even imagined yet -- will replace them.
So what do we do about it?
OK, so if we are going to stop pretending that there will be a point where all software runs in containers, what do we do about it?Well, if we're smart, we accept it and adjust, and we make sure that whatever comes next, we're ready for it. That means we need to:
- Design software that focuses on business problems instead of technology so the underlying infrastructure doesn't matter
- Build software in a way that's modular and flexible so that we can add on later
- Maintain a well-defined infrastructure so that if you need to change it later you can with less risk
- Accept the fact that we are going to deal with legacy systems for a long time to come, and figure out how to work them into what we're doing.
