6 min read
September 7, 2020
In the previous post we started talking about employees, and how are they prepared for this cloud journey, and open to the change this means? Are the leaders of the company prepared to support the employees through this change? Is the company prepared for the following:
The above list is a mix of tech and business. The first one, possibly the most important is more business than tech, Agile DevOps Methodology. It is listed first for a few reasons. The main reason is that it probably is the hardest. If you weren’t following the Agile Framework for software development, you might want to look into it. It emphasizes short iterative planning and development cycles. Agile accounts for that projects require the ability to pivot, and that you will probably make a mistake. With the short iterative process, you can test sooner and more often. Which allows you to identify issues sooner. Time is money, the sooner the issue is identified and fixed the less it costs you. Just like the sooner, you realize you need to pivot and can pivot you can stop spending money on something that no longer matters. So both can drastically save you money in the long run. Then bring it to the next level with DevOps. DevOps is a set of practices that combines Software Development (Dev) and IT Operations (Ops). It is complementary with Agile, and some of the aspects came from Agile. DevOps focus on hyper releases starting with several per day. When you combine the two you can see how they complement each other. DevOps promotes fully automated CI/CD (Continuous Integration and Continuous Delivery/Deployment) for frequent releases, and Agile provides the ability to rapidly adapt to changing requirements and better collaboration between smaller teams.
DevOps can introduce some major changes to how things work. As implied DevOps obscures the job roles and shift the responsibilities of some of the roles. One of the biggest changes is the concept of everyone is a developer, which complements the cloud IaC (infrastructure as code). So everyone should be writing code to some extent. At the end of the day, Developers will be implementing infrastructure and IT Operations will be writing code. This opens up the sweet spot of team design. You will still have a Dev Team and an Ops Team however their responsibilities overlap around 10% and each team communicates and help the other as needed, but still doing what they do best. Some of the other changes would be team sizes between 5 and 10 people per team, Ops should start using what were typically dev tools like version control, and Devs have to take on some operational features and understand what they need to implement. If you are not careful your teams can fall into anti-patterns of DevOps that inevitably fail. An example of this is when either Devs or Ops think they do not need the other. It is easy for one of the teams to underestimate the complexity and importance of the other’s skill set and have issues communicating. So things take longer and perhaps not done as well as they could be. I will do a much deeper deep dive around DevOps later, however, if you would like to learn more about the team setup, please go to web.devopstopologies.com. That is a major source for me when it comes to that topic
With everything as code several of the dev tools and principals crossover:
The last 2 items can go together. First, instead of purchasing and having to plan for capacity years in advance, you are now purchasing resources as you need them when you need them. You pay as low as per-second of service, typically there is a minimum that can vary by the provider. Either way, if you have a service that can support the compute service scaling, if you need an extra instance for 15 minutes a day, you are only charged for the second instance when you use it. One of the major benefits of the cloud is they have data sources all over the world. You can deploy multiple resources in multiple regions either for disaster recovery or to just better support your customers.
- Transition to Agile DevOps
- From IaaS to PaaS (at least)
- From Monolithic Applications to microservices
- The transition from CapEx (Capital Expense) to OpEx (Operational Expense)
- Think Global
The above list is a mix of tech and business. The first one, possibly the most important is more business than tech, Agile DevOps Methodology. It is listed first for a few reasons. The main reason is that it probably is the hardest. If you weren’t following the Agile Framework for software development, you might want to look into it. It emphasizes short iterative planning and development cycles. Agile accounts for that projects require the ability to pivot, and that you will probably make a mistake. With the short iterative process, you can test sooner and more often. Which allows you to identify issues sooner. Time is money, the sooner the issue is identified and fixed the less it costs you. Just like the sooner, you realize you need to pivot and can pivot you can stop spending money on something that no longer matters. So both can drastically save you money in the long run. Then bring it to the next level with DevOps. DevOps is a set of practices that combines Software Development (Dev) and IT Operations (Ops). It is complementary with Agile, and some of the aspects came from Agile. DevOps focus on hyper releases starting with several per day. When you combine the two you can see how they complement each other. DevOps promotes fully automated CI/CD (Continuous Integration and Continuous Delivery/Deployment) for frequent releases, and Agile provides the ability to rapidly adapt to changing requirements and better collaboration between smaller teams.
DevOps can introduce some major changes to how things work. As implied DevOps obscures the job roles and shift the responsibilities of some of the roles. One of the biggest changes is the concept of everyone is a developer, which complements the cloud IaC (infrastructure as code). So everyone should be writing code to some extent. At the end of the day, Developers will be implementing infrastructure and IT Operations will be writing code. This opens up the sweet spot of team design. You will still have a Dev Team and an Ops Team however their responsibilities overlap around 10% and each team communicates and help the other as needed, but still doing what they do best. Some of the other changes would be team sizes between 5 and 10 people per team, Ops should start using what were typically dev tools like version control, and Devs have to take on some operational features and understand what they need to implement. If you are not careful your teams can fall into anti-patterns of DevOps that inevitably fail. An example of this is when either Devs or Ops think they do not need the other. It is easy for one of the teams to underestimate the complexity and importance of the other’s skill set and have issues communicating. So things take longer and perhaps not done as well as they could be. I will do a much deeper deep dive around DevOps later, however, if you would like to learn more about the team setup, please go to web.devopstopologies.com. That is a major source for me when it comes to that topic
With everything as code several of the dev tools and principals crossover:
Tools
IDE
- VS Code
- Visual Studio
- Eclipse
Version Control
- Git (Currently the most popular)
- SVN
- TFVS (Team Foundation Version Control)
Principles
- KISS (Keep it Simple Silly)Do not over complicate what you are doing
- DRY (Don’t Repeat Yourself)If your IaC (infrastructure as code) supports modules/template linking use it
- SoC (Separation of Concerns)Don’t have one big template to manage everything
- YAGNI (You Aren’t Gonna Need It)Why create something that you are paying for before you need it
The last 2 items can go together. First, instead of purchasing and having to plan for capacity years in advance, you are now purchasing resources as you need them when you need them. You pay as low as per-second of service, typically there is a minimum that can vary by the provider. Either way, if you have a service that can support the compute service scaling, if you need an extra instance for 15 minutes a day, you are only charged for the second instance when you use it. One of the major benefits of the cloud is they have data sources all over the world. You can deploy multiple resources in multiple regions either for disaster recovery or to just better support your customers.
The services you are purchasing, most of them can be deployed within 15 minutes. This helps you ensure technology is working for you. Your disaster recovery plan for production can be implemented in a manner that, unless the provider goes done, you will have near-zero downtime guaranteed, if you want to implement it. There are ways to plan for hot/cold and depending on the resources you need you can spin up a hot secondary region within 15 to 30 minutes.
The cloud is designed to be agile. You purchase resources when you need them how you need them. If you need to pivot instead of having to think of how you can repurpose the existing monolithic server and what impact that will have, you can create the new resource try it out and then delete it at the end of the day. With Infrastructure as Code, there is no reason to leave the resources there if you are not needing them. If they get destroyed just redeploy them. That could easily be scripted.
In an upcoming post, we will look at diving more into this and looking to separate people from process.