luchschen_shutter - Fotolia
If developers aren't talking about microservices, it's because they're talking about containers. As mobile and cloud application-development technology matures, the use of containers is becoming more commonplace. And why not? They offer easy platform portability and ensure that apps will perform consistently when moved from a test environment to production. Add power-of-process isolation to enhance security, and the technology becomes simply irresistible.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
At the recent Red Hat Summit in Boston, attended by more than 5,000 developers, Brian Gracely, director of product strategy for Red Hat's OpenShift container management platform, sat down for an exclusive interview with SearchCloudApplications.
To bring about digital transformation, it's been said we need to look at the concept of a composable container platform. Can you tell us what that's all about?
Brian Gracely: Platforms are there to help not only developers get their applications deployed faster, but also to help operations do it more smoothly. Platforms inherently have a certain amount of biases -- this is how you should do it, this will make you go faster. Early generations of platforms were too restrictive, didn't support enough languages, weren't standard enough.
We think Red Hat OpenShift is much more standards-based. It's based around container standards and it's based around orchestration standards like Kubernetes. But, it's also more modular in the sense of if you don't love the monitoring that we deliver out of the box, you have options to make changes without losing any capability. The end intention is I want to give you a great development experience that is easy to operate, but I want to give you a better level of flexibility in terms of what pieces you may want to put into a certain area -- storage networking, monitoring.
Was that inability to choose which tools you wanted to snap into a platform a technological limitation of the day or vendor posturing?
Gracely: Vendors want you to use their technology, but a lot of it was the early days before there was enough deployed for a standard to evolve. Some did evolve; Docker came out of a company that used to make a platform that was boiled down to a small piece of technology that became, sort of, a standard. It really was more of technology maturing and people deciding if they like it.
How are IT departments using containers like the OpenShift container platform to securely deploy applications across any cloud and reduce the time it takes to build, test and run new and existing applications?
Gracely: We do a lot of work within OpenShift. Security has always been, sort of, top of mind. It starts with that foundation of [Red Hat Enterprise Linux]. There's always been a foundation of security from a Red Hat perspective that we've embedded into the OpenShift platform so that when you deploy an application, the container is going to be secure [and] the platform communication, the inner communication between applications is going to be encrypted. We encrypt your security keys. We make sure that all of those things around permissions and authentication are built into the platform. When you have that secure platform, you can then run it in your own data center, run it on top of Azure, [Amazon Web Services] or Google.
How do a container platform, container management and platforms as a service help developers and operations teams gain greater visibility into business processes and, ideally, help drive profitability?
Gracely: One of the great things about containers is it's one of these first technologies where it's relevant to a developer. It gives you a standard way to package applications. It's also very relevant to the operations team because it's going to automate the underlying environments. It's going to help you scale those environments. What you now have is this commonality of language, which we didn't always have, you know, in the past. Talk about dev silos and ops silos.
Brian Gracelydirector of product strategy, Red Hat OpenShift
When the underlying infrastructure and developers have a common language, I can start with a business idea. I can build out a minimum viable product in experimentation. I can get that deployed quickly, all fully automated, and the business can see it pretty quickly, in a couple of weeks or a couple of days. We had a customer in the keynote presentation that said its mindset is to go from idea to execution and to the customer in a couple of days. Having this fast technology makes that visible and possible.
That's a serious problem for legacy thinkers.
Gracely: Legacy ways of thinking about planning are going to be a detriment in the future. People are going to have to evolve.
Cloud and mobile app release cycles have gone from years to days. It's 'ship it fast and fix it later.' What is the real impact of this inability to do comprehensive testing on cycles that short with the OpenShift container platform or others?
Gracely: End users are now used to this idea of doing updates all the time. The way we're addressing that, essentially, around OpenShift is with a Docker or Kubernetes project, we make sure to grab a cut of it at a certain given moment in time. We integrate those pieces, do a ton of that testing and the end result is that you're getting essentially stable tested software.
The next piece becomes, 'How do I update the app without taking it out of service?' That's where we're doing a ton of work around automation tools, like in Ansible and cloud forms, that are going to help you do rolling upgrades. People sometimes call them blue-green upgrades where you can upgrade a certain number of users, make sure it works [and] then bring the rest of it. There's a realization that if I just gave you the same software the way you did it before and I didn't make it easier, that wouldn't work. We've been making investments on both sides of that.
What is the single biggest mistake that developers make in using a container platform in the development phase of a project?
Gracely: We see developers using old legacy patterns and maybe not thinking about if there is a way to modernize it. I think the biggest struggle for containers and for developers [is] to focus on what the business is. Don't always get hung up in whatever the newest, shiniest thing is. There's lots going on in containers. There's lots going on in new development frameworks. Be good at the thing that's going to help you solve a business problem. Containers are pretty flexible for that.
Which container platform is the best fit?
Are composable applications a boon or bust?
Containers and clustering, a potent pair