3 Key DevOps Needs for Every Development Team

Source:- stackify.com

Agile development has created a process for developers to rapidly ship a new version of their code. DevOps is the next step in the process. It is the ability to help get that code to production as fast as possible.

DevOps should be about empowering your development team to be able to do their job and support their apps from A to Z. There are the 3 critical things I think every development team needs.

1. Automate builds and deployments

If you want to deploy software quickly and consistently, you need a consistent build process. Having “Bob” (the builder) do builds from his machine and push them to production does not work well. If Bob is gone or forgets a manual step, you could have a lot of problems.

How you consistently do builds is up to you. Your tech stack and preferences will dictate that to some degree.

Many years ago I did builds manually via a virtual machine named Bob (of course). It was a VM in production that I knew nothing else touched. I could remotely access it, pull down the latest source code, build, and deploy artifacts from it via xcopy. It was rudimentary at best, but it worked. I was a DevOps pioneer and didn’t know it.

We achieve this today at Stackify by using Bamboo to automate builds and one click deploys our apps to the cloud. Azure takes care of provisioning the servers and all the other “junk” I don’t my team to be thinking about. Anyone on the team can deploy at any moment and have a high level of confidence that it will work perfectly.

2. Provisioning Servers
OK technically, you should probably provision servers before you try to deploy to them. But as a developer, I think about getting a successful build done first. So this is step 2 for me.

As a developer, I hate servers. I’m not even joking. I hate them as much as printers.

Provisioning servers is a very broad topic that varies wildly based on the type of app and how you host it.

In a lot of organizations, they tend to deploy to the same servers all the time and probably don’t setup new servers very often. Most apps never run on more than a few servers. Their apps just don’t get enough traffic. In those cases, provisioning new servers are less of an issue. At Stackify, we add new servers all the time due to our massive scale. It is a big deal for us!

Option 1: Use an Application Hosting Engine (Public or private cloud)

If you have your choice, I would highly recommend deploying your applications in a way that automatically provisions the servers for you. This helps to ensure that developers don’t have to get involved in the actual creation of the servers and that it is done consistently every time.

For example, with Visual Studio and Azure, it can be done in a couple clicks. I’m just showing this as an example below, you should really do this as part of your build server and deployment process. That will give you better tracking of when deployments are done, what was in them, etc.

Cloud application hosting options:

• Azure App Services & Cloud Services
• AWS Elastic Beanstalk
• Google App Engine
• Heroku
• … and more

On-premise private cloud options:

• Cloud Foundry
• Azure Stack

Cloud computing is not an option for some organizations. However, developers still need the same sort of PaaS environment and tools to make them more productive. Maybe containers could help?

Option 2: Containers

Another good way to solve this problem is Docker containers. Instead of provisioning lots of virtual machines, you could pack a bunch of lightweight Docker containers together. Although, you still need an easy way to manage how many instances of them there should be, deploying new versions of them, etc.

Docker management tools:

• Docker
• Rancher
• Cloud66

Option 3: Configuring Servers

If you have to provision actual servers, first off, I’m sorry.

I still have nightmares about having 15 web servers that do the same thing and frantically needing to set up more of them. Today, I solve that problem by clicking a button in Azure. Back then, we had a VMWare image saved off that had to be cloned. Inherently, 10 things changed since the image was taken and nobody knew what they were. ?

The problem with servers is knowing the exact configuration needed. This problem varies wildly based on your application.  This involves things like installing your web server, application framework, OS updates, security permissions and other dependencies. ?

To solve this challenge, configuration tools like Puppet and Chef have become really popular.

3. Optimizing and monitoring application performance

The DevOps community has always focused on deploying applications. I have always felt like the monitoring side of it gets forgotten about. Developers need visibility to data about how their apps are performing to troubleshoot problems quickly. It is an essential component of DevOps.

Application monitoring is a completely different beast than server monitoring. 10 years ago we monitored if a server was up or down and the CPU. We monitored Exchange and our critical web servers the same way. Obviously, that didn’t provide much insight into how our applications were performing.

Today, application monitoring is an umbrella term that could mean a lot of different things. There are 6 specific things that I feel like developers need:

• APM – code level application performance visibility
• Transaction tracing – code level traces of what your code is doing
• Metrics – server, application, and custom metrics monitoring
• Logs – aggregation, searching, and management
• Errors – aggregation, reporting & alerting
• Alerts – robust monitoring and alert capabilities

If you want to understand the performance of your application, you need all of these things. Each of them tells a small part of the story.

Let’s take errors as an example. While doing any software deployment, monitoring for errors is the first line of defense for finding problems. Odds are, the new release will likely cause some new errors they have never seen. It is just the nature of software development. Developers need to be able to quickly see these new errors so they can rapidly hot fix them.

Application monitoring tools are the eyes and ears of the development team in production. In lots of companies, developers do not have access to production servers. That is easy to understand for multiple reasons. However, it is very difficult for developers to troubleshoot problems if they can’t get access to log files and other data.

Companies can enforce strict security rules in production and give developers everything they need by leveraging the right types of tools.

Conclusion

I founded Stackify because I was frustrated that my development team didn’t have the tools that they needed. We had Nagios, Splunk, and multiple other tools. None of my developers had access to them. Even if they did, the tools only told part of the story and were hard to use.

Developers love and need tools. If you want to embrace DevOps, you need tools to help them build, deploy, and monitor their applications. DevOps is about removing barriers. These essential functions can help developers take ownership of their apps.