These executives answered questions from the audience regarding where application development is headed in the Red Hat space.

"How have you seen the world of enterprise application development evolving over the past couple of years?"

Little: "The biggest driver here is the fact we need to deliver more stuff more quickly. A lot of stuff we've been able to get away with as practitioners of software development - not taking the time to automate deployments and whatnot - you simply can't get away with anymore."

Mower: "Over the past couple of years we've seen a movement from developers to development teams. It's not about writing code but bringing value to the business. It's not controversial to say every company is a software company now. Over the past couple of years we've seen a shift to making fast, reliable code to deliver value to the business. Everyone decided containers are the atomic unit of execution - it doesn't matter if they're on premises, the cloud, bare metal, etc. Everyone's development strategy has containers - but the methodology and architecture is still up for debate."

Little added: "It's not about just a change in code, but a change in how we think about code. In order to help enact that, developers are looking at richer toolsets to assist in getting things out more quickly. The tooling that assists in this more agile or rapid release of apps is becoming just as important as the apps themselves."

Mower: "There's a definite move - and it could be considered rational or a fad or between - to take an app and break it up into microservices. We had this before with a service architecture. We're trying to do it in new and different ways and looking at an emphasis in how to get the teams to work better on that so different teams can work on different parts.

In theory it's been a great practice - such as Netflix or Etsy models - but comes with challenges too. More complexity leads to a whole new set of problems. We caution people about just jumping into microservices. There are plenty of viable reasons to do things in the monolithic way. If apps are already running and working, don't mess with something that's good. There's a whole new set of thinking around these things. We want to service all of them in a constructive way."

Little: "I mentioned agile earlier - one of the reasons we see people moving to microservices are to release apps not in 18 months but 18 days. By separating the monolith into independent services you can release them more quickly. An 18 day cycle might be great for Netflix but not BP or British Telecom. Maybe they can release every 3 months instead of 18 months now as a better cadence. There are better architectural practices and tooling. A service-oriented architecture can be another approach.

Microservices aren't for everyone. It really pushes a distributed system. Over the last 20 years evolutions in CPU power, cheaper machines and threaded languages have led to a more independent colocation of services. Today's generation of developers are really not used to distributed systems. People coming out of university might use their browser and a web server and that's it. 30 years ago we were really using distributed systems but we were pushing those principles into development practices then. That's the architecture microservices now and if you jump in without understanding that you'll end up in a world of pain. You'll have partial failures, recovery issues - you have to understand the positives and negatives."

"You're talking about application development - what attributes does a developer need?"

Bacon: "If you go a microservices route certainly distributed systems are important. My view is if you're going to be a developer you need to understand computer science if building anything larger than a toy application. Another reality today is that if you look at the number of programming languages and frameworks, you have a number of options and systems to build the pieces in whatever app makes the most sense. A developer needs to be a polyglot. They need the ability to learn new things every day. Every single day at Red Hat I hear about something I know nothing about. I have to learn. Collaborativity is much more important than 10 years ago."

Little: "We've moved wholesale to a DevOps mentality. Developers need to understand if they build it, they'd better test it and be on the line if it goes down. Customers shouldn't test code. If you don't test it, you might be the guy who is called at two a.m. to fix the issue. Whether you're coming out of university or training yourself, focus on unit testing, and know the difference between that and QA. There's lots of commonality in unit testing across programming languages. Developers can't assume there's a QA group to test this for them."

Mower: "My opinion is that a developer doesn't need to know much. There's a huge problem in that we rarify the ability to write code; some mystical magical thing only Ph.Ds can do. Many of the best developers didn't start out in development. One of our best evangelists was a theater manager. We do a disservice to the industry by laying out all these rules for what developers do. They need to be able to learn and start early. Requiring a four year degree doesn't help our industry. An apprentice program would work better - train as a vocation rather than a science. This stuff changes so much. Getting out university you need to understand some core stuff - distributed systems, computer science, but you have to learn on the job."

Little: "There are some fundamental things you need to know. My son is 14, and became a Java developer when he was 10 since we bought him a Minecraft license. If I told him how to write code, he would have closed up and gone into something else. He literally taught himself how to write Java, create mods, distribute to his friend, run on the cloud. Sometimes the mods didn't work and one of his friends would notify him and he'd fix them. So he taught himself about testing them before he gave them to his friends. He hasn't even gone to university yet but he knows how to mod Minecraft.

"How does Red Hat in its 'open message' reconcile that it's in the product business and product isn't about choice but about a fit to business cases?

Mower: There are a couple things about our vision for OpenShift.io. Customers tell us how much time and money they spend to integrate all their tools. We want them to have an option to not spend time and money and focus on creating software to make their business better. With OpenShift.io you have the option to start by not having to set up anything. We know some customers won't like that.

We will offer an extensibility model to integrate best of breed products such as tools in the toolchain which are core to the business. People will want to run on premise and not exclusively in the cloud. That being said, we think over time people will get sick of doing this. Customers I've talked to over the years say 'we'd rather have you do this for us.' As it becomes more of a commodity people won't want to extend it. The dev process will change; the things you integrate today will be less common going forward.

Little: "This isn't something peculiar to OpenShift.io. We've been asked by customers to be more prescriptive. Choice is great, but too much choice causes them to spin trying to figure out what to do. Focus on the one or two recommended ways. 15-20% will want to use the other ways and can still do that, but that's not what we recommend. Sometimes we'll remove things from projects when we create the product to simply."

"The elephant in the room with Dev is to do it faster and better, but people aren't thinking about security. What can the development community do to build security at the ground level?"

Bacon: "I can start with a couple of things. Certainly a data breach can wreck a company so there's some onus on developers. If you adopt a platform like OpenShift then you have a certain commonality that allows much more control over what goes in and what goes out. IT holds more promise to have control at the level of the platform and take it out of the hands of the developers.

Little: "People looking at security from the outset is not new to DevOps or microservices. Having security built in after is always something you do. A number of studies have shown open source software is more secure than closed source software. One study by the Mitre Corporation in 2006 looked at Microsoft SQL server vs MySQL and found 1000 times less bugs in a similar codebase in MySQL. Another similar study focused on Windows versus Linux. There are more eyes on open code so people can find bugs and apply fixes before these are exploited. It's not a magic wand, but we have the ability to leverage this advantage."

Mower: 'We're trying to tackle that problem and others head on. We are introducing a bayesian feature and a focus on open source packages to scan them in the wild. If there's a known vulnerability we can make recommendations for alternatives. The rabbit hole goes deep with things we can do with that type of technology. We can analyze code for vulnerabilities and abnormalities and provide recommendations to developers in real time."

Subscribe to TechRepublic's Open Source Weekly newsletter and get tips, tutorials, and commentary on the Linux OS and open source applications.

About Scott Matteson

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

Full Bio

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.