This interview with Mark Lamourine is the second in a series of interviews with the engineers and community members working, often anonymously, behind the scenes on the OpenShift Origin Platform-as-a-Service Project. Although you see them on IRC in the OpenShift Dev room, you pepper them with questions in the forums, and they hit on you for feedback, it's not often they surface and come up for air. So we're really pleased that we've managed to coerce a number of them (including Mark) to speak at upcoming OpenShift Origin Community Days and hope you'll come and meet them too!
Mark Lamourine, is a long-time OpenShift Origin contributor, author of the Thor OpenShift Setup tasks for EC2, the guy who made DNS sing on OpenShift , a Red Hat engineer, and generally all around wonderful community member. I had the pleasure of asking Mark a few questions the other day as I was roping him into giving a lightening talk on Thor and OpenShift at the upcoming OpenShift Origin Community Day in Boston.
First, a bit of history on Mark
Mark was one of the first four or five developers on OpenShift Origin, along with Mike McGrath and Matt Hicks. With 30 years of experience as sysadmin/software developer/toolsmith, he was the guy with the host level systems architecture background that left the others free to go do the "cool up-front stuff".
Things move fast and code constantly changes as the OpenShift code gets tweaked, re-factored, and re-written, so a lot of his original work has been replaced as new developers have arrived, and as new features have evolved. The most persistent parts with his name on them are the DNS plugins (bind, nsupdate, route53). He also did a lot of work to create self-contained dynamic DNS setups to simulate real services.
Running DNS in a vacuum isn't easy, but Mark made it work for testing and live CDs. He has also written a fair amount of documentation on how DNS works within OpenShift. OpenShift's DNS services perform so reliably that most people, even admins, rarely have to think about the details. Mark says that the dynamic DNS in Openshift still tends to bend people's minds a bit.
Mark also did a lot of the original node containment work, and although much of that code has been replaced as well, the architectural design still remains. Support for cgroups, pam_limits and disk quotas were all implemented as part of this effort. While Dan Walsh did the lion's share of the SElinux work, Mark also contributed a few policy changes, allowing logroller to run behind apache.
While Mark claims that he can't really keep up with the pace of development of the OpenShift service and feature set, he still manages to dabble here and there whenever there is something he can contribute. Currently, he's putting more focus on installation work. As he puts it, "OpenShift is a moderately complex system with a number of parts or interactions that are (ideally) hidden from the app developers, but which are important for the ops and admin folks to be aware of". Making sure these folks have all the knowledge and tools that they require are his most important goals these days.
The Interview
What makes OpenShift Origin great in your humble opinion?
OpenShift challenges the "give them a VM" mentality to *aaS. It maintains it's light weight by using new and old technologies to create a new twist on good old-fashioned shared-host login systems.
OpenShift really has no "secret sauce" which may inhibit re-implementation, or lead to system lock-in. This also means that OpenShift applications can be made portable (at least theoretically) between a Hosted style external cloud and an on-premise internal cloud. Non-locality (the fact that a user doesn't need to care where her app is) is one of the pillars of cloud services.
Really, the goal of OpenShift is to let developers be developers and not SysAdmins. Prior to something like OpenShift, development environments really had two modes of operation: "wild west", or "restrict everything". The first option makes consistency hard, and frustrates deployment and operations teams who have to reconcile all of the differing requirements that come from developers building their own work spaces. The second option limits productivity, and fosters frustration for the development teams themselves.
OpenShift offers the flexibility to allow each developer to create their own work space, while giving the managers some control and insight into the moving pieces of their apps. The developers can work in an environment which closely mimics the eventual deployment space, so there are fewer gotchas when rolling a release from dev, to test, to staging, and finally on to production.
What makes OpenShift Origin different from other PaaSes?
OpenShift is, I think, the only offering now that promises 100% portability of apps from an external hosted style service to an internal service and back. It's strength is that it is entirely built on and with available open source components. Some people are afraid of bitwise copy cats, but I'm really not. I can't see a reason why someone who wanted a professional enterprise grade service would go with a second-rate cookie cutter.
What do you see as most important/interesting thing on the roadmap for OpenShift Origin?
My perspective is of the system administrator and operator. I honestly don't pay much attention to the published roadmap. The features that interest me are the ones that make deployment and operations easier or better, and they don't generally rank very high on the feature list.
A big recently-released feature that is important is the version 2 cartridge specification. When we first created OpenShift, we were just concentrating on making things work and on the functions we needed to do it. Over time it became clear that the boundaries of what went in a cartridge (really, in developer space) and what supports it in the operating system (ops space) were messy. The V2 cartridges formalize the boundaries between the system, the cartridge, and the application. This will make security tighter by exposing and controlling interaction between the OS and the cartridges. It will make cartridge development easier by providing the cartridge authors with a set of resources and operations that they can count on, without having to dig so much for: "how do I do that now?". It will make the application development experience better because now the cartridge developers have a specific set of environmental conditions which must be provided to the running application. I hope it will also make app migration (moving an app from one node to another within a service or outside) easier to define and implement.
I'd love to see the same kind of definition and decoupling happen in the broker-node communication as well. This would allow people to implement alternate brokers or to simulate a complete broker if needed. It would possibly allow for porting the node behaviors to other systems as well.
I'm fairly certain there are people working on additional storage options. Removing the restriction to local storage for apps would be a big thing.
Currently all the nodes in a system have to have the same cartridges on them. The location selection logic doesn't yet allow for nodes dedicated to one kind of app type, say Java or Python/Django, or for different nodes to offer different versions of a cartridge. I think that this current restriction is artificial, and that at some point we'll have address it and then upgrading from one version to the next would be the same as cloning or migrating it to run under a new cartridge version on a different node. Which I believe is a simpler more elegant solution than the current process.
Who should come to OpenShift Origin Community Day?
Again, I'm a system administrator - So I'd like to see SysAdmins there. Much of the focus for promotion has been on the application developers and users, and while OpenShift really is for them, the SysAdmins are the ones who are going to make it all work and then hopefully fade into the background as the developers get on with making great software. The SysAdmins need to understand the needs and goals of their customers, and the customers need to understand the limitations and challenges that the operations team face. It's a DevOps-ish thing, and although I dislike the term, I've been among the group of people who practice it informally for a very long time.
So what are you waiting for? Sign-up for OpenShift Origin Community Day now!
- Boston, MA: http://openshiftboston.eventbrite.com
- Mountain View, California: http://openshiftmtview.eventbrite.com
If you want to hear more from Mark, he publishes an irregular blog series called "OpenShift Under the Hood" at https://cloud-mechanic.blogspot.com.
You can find Mark on github here: https://github.com/markllama
