iQoncept - Fotolia
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?
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.
Build a DevOps environment with containers
How to track the success of your DevOps effort
The benefits of continuous delivery