DevOps
DevOps is a term that is heard quite often. It comes from combining the terms development and operations. The idea is to speed up the time to develop and deliver solutions. It is also about delivering a high quality solution. There are many facets to DevOps, and many concepts that fit in it. You might have heard about Agile deployment. This is one take on DevOps. Or maybe you are familiar with Infrastructure as Code. This focuses more on the Ops side of DevOps by allowing the automation of infrastructure deployment. It can greatly speed up the deployment of resources that are needed for solutions.
With Infrastructure as Code you also get the advantage of being able to build a consistent environment. You can also speed up patching and configuration changes to systems to make them the most secure that you can. You can script the deployment of a solution in the development environment. Then take that same code and roll out the exact same environment in your test or ITG environment. And then finally you can push that same solution straight to production. Now all three environments look exactly the same. And you can then walk changes up through the levels as you design and develop them. Deployment in higher environments is as simple as pointing the same code to the next environment. And when you are done with an environment you can use the same code set to decommission the environment.
With Infrastructure as Code you also get the advantage of being able to build a consistent environment. You can also speed up patching and configuration changes to systems to make them the most secure that you can. You can script the deployment of a solution in the development environment. Then take that same code and roll out the exact same environment in your test or ITG environment. And then finally you can push that same solution straight to production. Now all three environments look exactly the same. And you can then walk changes up through the levels as you design and develop them. Deployment in higher environments is as simple as pointing the same code to the next environment. And when you are done with an environment you can use the same code set to decommission the environment.
Scaling
Along with deploying a solution, you can also easily scale your solution. You can take the same code set to expand or contract your environment as needed. Maybe most of the time you can get by with four virtual servers. But once a quarter the servers would be overloaded with work. You can scale up the system to 6 or 8 servers during the heavy load time. Then when that time is past you can remove the extra servers, saving a lot of expense in systems that are not needed most of the year.
It is also possible to use monitoring to kick off scaling scripts. Maybe you don't know exactly when you will need more capacity. But you do know that periodically you will have heavy loads. You can set up monitoring so that when loads get to a particular level the monitoring system will automatically launch a script to spin up additional systems. Then when load drops below a certain level for a predetermined amount of time those systems will be spun back down.
This ability is ideally suited to use in the cloud, such as AWS, Azure, or Google. You can keep your costs much lower by provisioning resources only when you need them. It also helps with on premise systems too though. Say you have a VMWare ESX farm, and a lot of solutions or apps running on it. Different apps get busy at different times of the week, month, or year. You can reduce the needs of the underlying hardware for the ESX farm because you can spin up and down resources as needed. So app 1 might get busy on Thursday through Saturday of each week, and need twice the number of servers. Then app 2 is used the most on Mondays. You have some finance apps that are only heavily used end of quarter and end of year. You see where I am going with this?
It is also possible to use monitoring to kick off scaling scripts. Maybe you don't know exactly when you will need more capacity. But you do know that periodically you will have heavy loads. You can set up monitoring so that when loads get to a particular level the monitoring system will automatically launch a script to spin up additional systems. Then when load drops below a certain level for a predetermined amount of time those systems will be spun back down.
This ability is ideally suited to use in the cloud, such as AWS, Azure, or Google. You can keep your costs much lower by provisioning resources only when you need them. It also helps with on premise systems too though. Say you have a VMWare ESX farm, and a lot of solutions or apps running on it. Different apps get busy at different times of the week, month, or year. You can reduce the needs of the underlying hardware for the ESX farm because you can spin up and down resources as needed. So app 1 might get busy on Thursday through Saturday of each week, and need twice the number of servers. Then app 2 is used the most on Mondays. You have some finance apps that are only heavily used end of quarter and end of year. You see where I am going with this?
Home |
About |
Services |
Copyright © 2016