How can we preserve developers’ freedom? And other questions with amazee.io

This is the first of a monthly Q&A session we’ll be hosting with amazee.io’s expert team. Today’s topic will be about preserving developer freedom and discussing the best ways that developers can use their time. What does this look like? What resources should we be providing developers to help them? We will answer all of this- and more. 

Bastian Widmer is amazee.io’s Platform Lead, and they’ve been working in IT, system engineering, and customer support for more than 15 years. They’re familiar with all things DevOps, and in recent years, they have noticed a significant change in the developers’ landscape.

Q. Bastian, in your opinion - what is the landscape for developers right now? What do they worry about, and why are teams struggling so hard to get things done? 

The landscape of software development has gotten quite a bit more complex in the past few years. Application developers need to keep up to date with recent trends in the space as well as we’ve seen a rise in complexity when it comes to actually building applications (e.g. more and more applications moved from being monolithic to using dependency management). This adds a lot of flexibility, but it also comes with the added tax of actually needing to take care of the dependencies your application consumes.

In my opinion, we learned a lot from the DevOps movement in recent years, and it helped to bring the worlds of Development and Operations closer together. We got to a point where Developers have been enabled to run complex applications together with the involvement of Operations as a joint team. Now, as things start to regulate and technology matures, there’s a bit of a drift again. But I don't necessarily see this as a bad thing. Platform Engineering teams can enable teams of developers to run their applications at scale, I believe, as long as there’s not again a full disconnect between the two worlds that we should strive towards collaboration.

Another thing I see is that there are two fundamentally different ways of how websites and applications are run and developed. There are still a lot of “one-shot projects” that are built and then sit around rather unmaintained. This works for a while, but the tooth of time will break those applications at some point. 

Luckily, a lot of the web development world understands that web applications are never really finished and need work, optimization, and regular care. When working with those teams I see that the application is put into the center of attention, and things that might not be perfect at first will be optimized within the lifespan of the application.

Q. How do operations and infrastructure cut into developers’ time? Why do those things take so long? 

Operations, at first sight, look like an easy problem to solve. You need infrastructure and you provision it somewhere and run it. This usually works for small one-off things, but operating infrastructure has a lot of implications. Do you take care of security patches and regular updates? Is the infrastructure monitored? Are backups created regularly and their restore tested? How does scaling work and what protocols are in place if something goes wrong e.g. a DDoS Attack against the service? And what happens when the issues come up in the dead of the night at 3 a.m.? 

While infrastructure and operations look like a simple task - It’s something that shouldn't be considered that way, because it’s not easy and can take a lot of time. 

Q. Many organizations want to find resources to help their developers, but they don’t know where to start. In an ideal world, what tools and resources would be ideal for developers and why? 

That’s not an easy question to answer. I’d like to approach the question from a few steps away.

I’d first try to find out what the organizational needs are e.g what software you need to run and what the business needs there are to cover. Then from there find out what and how the organization develops and runs things.

For example, amazee.io started out from the need to be able to run PHP-based applications scalable and reliable in the cloud. This is why Lagoon was born. We quickly saw that the complexity of Kubernetes just adds another burden onto the shoulders of developers hence we try to abstract that away and take care of the whole infrastructure behind the scenes. Sure having Kubernetes knowledge helps but we don’t see it as a necessity when it comes to using Lagoon.

But in general, when the needs are clear, seek out conferences and articles that explain how other companies with similar needs are working - you can take inspiration from that. It’s one of the best ways to understand possible solutions for your problem. Seeing how other teams solve similar problems can give you a lot of pointers and input on how you can and should structure your development workflows.

Michael Schmid, amazee.io’s co-founder and Head of Technology, recognizes that something has to change for developers all over the world - or high rates of burnout may cause teams to keep losing valuable people. Unhappy, understaffed teams aren’t going to lead to much creativity or productivity - and it’s time to do something about it.

Q. Demand for developers is higher now than it’s been in years, and many understaffed teams are experiencing burnout. If an organization is noticing this on their own teams, what can they do to help developers and engineering teams? 

Firstly, talk to your team openly and fully transparently. Communication matters here, because no one knows what resources are needed better than the struggling team itself. Ask your team what they’re struggling with, and see if they have any tools currently in mind to help them to overcome the current situation. 

If not, research some options and discuss them with the team. A helpful way to approach this can be making small changes and gradual improvements instead of huge steps to try and overhaul something completely right away. Focus on finding realistic ways to make small improvements gradually, over time, because these will add up if you keep the process going. 

Q. If burned-out developers can agree on one thing, it’s that they need to see improved conditions at work to feel better about things. In your opinion, what are some conditions that make a lot of difference? 

First of all, I think that smaller teams may perform more efficiently and effectively than one large team, simply because communication is streamlined and everyone is working more closely together. So having those smaller, close-knit teams is a must. After that is set up, it’s really important to define clear goals and responsibilities for each small team so they know where to focus. They need to be able to work independently and make their own decisions - for example, what type of tools they want to use. 

Next, consider open source tools, because those really help teams to improve the tools they’re using when this is necessary. Being able to contribute actively and be involved with the tool you’re using can make a lot of difference, and being able to look under the hood and truly understand the tool is a massive advantage.

Lastly, I would personally recommend allowing for remote work and flexible schedules. This helps people fit life and work both in, which is important, and often, people are much more focused during their working time when they are in control of it.

Q. Let’s tie the concept of ZeroOps to burnout. How can ZeroOps platforms and methodologies serve as a life raft for developers who are burned out, and teams who are struggling? 

To me, it’s actually really simple. Developers like to develop applications, right? That’s why they became developers in the first place. If they had wanted to run infrastructure all day or work with operations, they would have been infrastructure or operations people. But they didn’t - what they want is to develop applications, and anything that isn’t that is probably frustrating to them. 

ZeroOps is a cool methodology because it frees the development teams up to worry about operations - they don't need to worry about cluster sizing, maintenance, performance, monitoring, or the security of clusters. Providing them with this capability is priceless to a team struggling with bandwidth. ZeroOps really allows developers again to focus on creating outstanding software and applications.  

We actually just wrote a blog about what ZeroOps is and why it’s so valuable. Check it out here if you’re interested in learning more.

Have a question for our next Q&A blog session? Message us on LinkedIn or Twitter and we’ll work it into November’s session.