Before we start the actual post, today is the blog’s 1st birthday! <3 (Our first post.) Thanks to anyone who has been reading, or anyone who will read in the future. We blog because we love it, and we appreciate…well, everything related to it.
Last month, we spoke at Tech Leader Summit and ArchConf, which are conferences from the No Fluff Just Stuff tour. We also spoke this summer at UberConf, which is on the same tour. We had an AMAZING time, and we wanted to record and share some of it for posterity.
At that time the disciples came to Jesus and asked, “Who, then, is the greatest in the kingdom of heaven?”
He called a little child to him, and placed the child among them. And he said: “Truly I tell you, unless you change and become like little children, you will never enter the kingdom of heaven. Therefore, whoever takes the lowly position of this child is the greatest in the kingdom of heaven. And whoever welcomes one such child in my name welcomes me.” (Matthew 18:1-5)
Children
lolz
We were talking about this Bible verse, because we do that thanks to the magic of an app that spits out a Bible verse every day. Laine mentioned how this seemed legit, because children really are interesting and uncommon in their faith.
“That’s why kids are curious, and why they accept new information so easily. They don’t assume they’re right about…much.”
– Laine
And…children are pretty flexible. It’s true. They’re very sure about the world, but also they approach it knowing that they probably don’t understand it. Their only job is to learn, for at least the first 14-16 years. And since they change almost daily, they learn how to adapt simply in order to…wake up every day. This has the effect of them being very sure about the world – until something tells them to change.
Adults
“Adults go all hear-no-evil because their houses of cards are confused by new input.”
– Laine again
Adults build houses of cards based on the things they think keep them safe. Layer upon layer of flimsy, and foundations built on shifting sand. These houses of cards, despite being wobbly by nature, are rigid. They have to be held perfectly still, because if you even breathe too hard on a house of cards…the whole thing topples. So adults hold their breath, and they by and large tread lightly. People with house-of-cards models hate hearing things that disagree with their view of the world – which is unfortunate, because reality, and God, very often throw new information at us. Often this information is beautiful, if only we can manage to avoid running away from it long enough to allow it in.
God is going to force change, and growth. Not a single one of us is perfect or fully formed, and we do stupid things that hurt ourselves in the name of self-protection. God protects us from ourselves, and that means sometimes we have to change even if we don’t want to – and that means that not a single one of us can actually stay perfectly still or hold our breath for any length of time.
We can fight against the wind or we can go where it takes us – but either way, a house of cards won’t survive.
Conflict, too, is necessary for change and growth. It’s necessary for the growth of each of us, and it’s also necessary for the growth of the relationships we try to stumble through while we lug our baggage along behind us. The houses of cards that represent our relationships are even more elaborate – and even more fragile.
Adapt
At some point, children grow up. They start to get their own scars and their own baggage, and they start building models of reality that don’t hurt as much as actual reality. The begin to build the house of cards, and they lose all of the flex that makes them able to have the kind of faith that can bend without collapsing at the slightest breeze.
You gotta’ keep some flex in your models.
Some things are certain. But really, “certain” just means it takes a whole lot to convince someone otherwise. God, for example, exists. He exists, and he is good, and he cares about each of us individually. That’s certain. But…actually, that just means that we’re really really sure, because there’s a lot of evidence and we’ve been over that ground a lot.
Other things, like “OpenShift is the best Kubernetes platform,” eh. Maybe we should be open to new information about that, and maybe not being certain about it would be beneficial. Maybe it’s the best for some people, or even most people – and maybe it doesn’t work at all sometimes.
You have to have a foundation that’s built on things that are real – not cards precariously stacked. And…on top of that foundation, you gotta’ keep some flex in your models. You gotta’ be open to being wrong. You have to allow for wind, and breath, and change. The alternative is ignoring reality, and ignoring God, and that’s a dangerous path to go down.
Moving stuff between Kubernetes clusters can be a pain in the butt. You have to do this when:
Migrating between container platforms, such as EKS -> AKS
Upgrading clusters when you want to upgrade in parallel (move everything from old to new) as opposed to upgrading in-place (update one cluster from old to new). This would be something like what we’ll talk about in a minute, going from OpenShift 3.x to OpenShift 4.x
Moving work/applications between clusters, e.g. two clusters in different datacenters
Migrating work between clusters requires some thought and planning, and good solid processes. Specifically, the migration from OpenShift 3.x to OpenShift 4.x requires a parallel upgrade, because there is no in-place upgrade available for all of the new goodies in RHEL CoreOS (the underlying infrastructure of the cluster). OpenShift 4.2 released recently, so we thought it would be good timing to put our migration thoughts down here. However, the advice below is generally good for any Kubernetes cluster parallel upgrade or other migration.
One of the most crucial metrics of success for an enterprise application platform is if the platform can protect: a) the applications running on it, and b) itself (and its underlying infrastructure). All threats to an application platform eventually come from something within that platform – an application can be hacked, and then it attacks other applications; or there could be a privilege escalation attack going after the underlying host infrastructure; or an application can accidentally hoard platform resources, choking out other apps from being able to run.
We work with a lot of people who are implementing Continuous Delivery. We see that when various bumps and boulders get out of the way of delivering software stably and rapidly, there’s a strong push to go very very fast. When this happens, there are often barricades put up in the name of security – because traditionally speed and security have been considered enemies. Traditional enterprise IT security would say, you can’t possibly go fast in a safe way,
There is a dream that lives in IT – it is the dream of the easy button. Push one button (or even a couple of buttons, we’re flexible!) and get immediate value. Everyone wants these easy buttons, and every software sales company wants to sell these easy buttons.
We’ve talked previously about how developers drive organizational success: they deliver the applications by which companies deliver their competitive advantages. Because they are a way for companies to deliver products to customers, those delivered applications are critically valuable. Application development is a lot like extracting gold – it creates value out of raw resources.
Application development is a lot like extracting gold – it creates value out of raw resources.
Gold, wealth, needs to have some amount of protection.
We talked in a previous post about neat stuff that was coming up in OpenShift. We wanted to follow up now that more information is available and 4.1 is GA and quickly break down some of the neatest stuff.
OpenShift 4 is the major version that will bring Kubernetes to being the standard platform: it provides features that let the majority of enterprises build and run the majority of their applications on an open, agile, future-ready platform.
OpenShift 4 crosses the chasm from early adopters to the standard platform for Kubernetes.
Istio (Service Mesh)
What is it: Networking upgrade for OpenShift Applications
Big Talking Point: OpenShift Service Mesh makes managing all of the services you’re building visual and clear Business Use Case: Enterprises looking to get visibility into their microservices, AppDynamics and Dynatrace customers.
Red Hat Code Ready
What is it: Containerized Application Development Environment. Tagline is “cloud-native development.”
Key Features:
Single-Click Modern IDE
Tight integration with OpenShift
Debugging containers on OpenShift is a nice experience
Business Use Case: Enterprises with poor developer IDES will appreciate CodeReady.
Competitors: IntelliJ and VSCode
FaaS
What is it: FaaS/Serverless is an even easier, and more restricted architecture than containers or PaaS.
Serverless is an alternative to containers. Applications that would be a good fit in a simple container are an easy fit for serverless.
Knative
What is it: Kubernetes-based serverless “Application Easy Button” – just write code, forget about packaging. We talked about it in more detail here.
Key Features:
An open standard for serverless.
Build, scale, and trigger applications automatically Big Talking Point: Openshift 4’s Knative solution makes building, running, scaling, and starting applications even simpler. Business Use Case: Enterprises looking to turn their long-running (overnight) batch streams into real-time integrations should use Knative and AMQ streams on OCP
Competitors: AWS Lambda, Azure Serverless, Google Cloud Functions. K-Native provides this functionality without vendor lock-in from a single cloud provider.
The Operator Framework
What is it: intelligent automation that can manage an application by defining proper state and automate complicated application operations that using best practices.
Key Features:
Kubernetes-native application management
Choice of automation: Go, Ansible, Helm
Packaged with a Kubernetes application
Business Use Case: managing stateful applications like Kafka and databases, however new use cases show up all the time, such as managing the kubernetes cluster itself (Machine Operators)
Big Talking Point: Operators make managing complex applications in Kubernetes much easier, turning industry-standard practices into automation.
KubeVirt
What is it: Kubernetes-native virtualization. Run VMs on Kubernetes. Basically, this is VMWare for K8s.
Manage complicated, hard-to-containerize applications alongside the containerized applications that integrate with them
Business Use Case: ditch proprietary VM platforms and run you containers and VMs on one standard, open platform
What else is neat in OpenShift 4
Cluster Admin is so much easier:
Fully-automated cluster spin-up: AWS install in less than an hour
Push-button updates
Immutable Infrastructure: RHEL CoreOS are immutable and extremely strong from a security standpoint
Nodes as pets: automatic scaling and healing
Cluster can automatically add nodes as load increases
Stuff We’d Like to Get Deeper With
Theres’s a lot more coming with OpenShift that we’d like to get hands-on time with:
Windows Containers
OpenShift Cluster Management at cloud.redhat.com
Universal Base Image: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
Quay and Clair
OpenShift: Still the Best at What it Always was Best At
OpenShift is still the platform we know and love.
Secure Kubernetes: SELinux preventing security problems like the runc vulnerability
Fully backed by Red hat, which will be even more stable and well-funded after the IBM acquisition
Enabling Digital Transformation: Containers are still the best way to transform IT, and Kubernetes is the best way to enable DevOps and Continuous Delivery
Open Hybrid Strategy: Vendor Lock-in sucks. Open standards and great partnerships.
So you’re a Java/C++/web developer and you’ve heard about all of these “cloud native” technologies, and containers, and you’re wondering “excuse me, what is a Kubernetes please, and why do I care?”
…or maybe you’re a general technologist – idly curious enough to wonder what all the fuss is about but not super interested in digging into the guts of the thing.
…or maybe you tend to understand technology more big-picture than detail and you wish someone would just tl;dr it for you.
Well…welcome to the first of our Technology TLDR posts! Kubernetes, you’re up.
So you’re a Java/C++/web developer and you’ve heard about all of these “cloud native” technologies, and containers, and you’re wondering “excuse me, what is a Kubernetes please, and why do I care?”