3 Keys DevOps Needs for Every Development Team:
Agile development has created a process for developers to rapidly provide 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.
What do development teams need to embrace(accept/support) DevOps?
DevOps is about to empowering your development team to be able to do their job and support their applications from A to Z. There are the 3 critical things I think every development team needs.
1. Automate Builds and Deployments
2. Provisioning Servers
3. Optimizing and Monitoring Application Performance
1. Automate Builds and Deployments
If you want to deploy software quickly and consistently, you need a consistent build process.
suppose some from the built team who has responsibility to built the application & we have to dependent on him/her. somehow if he forgot the steps or not doing in proper time, then you could have a lots of problems.
Many years ago, I did builds manually via a virtual machine abc...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.
now we achieve this whole built through one click, and our apps is ready to run on the cloud.
Many cloud service provider like Azure/AWS etc. takes care of provisioning the servers and all other junks.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, we should probably provision servers before 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 set up 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.
we can 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 Azure, it can be done in a couple clicks. 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 etc.
On-premise private cloud options:
Cloud Foundry, Azure Stack etc.
Cloud computing is not an option for some organizations. However, developers still need the same sort of PaaS (Platform as a service)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 etc.
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 on 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 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.
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.
Agile development has created a process for developers to rapidly provide 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.
What do development teams need to embrace(accept/support) DevOps?
DevOps is about to empowering your development team to be able to do their job and support their applications from A to Z. There are the 3 critical things I think every development team needs.
1. Automate Builds and Deployments
2. Provisioning Servers
3. Optimizing and Monitoring Application Performance
1. Automate Builds and Deployments
If you want to deploy software quickly and consistently, you need a consistent build process.
suppose some from the built team who has responsibility to built the application & we have to dependent on him/her. somehow if he forgot the steps or not doing in proper time, then you could have a lots of problems.
Many years ago, I did builds manually via a virtual machine abc...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.
now we achieve this whole built through one click, and our apps is ready to run on the cloud.
Many cloud service provider like Azure/AWS etc. takes care of provisioning the servers and all other junks.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, we should probably provision servers before 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 set up 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.
we can 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 Azure, it can be done in a couple clicks. 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 etc.
On-premise private cloud options:
Cloud Foundry, Azure Stack etc.
Cloud computing is not an option for some organizations. However, developers still need the same sort of PaaS (Platform as a service)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 etc.
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 on 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 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.
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.
No comments:
Post a Comment