iQoncept - Fotolia

Manage Learn to apply best practices and optimize your operations.

Explore DevOps without software containers

Software containers just might not be the solution to your DevOps team problem. Expert Bert Jan Schrijver reimagines continuous delivery.

Bert Jan Schrijver, a software craftsman at custom Java software developer JPoint in the Netherlands and speaker at the JavaOne conference, answered SearchSoftwareQuality's questions about DevOps and why sometimes it makes sense to ignore conventional wisdom. He also discussed his JavaOne presentation that questions the need for software containers.

What causes DevOps teams to get bogged down?

Bert Jan Schrijver: A DevOps team can't be dependent on external help. If they are, they can't be responsible for production environments. How can you take responsibility for something you're not able to fix?

When teams get bogged down, what needs to change?

Schrijver: The teams need to be able to work on a self-service basis. It's all right when there are differences between teams. It's not all right when a team is dependent on external help.

You talk about building a completely new team while still producing new software. How is that possible?

Schrijver: We built a new team to lead the shift of our organization to DevOps so that the existing teams could move to the new way of working at their own pace. New projects moved to the new stack faster than older projects that were already in production.

Is there ever a danger of doing too much testing?

Schrijver: Doing too much manual testing is always a danger since it slows you down. Doing too much automated testing can also be an issue: The tests take too much time to run -- so your feedback loop gets longer -- and too much time to maintain. Find a way to optimize the number of tests, the balance between type of tests -- unit, integration, end-to-end -- and the running time of tests.

Why or how does the open source tool Jenkins play such a critical role in development?

It's not all right when a team is dependent on external help.
Bert Jan Schrijversoftware craftsman, JPoint

Schrijver: We chose to put Jenkins at the center of our delivery process. Since Jenkins is such a versatile system, it enables us to perform all steps in a product lifecycle -- build, test, release, deploy, etcetera -- in a single place, so we can create automated pipelines by chaining these steps together.

You aren't particularly excited about using software containers. Why is Amazon Elastic Compute Cloud (EC2) a better choice for companies?

Schrijver: Don't get me wrong: I love software containers. But they're not the solution for everything and can even complicate things. Since we're running on AWS, hardware and virtual servers are [commodities] to us. We like having mutable servers so we can quickly perform minor changes on a running system. And we don't need to run multiple services on a single machine. When that's the
case, machine is over dimensioned. By using EC2, we don't need to worry about port mapping and security between containers. We use the EC2 instance as our container.

Is there a scenario where containers might make sense?

Schrijver:  Yes, I think containers are excellent when you're spinning up and destroying loads and loads of servers in a very short timespan. Containers are very lightweight and start really fast. In our situation, we're spinning up and destroying environments one to a few times a day. In that case, it's fine to wait a little longer -- around five minutes -- before a newly created system is up-and-running.

Do specialists not have a role on your team? Can you explain why it's important that everyone can do everything?

Schrijver: We do recognize specialisms. For example, our teams have front-end developers, back-end developers and testers. But regarding repeating operations tasks like deployments and viewing logs, it is important that every team member can do this. This way, you won't have islands in your team that prevent progress when someone is absent.

Next Steps

Build a DevOps environment with containers

How to track the success of your DevOps effort

The benefits of continuous delivery

This was last published in November 2015

Dig Deeper on Software Development Fundamentals

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Are software containers slowing down your operation?
Cancel
I don't think you need Containers to get your first case of DevOps, but there certainly is more than a few places where containers provide not just alot of value... they solve certain problems.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close