In the past, I’ve been a member of software companies with a more traditional culture. The kind of culture that has the so called “walled gardens” of development and operations, working completely separate – one team to build, the other to maintain – to provide useful software products for businesses and consumers. I’ve seen firsthand the miscommunication that tends to happen and the resulting stress that arises in both teams.
I’ve spoken with other developers, especially those who are still stuck in that same culture, about adopting a DevOps mindset – one that helps both development and maintenance of apps go more smoothly and prevents stressful situations. Below, I’ve compiled a short list of Dos and Don’ts to help you make a smoother transition into a DevOps world.
1. Don’t lob code over to ops like a grenade
This is one of the top complaints I’ve heard from ops engineers and there isn’t another practice that breeds more resentment so quickly as this one. Lobbing code over sets up the expectation that ops is supposed to maintain code they haven’t seen before, and often times it comes without instruction. What better way to irk your ops team?
Do explain the app’s details and provide documentation
When a person is given the responsibility to do a task but isn’t provided the tools to accomplish the task, he or she is getting setup for failure. To avoid this from happening,
explain the details: what the app does and what it needs
provide ops with as much documentation as possible
Not only will it be greatly appreciated, but it will save time and provide the necessary elements to accomplish tasks and improve job performance.
2. Don’t expect that the deployment will be done for you
Ops may not know the code as intimately as you do. Yet, the assumption is that they do and can get it up and running without any issue.
Do get more involved with deploying the code you write
If your schedule allows it, immerse yourself in the deployment process for a day. Even shadowing a willing ops engineer for a short session will give you insight as to what they go through on a day-to-day basis, and it will allow you to become more familiar with the deployment tools – automation tools being especially important.
Once you gain understanding of the deployment processes and tools, you can design and implement the app in a way that makes it easier to deploy. Thus adding more value by increasing your skill set. All in all, it’s a huge step towards moving to a DevOps culture.
3. Don’t treat your app like it will be deployed in vacuum
Developing an app might seem fine when it has the resources to itself, but when it shares the resources among other apps or microservices, problems may arise. Designing the app knowing how it should function within the larger system is key to preventing these kind of issues, which can sometimes be frustrating to resolve.
Do design with infrastructure in mind
Apps in general are becoming smaller and smaller, working within a larger system. This is especially true for apps that utilize the cloud. When creating apps such as these, you should realize that the app will reside in a shared environment as part of a larger whole. As such, be aware of the resources the app needs to foresee potential problems once it’s working alongside other apps or microservices.
4. Don’t ignore the benefits of the cloud
Using cloud tools can be a huge benefit for developing an app that will reside in the cloud, especially those that allow ops engineers to help monitor the health of the system.
Do utilize cloud tools when appropriate
For example, if your ops engineers are familiar with many Amazon Web Services but don’t have much programming experience, having your app use RDS, DynamoDB or S3 will make it easy for them to interact with your persistent datastore. If the app needs to use an asynchronous queue as a messaging system, using SQS has a lot of visibility through the UI, so the ops engineers can see exactly what’s happening in the event of a problem.
5. Don’t skip writing application logs
Sounds like a no-brainer but it happens more than anyone likes to admit. When it’s crunch time, it can be easy to forget and tempting to cut this particular corner.
Do ensure that logs are sufficiently detailed
The impact this can have when in production can be huge. It can mean the difference between a quick bug fix and many frustrating hours of analysis to determine the cause of a problem. Code must be able to be easily audited – it helps to isolate future issues and cut down on the time it takes to resolve such issues.
The above tips are a promising start for a move to a DevOps world. Even if the culture you’re part of hasn’t adopted DevOps yet, these tips can go a long way to improving the processes in your work environment. Your ops engineers will thank you for it, trust me.
What are your thoughts about transitioning to DevOps? Do you have any additional tips for adopting a DevOps mindset? Please post your comments below.