Red Hat Summit / Dev Nation 2015 fell pretty well in line with the theme everything old is new again. The three main themes repeated again and again were containers, DevOps and microservices. I think each of these three important trends is building on a well-established base of solid practice and technology.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The idea of containers has been around for a long time. Container-based virtualization, virtual containers, or just plain ‘containers’ for short, build on pre-existing virtualization technologies. At the Red Hat Summit three years ago I had the pleasure of speaking with James Strachan, who was talking about how cool the containers in Karaf could be in terms of really easing the deployment of application artifacts.
So Docker’s containers aren’t coming out of the blue like one might think they are. It’s evolution over revolution. But that’s not to say that containers haven’t come a long way or that they aren’t going to go even further in the very near future.
Docker has made container-based virtualization very available to a wide range of developers who are pushing the bounds of what’s possible in terms of application deployment. Containers are definitely easing the pain of managing multiple development environments. And projects like the soon to be released Kubernetes – Developed largely by Google, but with a lot of help from the open source community, including Red Hat – are going to push those boundaries even further.
Kubernetes adds orchestration similar to Docker’s Swarm tools. Google, Docker, and other major virtualization players like Microsoft have gotten behind the Open Container Project to create standards that ensure containerization tools stay open and interactive.
At the same time, architecture trends today are favoring microservices. Microservices are the sleek, sexy name SOA goes by now. There are some differences between the use of microservices and service-oriented architecture, though. For one thing, a better understanding of automation, virtualization, and APIs means more organizations are ready to shift toward services. A better understanding of how to test means more organizations are ready to test services. In addition, the progress of Agile and DevOps means more organizations have undergone the cultural change needed to be ready for building and maintaining services. So my take is that microservices are what happen when an enterprise is really ready for SOA.
The third part of the triad is DevOps. DevOps seems like the simple concept of Development and Operations working together as a team. However, that simple definition is not necessarily shared by everyone. Like many terms in IT, DevOps means different things to different people. For many organizations, DevOps is a new department that sits between the developers and the operations folks and smooths out the road between them. To others, DevOps means the developers get the same late night phone calls the operations folk get (which naturally encourages them to write code that does not break down in the middle of the night). For others, DevOps seems to be an extra set of steps that have to be done in addition to the existing development and operations (which continue in the same quasi-effective way they always did).
The most effective view of DevOps, I think, is an extension of Agile to bring operations into the greater development team. This is continuing a job that Agile started. By breaking down the gates, Agile brought developers and software testers together as a unified team. But operations somehow got forgotten and left out in the cold. Now, operations gets to share in the planning and responsibility. They get to share in the glory when the team makes new innovations and they don’t have to shoulder all the blame when things go awry.